BitPoet

First, look at the page properties. Firefox e.g. shows you the text encoding when you right click and select "Properties". Look at the headers of all requests and responses. Each response should have a Content-Type header that states the type itself and the charset used, something like: Content-Type: text/html; charset=UTF8 If there's no charset header in the response but you have an HTML document, a meta header stating the charset is also sufficient. That meta header can have one of two forms: <meta charset="utf-8"/> <!-- or: --> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/> In the ajax request, the "prod" get parameter should contain percent-encoded double-byte values if non-ascii-characters are present, like /ajax/getParticipants.php?prod=Nouvelle-%C3%89cosse If you see %C9 here instead of %C3%89, then your ajax call is submitting its data in the wrong charset. In that case, look at the HTML page (= PHP files) that loads it. Then, sometimes just one involved file (PHP include, javascript file) is in the wrong encoding and makes PHP fall back to an 8 bit encoding. You can check this (99% reliably) from within PHP by running a small one-liner (or putting that into a script if you don't have command line access and calling it over the web): echo mb_detect_encoding(file_get_contents("/path/to/file/you/want/to/check")); The most likely suspect for being non-UTF-8 would be getParticipants.php, so I'd check that one first. Btw., I would expect this line: to read: data: {prov: prov}, instead, but that may of course just be a copy&paste error.

I'm pretty sure that at least a big part of the problem is a charset issue, as PW itself otherwise has no problem searching for accented characters. Use your browser's debug tools to check every request and response (page itself, ajax request/response) and make sure that all the templates and other files involved are also saved in UTF-8 format. Did you try the quotes together with your pipe substituion? If yes, it would explain why the others weren't found anymore, as the pipe then was no longer recognized as an alternative match operator. province%=Nouveau|Brunswick means that a search is successful if either Nouveau or Brunswick is found in the province field, whereas the pipe character is threated like any other character inside quotes.

You can use quotes around selector values, as documented here. So you might try if that solves your problem without any substitutions. $entries = $wire->pages->find("template=municipality_page, province%=\"$choice\""); Though, to be on the safe side, you should always sanitize all user input (the sanitizer can even add quotes where necessary): $entries = $wire->pages->find( "template=municipality_page, province%=" . $sanitizer->selectorValue($choice, array("useQuotes" => true)) ); Also, make sure your file encoding (also of the "prov" GET parameter) is UTF-8.

Ah, didn't look which admin theme you're using. Hooking into AdminThemeRenoHelpers::topNavItems should be the way to go. $wire->addHookAfter('AdminThemeRenoHelpers::topNavItems', function($event) { $out = $event->return; $out .= '<li><img src="path/to/your/logo.png"></li>'; $event->return = $out; });

You should be able to hook into AdminTheme::getExtraMarkup and add your image to $extras["masthead"] (untested): $wire->addHookAfter('AdminTheme::getExtraMarkup', function($event) { $extras = $event->return; $extras['masthead'] .= ' <img src="path/to/your/logo.png">'; $event->return = $extras; }); You can look into AdminThemeDefault/default.php to see where the different extras are used.

@Speed: you did restart the webserver after changing http.conf, right? I don't know MAMP in particular, but check if there's an "AccessFileName" directive somewhere in the Apache config. It may be looking for htaccess or htaccess.txt instead of .htaccess on Windows since the latter can only be created in a CMD window (I've encountered some Apache bundles over the years that did so).

Another idea: is there a class with the same name (TextformatterListCK) lying around somewhere in an include path?

The module itself is fine. Is the markup in the body field really what you think (i.e. no whitespaces or additional attributes in the ul/ol tags)? Does the content you look at really come from a body fields? Do you have caching enabled?

To get it to work in 2.8, the "namespace ProcessWire;" at the top of each file needs to be removed. The configurable module check error is thrown because the module doesn't have a getModuleConfigInputfields method. ",ConfigurableModule" needs to be removed from the implements declaration. After those two steps, it works fine in 2.8 (albeit with the missing fonts issue Mike mentioned).

This one might also be interesting. It uses a simple table to store todo entries for adapting links to images and files after a page is cloned. https://github.com/BitPoet/ProcessPageCloneAdaptUrls/tree/dev

Does this: $sub_image = $pages->get("has_parent.id=$sub->id,template=product, sort=random")->product_images->find('tags=prod')->getRandom(); work? (You may want to also include a "product_images.tags=prod" subfield selector for the pages in case you have pages without a production ready image)

not() modifies the original PageArray, so you need to populate your variables with a copy of the original PageArray before you filter them. ($primary_tags = $article->article_tags->slice(0))->not("id=1336|1337|1338|1339|1327|1326|1328"); ($secondary_tags = $article->article_tags->slice(0))->not("id=1042|1043|1044|1340|1341");

I'd pick a different upload directory that $config->paths->assets (which amounts to site/assets). Perhaps create an upload directory inside the assets dir and save it there. You could also shorten your image extraction function a little (and make it image type agnostic): function myImageExtract($imgData, $imgName, $assets) { $file = $assets . $imgName; file_put_contents($file, file_get_contents($imgData)); return $file; }

I don't think there's a straight-forward solution for this. Usually, advanced search requirements like this are covered by external search engines like Lucene, but those might a bit of overkill. A lean solution would be to create a (hidden) text field, let's call it titlenospace, and add it to all templates you want to search. Then, in site/ready.php (create the file if not there yet), hook into Pages::saveReady and populate the new field with the whitespace-stripped contents of the title field. <?php if($page->template == "admin") { wire()->addHookAfter("Pages::saveReady", function(HookEvent $event) { $page = $event->arguments(0); if($page->template->hasField("titlenospace")) { $page->titlenospace = str_replace(' ', '', $page->title); } }); } For a multi-language site, the titlenospace field has to be created as TextLanguage and the code gets slightly more verbose. <?php if($page->template == "admin") { wire()->addHookAfter("Pages::saveReady", function(HookEvent $event) { $page = $event->arguments(0); if($page->template->hasField("titlenospace")) { $page->titlenospace = str_replace(' ', '', $page->title); if(wire("languages")) { foreach(wire("languages") as $lang) { if(!$lang->isDefault()) { $page->setLanguageValue($lang, "titlenospace", str_replace(' ', '', $page->getLanguageValue($lang, "title"))); } } } } }); } The titlenospace field needs to be populated for existing pages (simply saving them should do). Then you can use the field in your selector instead of or in addition to the regular title field.

In addition to hort's suggestion, writing the raw image data contained in the data URI can be as simple as: file_put_contents($filename, file_get_contents($data)); No need for manually parsing $data for the base64 part. The only reason to look at $data would be to determine the correct file extension in case other types than png are allowed too.

Try save()ing $p before you assign the images. Some fields, and image/file fields in particular, only get initialized once the page is saved for the first time. I'm not sure if passing a data url to Pageimages::add will work though. If you hit an error there, you may have to extract the raw image data from $image using file_get_contents(), write those to temporary image file and pass the path to the temporary file to the method.

I found the time to test with a plain 2.8 installation, and it also refused to save changes. Just in case somebody needs a quick workaround too, I replaced the original code in UserGroupsHooks.module (starting at line 738): foreach(array('view_groups', 'edit_groups', 'manage_access') as $name) { $inputfield = $form->get($name); if ( $inputfield instanceof Inputfield ) { $inputfield->processInput($this->input->post); if( $inputfield->isChanged() ) { $page->set($name, $inputfield->value); } } else { $this->log->message("Not an input field in form: $name"); } } with this workaround for now: $fld = $this->modules->get("InputfieldCheckbox"); $fld->attr('id+name', "manage_access"); $fld->processInput($this->input->post); if($fld->value != $page->manage_access) { $page->set("manage_access", $fld->value); } if($page->manage_access) { $pa = new PageArray(); foreach($this->input->post->view_groups as $grp) { $pa->add($this->pages->get($grp)); } $pa->sort("id"); $page->view_groups->sort("id"); if($page->view_groups->implode("|", "id") != $pa->implode("|", "id")) $page->view_groups = $pa; $pa = new PageArray(); foreach($this->input->post->edit_groups as $grp) { $pa->add($this->pages->get($grp)); } $pa->sort("id"); $page->edit_groups->sort("id"); if($page->edit_groups->implode("|", "id") != $pa->implode("|", "id")) $page->edit_groups = $pa; } The fix in Issue #45 is also necessary for PW 2.8.

Picking "autossh" as command name is a bit of a bad choice in my option, since a similarly named command (and *nix package) with an identical use case has been around for more than 12 years.

Let me start with saying that UserGroups is one of the most important modules for me. Last week I noticed, though, that on our intranet (recently updated to PW 2.8 from 2.6) permission changes on a page weren't saved anymore. I tracked it down to the code in accessTabInput in UserGroupsHooks.module that somehow refused to assign the changed values from POST parameters. I've built a (quick&dirty) workaround that accesses the raw post values and assigns from there, foregoing processInput() and isChanged() calls (processInput even fails to do its job if I instantiate my own InputfieldPage objects), but I don't want to rule out that I'm missing some setting or detail. So if anybody has UserGroups working (or not working) in a 2.8 installation, it would be great to know so I know in which direction to take my further research.

ProcessWire by default blocks access to files with the extensions php, htm, html, inc and tpl underneath the templates directory (or, to be precise, the shipped .htaccess file does so). This is a security feature. Thus, to access third party PHP code, you have two choices: Move the relevant code outside of the templates directory or create a template with a PHP file in site/templates that includes the external library (in your case instapast-ajax.php, and that's where Ryan's quote comes in) and a page that uses this template (and that provides you with the URL to call from JS)

Have a look at the sql_mode setting of your MySQL server. This looks like ONLY_FULL_GROUP_BY is enabled.

Thanks for the pointer, I totally missed your module when I looked for existing modules for that feature. Seems I'm a bit out of the loop... I guess I need to reserve a few hours to play with AOS.

Can you try the latest version on git? The error should be fixed with version 0.1.0. The latest version also incorporates @tpr's fix for the count() on null problem in case someone removes one of the fields from the MediaLibrary template. @Zeka: I'm still looking into script loading in the frontend question. Currently, it's expected behaviour for an uncoditional autoload module, but I'm of course looking to only have the script loaded when necessary. Might be a while though, as it means a lot of testing and delving through PW's frontend editing code until I know what I'm doing.

Out of necessity (that is, my editors having created pages with hundreds of files attached...) I've whipped up a small module that adds a live search box (just plain jQuery hide/show) to file input fields (just for InputfieldFile, not images, and no searching descriptions yet). I've called it InputfieldFileFilter. If anybody wants to give it a try, it can be found at https://github.com/BitPoet/InputfieldFileFilter It's currently running on PW 2.8, though it should be compatible with other versions as well. I'd be happy to get a little feedback if this is worth rolling into a more elaborate module. The module is really only in alpha state right now, so I'd not recommend to put it onto a production system, and it does need quite a bit of testing. InputfieldFile has a lot of js magic attached after all...

The Content-Transfer-Encoding of 7bit isn't compatible with utf8 (or any other non-US-ASCII charset), but unfortunately it is hardcoded in WireMail.php. When mail clients encounter this header and find characters above ASCII code 127, it is anybody's guess how they interpret them. This should IMHO be fixed directly in the WireMail class' send method. A quick-n-easy approach would be to look for individual characters outside the 0-127 range and, if such is present, set Content-Transfer-Encoding to base64 and use encode_base64 on the part in question.