Robin S

Okay, I got the vendor folders sorted - it's the ones in the "on-server" folder, right? I can see the basic v5 icons but I can't seem to view the new v5 Pro icons. Even with Selectize enabled for the icon select in SelectizeTemplateFieldTags I can't find the "alarm-clock" icons, for instance. A few other little things: 1. In FontAwesomePro.module, $this->config->urls->$name . "vendor/js/v4-shims{$min}.js?v=$version" should be "$this->config->urls->$name . "vendor/js/fa-v4-shims{$min}.js?v=$version" 2. In the readme/info for SelectizeTemplateFieldTags it could be clearer that the module has a dependency on the JquerySelectize module. The module gives a JS error that can stop the admin interface from loading properly if JquerySelectize is not installed. 3. It's a little hard to find the JquerySelectize module in the modules directory because it is listed under author "outflux3" instead of "macrura".

Thanks. Still not sure about adding the Font Awesome files though. Maybe you could spell it out a bit more in the readme? When it says "css, js, sprites and webfonts folders", which ones exactly? There aren't folders with those names in repo root - it looks like this... ...and there are multiple folders named "css" within the repo structure. Thanks.

@adrianromega, did you see the "Example use" section above? To expand on this... it's useful in any situation where you want to be fair to a group of images with different aspect ratios. Take the three images shown in the screenshot above. If these images had been resized using maxSize(800,800) for instance, photo 2 (the square image) would be larger than the others in total area - it would contain the most image data. Now suppose you're running a competition on your website where visitors can vote for the best photo. The three images above have been submitted by three different photographers. If you are resizing by maxSize() rather than megapixels then it's not fair on photographers 1 and 3 that their images are shown smaller than the image from photographer 2.

Hi @Macrura, Is this module working with the latest Font Awesome 5 Pro releases? The readme says to copy the Font Awesome files to the module directory and rename the outer folder as "vendor", and I see paths like below in the code: $this->config->urls->$name . "vendor/css/fontawesome-pro-core.css?v=$version" I have an early Release Candidate version of FA Pro 5 that has paths like that, but the recent versions look like this... ...and there is no file included anywhere named "fontawesome-pro-core.css". Another question: when the module is installed, does it replace the core icon preview with the icons from FA Pro 5?

One more option, but requires a pro module. Lister Pro has a delete/trash action in its set of bundled actions. I use this one a lot.

Inspired by the "max megapixels" option for the client-side image resizer, I made a simple module that adds target megapixel resizing for Pageimages. Image Megapixels A module for ProcessWire CMS/CMF. Adds methods to Pageimage objects useful for resizing to a target megapixel value. Example use You are creating a lightbox gallery of images with different aspect ratios. For the enlargements, rather than setting a fixed maximum width or height you want all the enlargements have the same size in terms of area, allowing a panoramic image to be wider than a square image, for instance. Another use case is sizing a gallery of sponsor logos. The supplied logos are different aspect ratios but you need to ensure the logos are sized so each has equal prominence on the page. The effect of resizing three different aspect ratios by the same megapixel target value can be seen in the screenshot below: Installation Install the Image Megapixels module. API // basic usage $pageimage = $pageimage->megapixels(float $megapixels); // usage with all arguments $pageimage = $pageimage->megapixels(float $megapixels, array $options = []); Example: foreach($page->images as $image) { echo "<img src='$image->megapixels(0.8)->url' alt='$image->description'>" } If needed you can supply an array of options for Pageimage::size() as a second argument. Getting dimensions If you just want to get the height and width dimensions needed to size an image to the given number of megapixels you can use the Pageimage::megapixelsDimensions() method that this module also adds. It returns an array with width and height as keys. Example of how this could be used to output a gallery of logos: foreach($page->logos as $logo) { $dimensions = $logo->megapixelsDimensions(0.01); $width = $dimensions['width']; $height = $dimensions['height']; $width2x = $width * 2; $height2x = $height * 2; echo "<img src='{$logo->size($width, $height)->url}' srcset='{$logo->size($width, $height)->url} 1x, {$logo->size($width2x, $height2x)->url} 2x' alt='Logo' width='$width' height='$height'>"; } https://github.com/Toutouwai/ImageMegapixels https://processwire.com/modules/image-megapixels/

The documentation could be clearer in this regard, and I'm probably oversimplifying here, but there two basic categories of selector usage in PW. 1. Methods that use the PageFinder class - common ones would be $pages->find($selector), $pages->get($selector), $page->children($selector). Also find/get selectors for $users. Those are the ones that spring to mind, although there might be a few more. These methods do a database query behind the scenes. 2. All other methods that accept a selector, for example $some_pagearray->find(), which is actually WireArray::find(). These methods do not query the database but work on items that are in memory. There are differences in the ways that these two categories of selector usage are implemented. Some things work in a PageFinder selector that don't work in an in-memory selector. The documentation for Selectors seems to be assuming the reader is interested in PageFinder selectors because there are code examples there that won't work with in-memory selectors. There isn't any definitive list of the differences (that I know of), but here are some things that I have found do not work with in-memory selectors (but do work with PageFinder selectors): 1. Datetime values as strings, e.g. "some_datetime_field>today" 2. Page statuses as strings, e.g. "status!=hidden" 3. OR groups In a perfect world selectors would work the same everywhere and you wouldn't have to think about it. There's an open request for this here.

I don't think OR groups are supported at all in WireArray (therefore PageArray) methods - adding support for OR groups inside a single PageArray selector is what BitPoet's module above is all about. But if you are doing what I suggested with find() and add() then you don't need the OR group parentheses. It's a different approach but should result in the same thing as OR groups inside a single selector.

In this example you only have a single query for modifying the original PageArray. So you don't need add() here - that is only needed for cases like your earlier example where you have multiple queries to apply to your PageArray where you want to say "find this" OR "find this". // Your original PageArray (which you will reduce down from) $pagearray = $pages->find($selector_1); // First modifying query $results = $pagearray->find($selector_2); // Stop here if you only have a single modifying query // Otherwise if you have additional OR queries, add them to the results $results->add($pagearray->find($selector_3))

See here for how you can add those settings via hooks:

Not necessary I think. As far as I know PageArrays are always unique (they never contain the same page more than once).

You could filter the PageArray more than once and add the results together. Actually, filter() is destructive so use find() instead. $results = $pagearray->find($selector_1)->add($pagearray->find($selector_2));

I remember you mentioning this in the FB subforum and it's a nifty solution. In terms of letting editors add the repeatable field, you could bundle the bits into a custom inputfield module and then include it in the types allowed for FormBuilder.

There's no performance issue with having any number of pages under a parent - the admin page list (and Lister) are ajax-driven and paginated for this very reason. I'm not aware of any module that creates virtual folders of pages in this way. Rightly or wrongly, ProcessPageList doesn't really lend itself to being manipulated like this. If you wanted to have the posts inside real year/month parents you could try the ProcessDateArchiver module. It's hasn't seen any updates in a while but maybe it doesn't need any (I haven't tried it). Or, if you're keen to get your hands dirty in code you could make a custom Process module with selects for month and year, and a datatable that lists matching blog posts. @bernhard has written a great tutorial for getting started with Process modules.

It's not that I think the PW admin isn't easy, but there are lots of scenarios where users don't need to edit site content in any big way and seeing the PW admin would confuse them more than anything. Like where your users just have an account so they can access a private "members" area, or view "premium" content, etc.

Via a custom front-end login form. I think that's how most of us have been dealing with front-end logins (until the LoginRegister module came along - I haven't had the chance to use it yet). Well, it's not unusual. Guess it depends how many sites you build that service front-end users.

I like to use Lister (or Lister Pro) for this purpose. Rather than being limited to a single, static organisation of pages Lister allows you to view pages by any number of filters: date, author, field value, etc. Lister Pro has a number of useful features, including that you can create dedicated listers for particular preset filters, and include some default empty filters within the lister. But you can still achieve a lot with the core Lister using the Bookmarks feature.

I think @Peter Knight might be talking about logging out a front-end user, in which case you might not want to expose the admin login URL to those users. I usually create a dedicated template and page /logout/ for the purpose.

The thing is, that isn't the code from the OP. To experience the issue I believe you need to have a minimum of three usages of the same PageFinder operation (in this case, getting the children of the root page). In SamC's original code there were two usages where the children of root are retrieved (showing different alternatives for doing the same thing) and then a third usage of the children of root within the foreach that generates the dropdown menu. An explanation of what I believe is going on (to the extent that I understand it):

And it's not just children() but other (all?) methods that use PageFinder: Weird.

Hi @adrian, Have you given any thought to the idea of making some of your modules PW3-only? For most modules I think it's nice to keep PW2 support (I have been doing that for my modules so far) but in the case of Admin Actions where the idea is that users can code their own actions it would be good to be able to declare the ProcessWire namespace in the action files, for the sake of code completion and avoiding false code warnings in an IDE. I could add the namespace to ProcessAdminActions.module manually (to avoid fatal PHP errors), but then it will get lost when the module is upgraded. This isn't a big issue and I can just comment out the namespace declaration in my action files after I've finished working on them. Just thought I'd ask for your view on things.

@ridgedale, sorry, I should have tested that hook better. It seems that PHP's strpos() function will not work with an integer (page ID) as a parameter. So the page ID needs to be cast to a string. I'll add the revised code below and edit my earlier replies. To fix your posts, first remove the hook in /site/ready.php. Next you will need to execute some API code. Not sure how experienced you are with that, so a couple of ways you can do it... 1. If you have Tracy Debugger installed you can use the Console panel. 2. Assuming your site is a dev site and you are the only person with access to it, you can put the code in a template file (e.g. home) and then load a page using that template on the front-end. Code is: $items = $pages->find("template=blog-post, include=all"); foreach($items as $item) { $item->of(false); $item->name = $item->id . '-' . $sanitizer->pageName($item->title, true); $item->save(); } When you have executed that and checked that your blog post names are okay you can remove the API code above from your template file (if you executed it that way) and add the revised hook back to /site/ready.php: $pages->addHookAfter('saveReady', function (HookEvent $event) { $page = $event->arguments(0); if($page->template != 'blog-post') return; // Only for the blog-post template if(!$page->id) return; // Skip pages that are brand new and aren't yet populated with data // If the page name doesn't start with the page id if(strpos($page->name, (string) $page->id) !== 0) { // Prepend the page id to the page name $page->name = $page->id . '-' . $page->name; } });

Just sharing a tip... PhpStorm had slowed down to a crawl, disk usage was regularly at 100% and the interface was sluggish to the point it was almost unusable. After some googling I found a suggestion to try restarting using the Invalidate Caches option and it has made a huge difference. Now everything is snappy and fast again. More info here, and be sure to read and understand the warnings, especially the fact that your local history will be erased.

Nice one! I think the fact that the ID of the original page is not retained when the draft replaces it is a bit of a problem. Because any pages that have a reference to the original page in a Page Reference field will lose that when the draft is published and the original is trashed. This issue is discussed earlier in the thread, and Ryan's suggestion was to copy the content of the draft page to the original page when the draft is ready to go live. Maybe you could look at using that approach?

I think ridgedale has the hook working now. Or are you asking because you want to use this hook yourself? If you have Tracy you can do some simple debugging to find out why the hook might not be working in your case. $pages->addHookAfter('saveReady', function (HookEvent $event) { bd('saveReady hook fired'); $page = $event->arguments(0); if($page->template != 'blog-post') return; // Only for the blog-post template bd('$page has template blog-post'); if(!$page->id) return; // Skip pages that are brand new and aren't yet populated with data bd('$page has a non-zero ID'); // If the page name doesn't start with the page id if(strpos($page->name, (string) $page->id) !== 0) { bd('$page name does not already start with its ID'); // Prepend the page id to the page name $page->name = $page->id . '-' . $page->name; } }); Based on what is dumped you can find out where things are going wrong.