Robin S

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.

The path must be /site/ready.php Create a new PHP file "ready.php" in the "site" directory. Save the following as the contents of this file: <?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; } }); Adjust the name of the blog post template within the hook if needed.

Nowhere does the documentation say that "Name format for children" supports the string "id". The (unfortunately very brief) documentation for the feature says that it supports the string "title", or a date format string. When you insert "id" in the setting field PW attempts to interpret it as a date format. If you need something beyond what the feature provides you could try kixe's module, or use a hook.

Page IDs are not random, and they do auto-increment. If you check the "pages" table in phpMyAdmin you will see that the ID column is an auto-incrementing INT type. You'll also notice that rows (pages) in the table have sequential IDs. But the IDs increment site-wide for all pages, not separately or specifically for your blog post pages. So if you add some non-blog pages in between blog posts then the IDs for your blog posts will not be sequential. Deleting pages will also create gaps in the ID sequence. But all of this is completely normal on a system like this, and I can't see how it affects anything you might need to do with a blog post. Perhaps you could explain what the specific problem is that you are trying to overcome by inserting IDs in the page names.

What is your purpose for finding the pages within CKEditor? To link to them? In that case it takes a single click on the link button in the toolbar, then you have autocomplete in the "Link to URL" field.

Nothing extra is needed to achieve this. If you create a page that has the same title as another page under the same parent then by default PW will automatically add a digit to the end of the page name to make it unique. Unless you have a need for something different it's best to just leave it at that. But if you want to prepend the page id to the page name you can do it with a hook in /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; } });

Most likely explanation is that the page path or ID that you are saving to session is correct, and that it simply is the 404 page that is being loaded. Maybe you have removed view access for the guest role on one or more templates, and have the "Show a 404 page" option selected? Incidentally, an alternative to what you are doing in _init.php is to select the option "Redirect to another URL" to redirect to your login page, and pass the ID of the page that the user attempted to access in a GET variable. So something like... /login/?return={id} ...then you look for the return variable in your login template and redirect back to that page after login.

Not entirely sure about the following, so would be glad to hear from anyone who understands this better. @ryan? I think you must pass in any external variables to a named hook function as part of the $options array. See this line in the HookEvent class: @property array $options An optional array of user-specified data that gets sent to the hooked function. The hook handling method may access it from $event->data. Also includes all the default hook properties. So you would assign a custom key/value to the $options array by reference. An example: $colour = 'red'; $options = array(); $options['colour'] = &$colour; // assign by reference $wire->addHookAfter('Pages::save', null, 'hookFunction', $options); function hookFunction(HookEvent $event) { $opts = $event->options; $opts['colour'] = 'green'; // $colour is now 'green' // ... }

It's the WireData::and() method. Was a new one to me too.