Robin S

Thanks, seems like a good approach. Was unsure at first whether the "id" value in the JSON export needed to be incremented when duplicating for import, but after testing it looks like PW ignores the id value on import and assigns a new id, so no need to worry about that.

I have an idea for an enhancement: for the "Enable + New link?" option it would be great if the newly added page was automatically selected in the Page field. Ideally it would show as selected immediately after closing the modal window (reload the Page field via AJAX?), or otherwise show as selected after saving/refreshing Page Edit. If a person is adding a new page from within Page Edit I think it's likely they want to select that option also. I also noticed a quirk in that the "+ New" link is not rendered unless the "Enable view/edit link(s)?" option is also selected.

This is in the core now for PW dev, so no module needed. However, the "Enable + New link?" feature of this module is nearly what I was hoping for. It allows the addition of new pages in a modal window. The only catch is that the added page is not available for selection until the page being edited is saved or reloaded. Thanks for pointing me in the right direction.

The "Allow new pages to be created from field?" option is great for site editors, but you can really only allow this if the template used in your Page field only needs the Title filled out. If your template requires other fields then editors need to leave the page they are editing and create a new page from the tree or from "Add New". It would be cool if there was an option to add new pages to the Page field via a modal window (like the one you get if you allow edit links for the field).

@adrian: I'd love to try your modified Batcher module for adding multiple fields - nice to have a GUI for the task. I've seen other modified Batcher modules posted on the forum so I figure Wanze is okay with this. Maybe you could post the module here or fork it on Github?

Great idea! If I understand correctly, the module looks for a glossary page with a title that matches the text between the pipe delimiters. I'm wondering about cases where the term in the textarea needs to be slightly different than the glossary page title, for instance if you need to use a plural form of term. Say I have a glossary page for "mouse" but in my textarea I need to say "mice" - could a variation like that still be linked to the glossary item? Perhaps introduce some syntax to manually specify the glossary term for such cases?

The "toggle all" checkbox doesn't seem to be working. I had a play around with the JS and changing $('input.toggle_all').click(function()... to $(document).on('click', 'input.toggle_all', function()... seemed to do the trick.

That is brilliant - thanks!

Incidentally, when I set out to achieve a blurred image effect I initially thought I would do it client-side. Each client-side option I tried had issues: CSS filter - not supported in IE SVG filter - blur effect noticeably less smooth JS stackblur plugins - difficult to use as a CSS background image supporting background position and background size properties In the end it was so much easier to do it server-side, and browser support is 100%. Edit: for those interested in client-side image manipulation, CamanJS is pretty cool. It's an absolute breeze to use on inline images using the "data-caman" attribute, just a bit of a hassle to use it for CSS backgrounds.

Not really sure what you're getting at here. Do you mean you could do this in Photoshop? Because you could, but Photoshop doesn't run on your server. This is for processing images on a website, maintainable by your client. You're going to download, open Photoshop, filter and reupload each time your client changes an image? That's definitely not more efficient.

Not a module, just a little function for applying effects to images if you have the Imagick PHP extension installed. This started out as a need to blur an image and then I expanded it to accept more of the Imagick methods. Not all Imagick methods are supported. The function takes the URL to a source image, the name of an Imagick method and an array of arguments for that method, and returns the URL to the processed image. The processed image is saved to same directory as the source image, with the method name and arguments appended to the name of the source image. Images are cached in that the function checks if an image with that name/method/arguments exists already to save recreating it on every page load. function imagickal($imagePath, $method, array $arguments) { $path_parts = pathinfo($imagePath); $dirname = $path_parts['dirname'] . '/'; $filename = $path_parts['filename']; $mod = $method . '-' . implode($arguments, '-'); $mod = wire('sanitizer')->filename($mod, true); $savename = $dirname . $filename . '_' . $mod . '.jpg'; if (!file_exists($_SERVER['DOCUMENT_ROOT'] . $savename)) { $image = new Imagick($_SERVER['DOCUMENT_ROOT'] . $imagePath); call_user_func_array([$image, $method], $arguments); $image->writeImage($_SERVER['DOCUMENT_ROOT'] . $savename); } return $savename; } I'm a PHP novice so happy to receive suggestions of how this could be improved. Imagick reference: http://php.net/manual/en/class.imagick.php Examples of some effects possibilities...

I've just watched the demo video for the amazing Visual Page Selector module that kongondo is working on and it's got me thinking about the one-image-per-page approach to managing images. I haven't had a project that needed to reuse images on a large scale but I can see how it would be a good approach for managing a media library. My question: when it comes to adding new images in the one-image-per-page approach, I understand how it's easy to do this via the API but how do you make it easy for site editors to add multiple images at once and add descriptions and tags to those images? Has anyone devised a module that that allows images to be added and described from within the PW admin? Or would it be simpler to create a form on the frontend (with restricted access) to handle image uploads/descriptions/tags?

Ahh, it's a Firefox-specific issue. Thanks for the info. There are probably ways to get the desired behaviour in Firefox (e.g. give the password and confirm fields similar properties so they both get autofilled, or load the Set Password field with AJAX only if it is opened), but maybe it's not considered worthwhile to make such changes just for the quirks of one browser.

I think this has been requested before, but I can't find the thread I read it in. The user profile page can contain the selection for admin theme if more than one is installed, and possibly other fields too I believe. It would be good if these fields could be changed without having having to enter the user password. Also, if you forget to type in the password when attempting to change another field on this page and get the "Passwords do not match" error the change you were trying to make is not remembered and you have to make the change again.

Github issue is here for those interested, along with a suggestion for an alternative approach to making the input form pretty.

Setting the CKEditor field to inline mode does fix the bug. I think I have traced the bug back to these lines of JS code, which attempts to match the height of adjacent columns with every change (e.g. keypress) to the CKEditor field. Will open a Github issue for this.

Just tried the current stable and can't replicate the bug.

I'm experiencing a weird bug with CKEditor that seems to occur when a neighbouring field in the same row is taller than the CKEditor field. Firefox: when typing the cursor jumps to the start of the CKEditor text area with every keypress. IE: when typing the text appears below the CKEditor window. Chrome: the bug does not occur. The screenshots below show the result of typing the second line "How now brown cow?"... All browsers, neighbouring field shorter than CKEditor field (no bug) Firefox, neighbouring field taller than CKEditor field IE v11, neighbouring field taller than CKEditor field If someone can confirm they get the same bug I'll file an issue on Github. Thanks.

Thanks Soma, I understand better now.

Okay, thanks.

Thanks adrian, that works fine, although it does start to get a bit long-winded depending on how many pages you want to match. Any idea why the pipe syntax can't be used like with ID and other fields? In my case I'm selecting pages to appear in the main navigation. I was using name but then an editor created a news item called "News"... So was aiming for something more unique than name but more readable than ID. The combination of name and parent is a great suggestion.

The API docs have an example for OR selectors, to match any of a group of page IDs. id=123|124|125 What is the correct syntax for doing something similar but using page paths? I tried... $pages->find("path=/news/|/about/") ...but no success.

Is it possible to use the "selector" option to choose menu items based on parent? I tried... "selector" => "parent=1020" ...and... "selector" => "parent=/my-page/" ...but neither of these worked. I know I can do this by setting a PageArray as the root object but I'm trying to understand why I can't do this with the selector option.

I've noticed that the search box in the header of the ProcessWire website and forums doesn't work very well. For instance, how is that a search in the Modules section for "admin custom files" doesn't deliver the page for the module with this exact name as the first result, or even anywhere on page 1? It doesn't appear in the results until page 4 of 5. The forum search isn't great either, and maybe that's down to IP.Board. But what about the rest of the official PW site? Is that running on ProcessWire? It seems like a bit of a bad advertisement for PW if the official site is running it but the search doesn't work well. I find myself relying on the Google Custom Search to find things. Are there plans to improve the built-in search on the ProcessWire website?

I think I understand what this module does but I'm having trouble grasping the situations in which it would be useful based on the examples you've given. Is it just a convenience thing, so the editor doesn't have to look elsewhere for some information that might affect the content they decide to add to the page?