ryan

Here's some good coffee shop ambient noise: http://coffitivity.com/ I'm testing it out right now, trying to see if I can still focus with the noise.

It does seem odd to me that it started occurring after the server/PHP upgrade. The query that it says is failing "show columns from..." also reminds me a lot of a bug I just fixed this morning with FieldtypeMapMarker. Though I've never seen it occur with the images field, but the images field does do something very similar in terms of supporting DB schema changes to the field table. It looks like you are running PW 2.3.0 or earlier, based on the class names in the exception. I'd suggest upgrading to 2.3.2 (dev) and seeing if this resolves the issue. However, both PW 2.3.0 and 2.3.2 have the failing query mentioned here (FieldtypeFile.module line 261) wrapped in a try/catch block, which makes the exception here particularly unusual. You might want to wipe out your /wire/ directory completely and replace it with a brand new copy, then clear the APC cache.

This has never been the goal with selectors. I think we'd have an unusually complex selector system if it could entirely replace SQL. SQL is very powerful and–relative to it's power–probably as simple as it can be. So when needs come up that are more easily accomplished by SQL, that's the way to go. The goal with selectors is to remain simpler than SQL for the majority of cases, but not to replace everything you can do with SQL. No doubt we'll continue adding new options and capabilities to selectors in the future, but it's always got to be a balance in focusing on the things that will get the kind of usage and mileage that warrant their inclusion. If the sorting by date then reverse by time function that you mention comes up regular need for many people, then it may be worth adding at some point.

When you are running APC a good function to know is apc_clear_cache(). Put that in a file and run it, or maybe added it to your homepage template file with some code like this: if($user->isSuperuser() && $input->get->clear_apc) apc_clear_cache(); Then you could just access your site and do this: http://domain.com/?clear_apc=1. It's not often you'll need to clear the APC cache, but it's a good idea any time you see anything weird like this. However, I'm guessing that the table really doesn't exist and the error messages are correct. Though I'm also guessing the table creation process got screwed up by the APC cache somehow. I would go into PhpMyAdmin and create the table manually, so that you can either use it or delete it. Paste this into the PhpMyAdmin SQL tab and execute it: CREATE TABLE `field_event_image` ( `pages_id` int(10) unsigned NOT NULL, `data` varchar(255) NOT NULL, `sort` int(10) unsigned NOT NULL, `description` text NOT NULL, `modified` datetime DEFAULT NULL, `created` datetime DEFAULT NULL, PRIMARY KEY (`pages_id`,`sort`), KEY `data` (`data`), KEY `modified` (`modified`), KEY `created` (`created`), FULLTEXT KEY `description` (`description`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8; After clearing the APC cache, try creating a new image field and see if it's still having problems?

Sorry about that guys. It turns out that it was trying to execute a query to update the schema of the DB table, before the table existed. The exception interrupted the creation of the field in the DB. I've fixed the issue and posted an update. This applies to new MapMarker fields only, no problem with existing fields (which is why I hadn't noticed). This update should also enable you to delete any fields you created that had this error (you'll want to delete it and re-create it, since it doesn't have a table). Regarding the "ENGINE=MYISAM" statement, that should already be getting added by the base Fieldtype.php. In your case, it probably didn't because the field creation process was getting interrupted. But I did double check to be sure: echo "<pre>"; $ft = $modules->get('FieldtypeMapMarker') print_r($ft->getDatabaseSchema($fields->get('map'))); results in: Array ( [pages_id] => int UNSIGNED NOT NULL [data] => VARCHAR(255) NOT NULL DEFAULT '' [keys] => Array ( [primary] => PRIMARY KEY (`pages_id`) [data] => FULLTEXT KEY `data` (`data`) [latlng] => KEY latlng (lat, lng) [zoom] => KEY zoom (zoom) ) [xtra] => ENGINE=MyISAM DEFAULT CHARSET=utf8 [lat] => FLOAT(10,6) NOT NULL DEFAULT 0 [lng] => FLOAT(10,6) NOT NULL DEFAULT 0 [status] => TINYINT NOT NULL DEFAULT 0 [zoom] => TINYINT NOT NULL DEFAULT 0 ) Please let me know if you are getting a different result or still needing to specify the engine separately?

I'm not–I've only ever used PHP on their servers as an Apache module (the default way they have it setup).

Usernames are just page names. If you aren't using them for user login, and don't want to append numbers, etc., you can always do something like this: $user->name = $user->email; The "@" will get converted to a "-" (as will less commonly seen email characters like "+").

I wouldn't consider it a bug necessarily, but it sure would be nice if it would throw a JS error or something. This was a difficult one to track down.

I wasn't able to duplicate this one. What browser? Any chance I could get a look at what you were pasting? Inline mode actually puts the contents directly in the HTML document (which is why it's called inline mode) rather than in a safely iframe'd window like regular mode. As a result, something as simple as an unmatched tag can break the entire page editor, and make it very difficult to fix–you'd have to switch back to the regular CKEditor, fix and save it, then switch back to the Inline editor. That's why something like HTML Purifier is so important in inline mode.

Ryan, glad to see you working on this module! It looks like you already figured this out, but /site/assets/cache/[your dir] is usually a good place to store things like XML cache files. If connected with a page, then just use the page's files dir ($page->filesManager->path or $page->[your files field]->path). Horst is right that you can add files to pages and manipulate them using PW's methods from there. He's also written an excellent manipulation module. If you just need to resize images, also look into PW's ImageSizer class, which is ready to operate on any file (doesn't need to be connected to a page). In the dev branch, I'm about to push some updates to that class from Horst that add sharpening and auto rotation among other tweaks. Lastly, I wanted to mention that the dev branch also has the WireHttp class, which you may find more convenient than CURL.

I like to solve it by having a lot of specific templates, and only 1 basic-page type template. This is in part because I really like to keep pretty strict family settings for each template, so that the client doesn't ever have to decide what template to use when creating a page, and they don't have the option to create pages where they shouldn't. It also opens more options for current or future access control. But the actual template files are pretty spartan, and many of them totally blank, some set or modify a few variables, and others simply include another. I rely on my prepend/append template files to handle all of the common stuff (_init.php and _main.php) leaving the other template files focused purely on any components that are unique for the template. In terms of scalability, I also like having lots of template files, even if there isn't much in them, because future additions and modifications are very simple. So far this way has worked really well for the last few sites I've used it on, but I don't think any one method works best for everyone because we all have slightly different needs.

Also take a look at the Foundation site profile that uses both $config->prependTemplateFile and $config->appendTemplateFile options. It also takes the approach of defining a bunch of shared functions, similar to what you were trying to do. I have no idea why yours didn't work though, as if you include a file with functions defined in it, then those functions should be available to any code that follows it, regardless of what file the code is in. I think that either the Skycrapers or Foundation profiles would be good examples to look at.

I haven't run into that here. But we are using TypeKit. Please let me know if it continues or if anyone else runs into it?

You actually don't need or want the "sort=sort" at all when it comes to a children() call, because it's already assumed, given that parent pages already specify a sort. You would only specify a sort if you wanted to modify the default sort. But there would be no condition under which you'd need to specify a sort=sort to a children() call simply because if the default sort is something other than sort=sort, then "order in the admin" doesn't exist by definition. I don't know why specifying it is breaking it without looking into the code (not in front of it at the moment), but my guess is that it's canceling the default behavior in this case. As a result, I think if you simply omit that part, it should work the way you want.

I'd consider that a bug. There are reasons to install language support even with only 1 language, like if you want to take advantage of static translation capability in template files. I've added this as an issue on GitHub, and I'm hoping to get through the current queue of issues here over the next few days.

First things first, the $user->language should be set based on the current domain its being accessed from. We'll assume that the subdomains match the language names, i.e. subdomain "fr.domain.com" corresponds with language "fr", as named in ProcessWire. Code like this should exist at the top of a common include file that gets run/included before others (I recommend using $config->prependTemplateFile to automate it for you, see /site/config.php). /site/templates/_init.php: foreach($languages as $language) { if(strpos($config->httpHost, "$language->name.domain.com") === 0) { $user->language = $language; break; } } Next, I'm not necessarily sure it's ideal to autodetect the browser language and redirect based on that. There will always be cases where this doesn't actually match the user's preference. It might (possibly?) be an SEO concern too. It also limits what you can do in terms of caching, since you have detection code that always needs to run. I think it might be better to present a default language and an easy path for the user to find their language. However, if you still want to do language detection from the browser, you can look at the http_accept_language header. We'll assume that your languages are subdomains use the same naming convention as the http_accept_language, which would be "fr", "en", "es", etc. $name = $sanitizer->pageName(substr($_SERVER['HTTP_ACCEPT_LANGUAGE'], 0, 2)); $language = $languages->get($name); if($language->id && $name != $user->language->name) { $url = "http://$name.domain.com" . $page->localUrl($language); $session->redirect($url); } I've found that flags don't always represent language well. For instance, for Spanish do you show a Spain, Mexico, or some other flag? I think what's better is to make the selection based on the native language name, i.e. "Espanol" for Spanish. This is easily recognizable to people looking for the language. As for implementation, there is a good code example for this in the API documentation: How to implement a language switcher. In your case, using different domains, the same strategy would apply except that you'd need to include the domain as part of the $url, i.e. // this for: de.domain.com $url = "http://$language->name.domain.com" . $page->localUrl($language); // or this for: domain.de $url = "http://domain.$language->name" . $page->localUrl($language);

When I get a new VPS or dedicated server (usually from ServInt) the first things I ask them to do are: Upgrade PHP to the latest version available (preferably 5.4+). Install an opcode cache like APC (except for PHP 5.5, which apparently has one built in). Make sure that PDO is enabled (some ServInt default configs don't have it for some reason). I also usually make two tweaks to the php.in file: Bump up the memory_limit to 128M or 256M. Not technically necessary, but nice when you need to import or manipulate a lot of data or deal with large photos. Bump up the upload_max_filesize and post_max_size to a number at least as large as the largest files I'll be uploading (usually 100M).

There was a bug in the InputfieldCKEditor module that made the "Anchor" tool not work. In fact, if you clicked on it, it basically freezes the page and you can't do anything but reload. This is a result of the Anchor tool now requiring the Link plugin in CKEditor (as of version 4.1.2 I think). Since the Link plugin was in our default "Removed Plugins" configuration setting, the Anchor tool is broken. In order to fix it, edit your field settings, click the "input" tab, and remove "link" from the "Removed Plugins" list. Alternatively, you can just update your InputfieldCKEditor to the latest version v1.1.1 and it will take care of this for you. The latest version of InputfieldCKEditor also updates the CKEditor version from 4.1.2 to 4.2.0 and has a few more tweaks as well, so it's worth the upgrade even if you don't use the Anchor tool.

Just wanted to mention that $thistitle should also be sanitized as a selector value (if it isn't already).

What version of the CKEditor module? Double check that ACF is enabled. When you paste stuff, only the formatting that is allowed from the advanced content filter should come through. Meaning, things like <h2>, <p> and <a> tags should come through, but things like <span class='-mso-blah-blah-blah' style='blahblahblah'> should not, unless one of the plugins is allowing it. I did a few test copy/pastes from other websites, and it is allowing more to come through than I'd like. It appears one of the plugins is allowing "style" attributes on links and some other things. Unfortunately I'm not sure what CKEditor plugin is allowing that yet. But once you hit save, the HTML Purifier module should fix those things. It sounds like you actually want some of those styles to be retained–I don't recommend this, just because it would be very difficult to maintain consistency unless you are always the editor, and inline style attributes aren't pretty from the code side. It's better to focus on marking things up properly on the back-end, and let your front-end stylesheets make them look the way you want on the front-end. But if you want to keep those styles, you probably need to use regular (not inline) mode and turn off HTML Purifier in the field settings.

I've just pushed some fairly major updates to this module for version 2.0.0: Add zoom to the data managed by this module. It can be accessed from your field in the same way as address, lat and lng, i.e. $page->map->zoom. It will remember your zoom level setting from the page editor, and it can be used for generating your own maps. The map settings are now configurable in the field settings (input tab). This includes the starting/default location for the map, map height, default zoom level and map type. Removed some annoying behaviors from the geocoder. The client-side (javascript) and server-side geocoders no longer try to complete with each other. InputfieldMapMarker is now responsive so that it's input organization is just as usable at mobile resolution. Addition of a new related Markup module: MarkupGoogleMap. This provides an easy way for you to generate maps with the data managed by FieldtypeMapMarker: $map = $modules->get('MarkupGoogleMap'); // output a map with one marker echo $map->render($page, 'map'); // or output a map with a bunch of markers: $items = $pages->find("template=something"); echo $map-render($items, 'map'); This is just a basic usage example. For all options see the README.

I actually ran into this issue myself on Wednesday when I was upgrading a client's PW install running PW 5.2.17. I corrected the issue and committed it yesterday morning when I got an email about this thread. I hadn't been through the issues list this week yet, but looks like Roope submitted the exact same fix more than a week ago. I have no idea why PHP 5.2 doesn't like the syntax, or why I changed the syntax in the first place, but the latest dev should be fixed to work with PHP 5.2.

Dragan is right, it your relative URLs wouldn't work just because the path may be changing relative to the language. The fix is as simple as using an absolute path rather than a relative one.

It sounds like you want to change the field attributes just for the context of a single template, is this correct? If so, look into $fields->saveFieldgroupContext().

Matthew, I'm assuming this this error occurs after you perform $pages->find(), $pages->get(), or $page->children(), type call somewhere that contains a selector that looks like "title=some title, with a comma in it"? Wanze is right that you would want to use selectorValue on the "some title, with a comma in it" before bundling it into the selector. But if you are just creating pages, rather than querying pages for a title, then let me know.