BitPoet

I was thinking of Inputfields return from getModuleConfigInputfields. Here's a snippet to illustrate my thought: wire()->addHookAfter("Modules::saveConfig", function(HookEvent $event) { wire('log')->message("Hook after Modules::saveConfig"); $class = $event->arguments(0); if(is_object($class)) $class = $class->className(); $moduleName = wireClassName($class, false); $id = wire('modules')->getModuleID($class); $data = $event->arguments(1); $fields = wire('modules')->getModuleConfigInputfields($moduleName); foreach(array_keys($data) as $key) { if(! $fields->get($key)) { unset($data[$key]); wire('log')->message("Removed property $key from module {$moduleName} config"); } } // Code shamelessly stolen from Modules::saveConfig $json = count($data) ? wireEncodeJSON($data, true) : ''; wire('log')->message("Data = $json"); $database = $this->wire('database'); $query = $database->prepare("UPDATE modules SET data=:data WHERE id=:id", "modules.saveConfig($moduleName)"); // QA $query->bindValue(":data", $json, \PDO::PARAM_STR); $query->bindValue(":id", (int) $id, \PDO::PARAM_INT); $result = $query->execute(); $this->log("Stripped module '$moduleName' config data"); $event->return = $result; });

Can I leave a vote to make the restore optional? @tpr: the topic also came up here. Currently, PW carries over old field settings infinitely, though it might be worth a thought to make PW core (Modules::saveConfig) forget no longer applicable field values.

I think using an after or replacement hook on Modules::saveConfig should be possible, even if it creates a bit of repetition overhead. Retrieve the fields list (again) through getModuleConfigInputfields(), then iterate over all configuration values, unset() the respective entry if $fields->get($key) returns null and finally save (again). It's actually a tiny bit more complex since language support also needs to be taken into account, but not that much.

And you can find all 12 if you run a find for template=municipality_page without a province?

Hm, I understood your original post so that searching for words with accented characters only works if you substitute the hyphen, but I may have misread that. Still, trying to solve one mystery at a time: are the pages that aren't found activated for the French language? (Since Colombie-Britannique should be found in any case)

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)