ryan

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.

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.