ryan

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.

All image and file fields technically support multiple files. In your field settings, when you set it to contain a max of 1 file, you are really telling it to behave as a single file on the front-end of your site (for API convenience). But when it comes to administering files/images from the API side, all image/file fields are treated the same (when output formatting is off, as it would be when performing any kind of page manipulation). What I might suggest is to use this bit of a code instead when replacing your single image: $thisPage->image->deleteAll(); $thisPage->save(); // now add your new image

If you treat each photo as a page, then you'll have no problem with checkbox-style tagging (categorization), using a Page reference field. One way to do this is with an image field and a Page reference field in a repeater. This would be a fine way to go, but you'd be limited to uploading 1 photo at a time. Whereas with a regular images field, you can drag in a bunch at a time. Lets say you didn't like the repeater option due to the 1-file at a time issue. The way you describe it, you want to have an individual page (like an event) with a photos field, and the ability to tag those photos with predefined tags. I think of tags as being something more free form, and predefined tags as really being more like categories. This is not something that the Image fieldtype does on it's own. It does support tags, but it doesn't connect to an external database of them so that they can be predefined like categories. You could solve this by making your own Inputfield module that extends or modifies the existing InputfieldImage module. But for the simplest solution, I would probably just use the tags as they are already provided by the module (free form). You can use the API to find pages with images containing specific tags. To summarize, the most likely options are to 1) use a repeater with an image field and a page reference field, and compromise on the 1-file-at-a-time thing. 2) use the existing Image field tags option, and take the free-form compromise. 3) extend or modify the existing Image inputfield to work the way you want it, with the compromise being having to get deeper into the PHP side.

Thanks, that looks better–I will give this one a try.

Yes, that's better. Beyond creating the directory for you if it doesn't already exist, it's also good to note that the directory might not literally be the $page->id. If you've got the $config->pagefileSecure=true; option in your /site/config.php, then unpublished and non-guest-accessible pages will have file directories that start with a period, in order to prevent web access, i.e. ".123" rather than "123". Using the $page->filesManager->path or $page->[your file field]->path, rather than constructing it yourself, ensures that all of this continues to work as it should.

Thanks, I have added this to the /wire/templates-admin/styles/inputfields.css .Inputfields > .Inputfield > .ui-widget-content { /* the Inputfield's content, padded from the borders */ padding: 1em; overflow: auto; } ...but am seeing odd results, specifically this scrollbar: So I changed it to this: .Inputfields > .Inputfield > .ui-widget-content { /* the Inputfield's content, padded from the borders */ padding: 1em; overflow-y: auto; overflow-x: hidden; } ...and that seems to work. I'm not seeing any more oddities, but will keep testing. Just wanted to make sure this is consistent with what you guys are suggesting? Also, it was mentioned earlier that there were various CSS hacks already in place to solve the problem that this CSS fixes? I guess I'm not sure what or where those are, but if you can point them out, it might help me to better understand the issue. Not to mention, if there is redundant/unnecessary code somewhere, I'd like to remove it.

Very impressive module Horst! I look forward to using it. Please post to the modules directory too if possible. Thanks for your great work here.

I think it's best though just to keep it simple and use the template file home.php as your homepage template, and keep that on your root page.

They shouldn't be compressed. Regarding the 1-line issue, we can correct this on PHP 5.4 and newer as json_encode() now has a JSON_PRETTY_PRINT option, which makes it output the JSON in a human readable way (and I'm assuming a much easier-to-version way). I'm going to add a check for PHP 5.4 so that we can start taking advantage of this now.

The $cacheFile->remove() should remove all files in the cache directory for that page. Probably what would be better is just to call $cacheFile->remove() regardless of whether the individual cache file exists -- so your suggestion is a good one (but will use remove rather than removeAll). Secondary ID is a combination of $options (prependFile, appendFile, filename), page number, language and perhaps some other things I'm not thinking of. I can look at opening it up to more options. MarkupCache is also another option, that lets you have full control over the cache ID. I'll look into this option. Though the MD5 includes things outside the $options array as well, but perhaps the entire $options should be part of it.

I actually have no idea what you guys are talking about–tell me what to change? I understand code better than concept when it comes to CSS, so might need you to be literal as to what you suggest?

When you uncache a page, it also triggers an uncache() method on all the page's fields. Fieldtypes can decide how to handle that. If those fields are objects, then they may choose to uncache themselves as well. Depending on the fieldtype, this could mean that they essentially reload from DB the next time you access them. Text fields on the other hand are just text, not references to other object instances–so there aren't any external references to uncache. When you clone a page, it creates a second copy of everything (including the fields it references). By uncaching the clone instead of the original, you are effectively uncaching it from the ID cache of $pages only. A shallow uncache rather than a deep one. All the fields on your clone are still being uncached, but your original $page is still in tact and an uncache hasn't uncached your changes. Basically, I think what you are doing makes sense and is probably the right way to go here. Though it might make sense for me to add a $shalllow option to the $pages->uncache method, so that you could bypass a deep uncache if needed.

Would something like this work? (written in browser, so might need tweaking). This should print all events sorted by date descending, but grouped by day and sorted by time ascending within the day. $allEvents = $pages->find("parent=/events/, sort=-date"); while($allEvents->count()) { $event = $allEvents->first(); $from = strtotime(date('Y-m-d 00:00', $event->getUnformatted('date'))); $to = strtotime("+1 day", $from); $events = $events->find("date>=$from, date<$to, sort=date"); echo "<h3>Events on " . date('F j, Y', $from) . "</h3>"; foreach($events as $event) { echo "<p><a href='$event->url'>$event->title</a> $event->date</p>"; $allEvents->remove($event); } }

This is a planned future addition, not yet implemented.

For pages that are only containers, I usually try to implement them as just a general listing page of the children so that there is something there if someone goes there. Basically, I like containers that behave as containers, listing what children they have. I also check the "hidden" box for the page, so that it stays out of navigation and searches, when desirable. Other strategies I've used are to: Not implement a template file, so the page throws a 404 when you access it; Have it redirect to either the first child, or it's immediate parent, or the homepage, using a $session->redirect().

When saving files to a page's path, Wanze's got the right trick there, but do it like this instead (which ensures the directory is created if it's not there already): $document->save($page->filesManager->path . 'myName.docx'); You might also want to add it to an existing files field on your page? $page->files->add($page->filesManager->path . 'myName.docx'); The above assumes your files field is named 'files'. For temporary, non-web accessible files, I usually save to /site/assets/cache/ $document->save($config->paths->cache . 'myName.docx'); If you need to store multiple files, it's best to have your module create it's own directory under /site/assets/cache/.