Robin S

Yes, in this example I was saving in the admin. Thanks.

Hi @adrian, I'm having another problem with pages not being renamed when "Enable for API" checked. As a demo, here are my module config settings: {"PageRenameOptions":{"version":"1.0.5","settings":{"enableForApi":1,"renameMatchTitle":1,"renameWithoutTitleChange":"","renameUnpublishedOnly":"","includeExclude":"exclude","exemptTemplates":[],"exemptPages":[],"exemptRoles":["superuser"],"initialDifference":1,"preventManualChanges":1,"liveChanges":null,"uninstall":"","submit_save_module":"Submit"}}} In ready.php I have this hook: $pages->addHookAfter('saveReady', function(HookEvent $event) { $page = $event->arguments(0); if($page->template == 'basic-page') { $page->title = uniqid(); } }); For any page using the basic-page template, the page gets a new title on every save as expected but the name is not updated. I tried turning off "Initial differences protected" in case that was related, but pages are not renamed then either.

@gebeer, I have similar concerns as @szabesz, not just about the InnoDB requirement but the MySQL >= 5.7.8 also. I think a lot of hosts and existing sites out there are not going to meet that requirement. For instance all my sites use MariaDB and as far as I know there isn't full JSON support in MariaDB yet. Could you please clarify if InnoDB / MySQL >= 5.7.8 are strict requirements for the module? And if the module will partially work with MyISAM / MariaDB / MySQL < 5.7.8 which features would not be available?

I have now, and it works perfectly. Thanks! ?

@adrian, I don't seem to be able to dump anything inside a LazyCron hook. I don't get any errors (like I would if Tracy wasn't available when the hook runs) - I just don't get any dump in the Tracy bar. Is that expected, and do you have any tips for viewing dumps made inside a LazyCron hook? Thanks.

@ryan, thanks for this new module - really looking forward to getting my hands on it! One important thing that I think is missing though is support for Image fields (the screenshots say no File fields and I figure this means no Image fields either). It's a really common need to allow avatar/profile images for members. A simple file input would suffice, but of course it would great to have things like preview before upload, front-end image resizing, and progress bar for upload (especially if front-end resizing isn't possible).

This maybe: https://www.php.net/manual/en/function.floatval.php#92563 function ParseFloat($floatString){ $LocaleInfo = localeconv(); $floatString = str_replace($LocaleInfo["mon_thousands_sep"] , "", $floatString); $floatString = str_replace($LocaleInfo["mon_decimal_point"] , ".", $floatString); return floatval($floatString); }

First thing to try would be updating the core in case it's a fixed issue - at least to the latest stable version but I recommend going with the latest dev. From what Ryan has said the dev is going to become the new stable any day now, and in general the dev is never that unstable anyway - I always build new sites on the latest dev. If that doesn't fix it the solution is probably to grant edit access to the system repeater template, i.e. repeater_your_field_name. It's never been clear to me why users with edit access to the repeater field shouldn't have edit access to the repeater template.

You're nearly answering your own question there. The key is the position number in the field (zero-indexed like all arrays). Using this field as an example... The key is the position:

You're right - it doesn't work because the selected pages are lost after save. I remember now that there was an issue with how InputfieldPage and FieldtypePage interpret "page.some_field" when it is used to refer to another Page Reference field: https://github.com/processwire/processwire-issues/issues/479 The thing is that PW has to make some consistent evaluation of what "page" is in this circumstance and it can't really know whether you want page to refer to the edited page or the repeater page. I don't have much time right now but I might come back and explore this more later.

No, but I posted a hook for using the hidden JS max filesize validation for File fields: I'm not sure if this validation is used for Image fields. Another hook that could be used to check the filesize after an image is uploaded: $wire->addHookBefore('InputfieldImage::fileAdded', function(HookEvent $event) { /* @var Pageimage $image */ $image = $event->arguments(0); $max_filesize = 150000; if($image->filesize > $max_filesize) { throw new WireException("Image $image->basename is $image->filesize bytes which exceeds the maximum of $max_filesize bytes."); } });

The dependent selects feature has only ever worked with the selector string option as far as I know.

I had a play around and this hook seems to do the job: Edit: the hook doesn't work because the selected pages are lost on page save. Maybe related to the discussion in this issue. $wire->addHookBefore('InputfieldPage::render', function(HookEvent $event) { /* @var InputfieldPage $inputfield */ $inputfield = $event->object; $page = $inputfield->hasPage; $field = $inputfield->hasField; // Return early if inputfield is not in a Repeater page if(!$page instanceof RepeaterPage) return; $selector = $inputfield->findPagesSelector; // Return early if no selector or selector doesn't include a dependency if(!$selector || strpos($selector, '=page.') === false) return; // Get suffix added to inputfields in this Repeater page $suffix = str_replace($field->name, '', $inputfield->name); // Add the suffix to dependency inputfield names $selector = preg_replace('/(=page.[_a-zA-Z0-9]+)/', "$1{$suffix}", $selector); // Replace the original findPagesSelector $inputfield->findPagesSelector = $selector; }); Demo... Page tree: Selector string for Subcategory field: Page Edit:

LOVE the new module! I'm adding this to every site for sure. ? In terms of alternatives, besides the SystemNotifications module mentioned in the post there is also Page Edit Soft Lock, but UserActivity is more powerful. A question: is it possible to use this module via the API to find all users currently logged in by role? Something like (pseudo-code): $logged_in_editors = $userActivity->findLoggedIn("role=editor"); I think that could be useful. Thanks @ryan!

@DV-JF, I thought that this module was too "minor" to belong in the modules directory, but I get that it makes it easier to find, install and update so I've added it now. It should get validated and appear in the directory soon.

There is already a feature similar to this - it's the "Name format for children" setting on the template of the parent page. https://processwire.com/docs/modules/guides/process-template/ ID is not one of the supported options, but if you want the page to be named with the ID you can install @kixe's module which extends the functionality of this feature. http://modules.processwire.com/modules/process-setup-page-name/ Or you can enter something like a date format ("Y/m/d H:i:s") in the core "Name format for children" setting, which allows you to skip the Page Add step. And then set the page name and title to the ID with a hook in /site/ready.php: $pages->addHookAfter('added', function(HookEvent $event) { $page = $event->arguments(0); if($page->template == 'your_child_page_template') { $page->setAndSave([ 'name' => $page->id, 'title' => $page->id, ]); } });

The thing to remember is that this setting is called the "Formatted value", i.e. the value when output formatting is on. When output formatting is off the value of an image field is always a WireArray. And in your code, you specifically turn output formatting off before you work with the field (as you must). If you treat the image field value as an array I think it will work as expected. Something like: $page->of(false); $page->photo->removeAll(); $page->photo->add('https://example.com/img.jpg'); $page->save(); $image = $page->photo->last(); $image->textfield = 'Some text'; $page->save();

See the docs to understand the difference between $pages->get() and $pages->find(): https://processwire.com/api/ref/pages/get/ https://processwire.com/api/ref/pages/find/ You want $pages->find(). And you only want to execute it once and use $results for both the results list and the pagination. $results = $pages->find("template=product, limit=10"); // Results list foreach($results as $result) { // Output each individual result // ... } // Pagination echo $results->renderPager(array( 'nextItemLabel' => 'Volgende', 'previousItemLabel' => 'Vorige', 'currentItemClass' => 'active' ));

@Kiwi Chris, I think you want to make use of Inputfield::hasPage in this case. $wire->addHookAfter('InputfieldPage::getSelectablePages', function(HookEvent $event) { /* @var InputfieldPage $inputfield */ $inputfield = $event->object; $field = $inputfield->hasField; $edited_page = $event->arguments('page'); $page_containing_inputfield = $inputfield->hasPage; // a Repeater page in your case if($field->name === 'pageBatch') { // Use $page_containing_inputfield as needed here // ... } });

This was fixed in 3.0.144: https://github.com/processwire/processwire-issues/issues/1027

What we're discussing is a feature request rather than a bug to report, and there already is the feature request I linked to in my earlier post. I've added a comment linking to this thread but like all such things Ryan will just get to it when he gets to it. This is feature request 13 of 269 and counting. ?

If I use Tracy to do a test dump in FieldtypePage::wakeupValue (which is where the stored IDs are loaded into a PageArray) then it seems that this method executes regardless of the visibility of the field in Page Edit. And it's not Page Edit that's the main problem anyway. If you have a field then presumably you want to work with that field, but whenever you do... $page->my_pr_field ...then all the pages are loaded to memory. So for instance if you want to add a page via the API... $page->my_pr_field->add($p) ...then you are automatically loading all the pages to memory. @bernhard's suggestion and @teppo's module are good workarounds but I think it's important to get a core solution to this. PW has an "everything is a page" philosophy, so pages can be any unit of data, not necessarily a viewable page of content. And Page Reference fields are the fundamental way to make connections between pages in PW. So when you have thousands of pages that need to have connections to thousands of other pages then you have to start looking beyond the core fieldtypes which is a limitation for PW. Sometimes you can do what @wbmnfktr suggested and reverse the connection, putting the PR field in the other template to reduce the number of pages stored per field. But this isn't always possible. In terms of concrete examples, imagine you were using PW to build some kind of Spotify-like database that tracks users' listening habits. There could be thousands of users who listen to thousands of songs, so either way you cut it you want to store thousands of pages in a PR field.

I can't reproduce that here. If you insert an image without the caption checkbox checked then the plugin inserts an image with the class applied and doesn't insert a wrapping figure element. <p><img alt="" class="align_right" src="/site/assets/files/1/colin-watts-1141600-unsplash.300x0-is.jpg" width="300" />Lorem ipsum dolor sit amet, adipiscing elit. Nullam dignissim convallis est. Quisque aliquam. Donec faucibus. Nunc iaculis suscipit dui.</p> If you insert an image with the caption checkbox checked then the plugin inserts a figure + img + figcaption with the class applied to the figure element. <figure class="align_right"><img alt="" src="/site/assets/files/1/colin-watts-1141600-unsplash.300x0-is.jpg" width="300" /> <figcaption>Your caption text here</figcaption> </figure> <p>Lorem ipsum dolor sit amet, adipiscing elit. Nullam dignissim convallis est. Quisque aliquam. Donec faucibus. Nunc iaculis suscipit dui.</p> Something to be aware of is that if you change the alignment classes for Page Edit Image from their defaults you need to allow those classes in the Extra Allowed Content setting for the CKEditor field. img figure(is-pulled-left,is-pulled-right) It would be better if the class names configured in Page Edit Image were automatically allowed - there's an open issue about this: https://github.com/processwire/processwire-issues/issues/800

@AndZyk, a Page Reference field doesn't scale well because all pages are loaded into memory and there is no ability to limit the loaded pages or paginate the inputfield in admin. Back in 2016 Ryan said it was likely that pagination would be added to several core fieldtypes but it hasn't happened yet: https://processwire.com/blog/posts/fieldtype-pagination/ The Page Reference fieldtype/inputfield is the one that would benefit the most from this. I have an open request for this that you could add your voice to: https://github.com/processwire/processwire-requests/issues/13

See the module config for Page Edit Image (which is the Process module used by the PWImage plugin):