adrian

There are some links and also some code for creating repeaters and adding fields to it here: Shouldn't be anything special about doing it from a module. HTH.

Nope - you just select the template of the parent page and the template that you want to use for the child pages from the module config settings. It should be pretty obvious once you start with it.

Hey @onjegolders - I just tested @mr-fan's version of this script (which makes it a configurable module) and it works fine for me in PW3. The new page are created as direct children of the page where the bulk images are uploaded. The only thing I noticed that seemed a little weird is that if no description for an image was entered, the child page title used the name of the image directly including the file extension. I have created a PR which improves this: https://github.com/mr-fan/AutoImagePages/pull/1 Until that is accepted, please check out my fork: https://github.com/adrianbj/AutoImagePages

Hi @Klenkes - I decided to go with #2 - now BCE will only apply the "purify" sanitizer if the field that is being populated/updated has the HTMLPurifier enabled. Could you please test at your end to make sure it works as expected? Thanks!

I do use the $sanitizer->purify option with all content added via BCE, so that will be the source of the problem for sure. I can see two possible options here. 1) Add a BCE config setting to enable you to turn off the purifier sitewide and/or per parent page. 2) Check the purifier status for the field that the content is being added to and respect that. Any thoughts? PS if you want a quick fix, just edit this line: https://github.com/adrianbj/BatchChildEditor/blob/ba228d2f011d306345f02ec4aa19d090f2d89481/BatchChildEditor.module#L1448

Hey @bernhard - I spent quite a bit of time looking into this the other day with no success. It turns out it's not just hooks inside ready.php - it seems like ready.php is never called at all from the Tracy console panel. I will investigate further, but so far a bit of a mystery. I thought perhaps it was an issue with ajax calls (which the console panel uses), but a normal ajax call results in ready.php being called, so really not sure at the moment. I'll see what I can figure out. Cheers, Adrian

You could also just do this. By using "first()" you avoid the need for the foreach loop. $cart->renderPriceAndCurrency($release->children("limit=1, sort=pad_price")->first()->pad_price);

You could also use Batch Child Editor's edit mode to change the status of all 500 children at once. Simply click the checkbox for the "Unpublished" label and that will uncheck it for all child pages.

To follow up more - I just tried this in init.php: bd('test init'); $this->addHookAfter("Pages::saved", function($event) { bd('test init inside hook'); $this->log->save('debug', 'saved hook'); }); and this in ready.php: bd('test ready'); $this->addHookAfter("Pages::saved", function($event) { bd('test ready inside hook'); $this->log->save('debug', 'saved hook'); }); and got this response when running from the console panel: So, ready.php is being called, but hooks inside it are not - weird

Hi @bernhard - I am not really sure why at the moment, but if you move your hook to init.php (instead of ready.php), it works when the code is run from Tracy's console panel. So it looks like for some reason ready.php is not being called from the ajax call that the console panel makes when running code. Does that help?

@Klenkes - a simple solution to this would be for you to manually change the "data" field in the "modules" db table from "text" to "mediumtext". I'll see if I can get Ryan to do it in the core so it's always available. https://github.com/processwire/processwire-issues/issues/321

The best option would be if you could please post an issue on Github: https://github.com/processwire/processwire-issues Thanks!

Just looking at this now and it actually looks like this is the same behaviour as the PW core. Try disabling this module and manually change an additional language "name" for a page. Sometimes I get the integrity constraint violation and other times it actually names the page the same without an error and without adding a "-1". Can you please confirm the same behaviour at your end and if so, maybe this should be fixed in the core instead.

Hi @titanium - sorry for the delay - turns out this was a new problem with the multi-language title info that was added recently. Please test the latest version and let me know if you have any further problems.

@sanstraces - depending on your actual needs, this might also be an option:

TracyDebugger's "production" mode has the option to email for various error types. https://processwire.com/blog/posts/introducing-tracy-debugger/#production-mode-error-logging-and-email-notification

As far as I know ffmpeg is the only solution for being able to create poster images. That said, I haven't looked into this is a few years, so maybe now there is. If you find an alternative I might be able to implement it within this module.

Do you have ffmpeg and ffmpeg-php installed and running correctly? Maybe that's not the issue and there is something else new that is breaking poster generation, but please confirm that you have those.

I don't have time right now, but I don't expect it would take too much to make it work to populate the fields in the backend, instead of just displaying on the frontend. Probably just a matter of a config setting and a new hook (in addition to the current Fieldtype::formatValue) to get it to populate the backend form fields instead. Feel free to submit a PR

I don't have much time to figure out why at the moment, but I discovered that InputfieldPageListSelect::renderReady is not being called for non-superusers. It is inside this that the ProcessPageList module is loaded, so as a quick hack so I can move on for now, I added: if($page->template->name == 'admin' && $user->isLoggedIn()) $this->wire('modules')->get('ProcessPageList'); to site/ready.php which gets things working properly again. I hope to find some time to get back to this and investigate properly, but if anyone else has any ideas that would be awesome

Thanks - unfortunately creating a new role to assign to the user isn't working for me - I'll take a better look tomorrow and see what I can figure out. Cheers.

Hi @gebeer - I just came across this - one of my site editors gets this error when trying to edit a PageTable or Repeater field that contains images. I haven't investigated much yet, but was wondering if you ever found out anything more on this? It seemed to come out of the blue, but maybe it was related to a PW core update? What version are you running?

https://www.typografics.be/nl/blog/processwire-bigger-stronger-faster-en-easier

Hi @Robin S - just wanted to confirm that you have everything working as expected now when editing Page Tables in a modal window? @tpr - I am a little confused - what styles.css file are you talking about? The one included in TracyDebugger, or something else? How can you use this module in non-PW projects? @hettiger - glad you like it - thanks! PS Hi again everyone - it's been a while

Hi @kixe - thanks for all your thoughts here. Hopefully you know that I have been away and not just ignoring your post! The latest version has the getBranchRootParentId function hookable. The reason I did this is because when a user is restricted to a branch of the page tree, there is no "Home" breadcrumb, so I added this to give them easy access back to the root of the pages they have access to. I am curious about the working solution you have though - maybe it takes care of what we both want? I think that regardless of the interaction with this, module those "1" values shouldn't be hardcoded in the PW as you noted - maybe you could submit a PR to Ryan to fix those? As for the actual prepending of BranchRootParent to the Pagetree under PagesTab, do you mean here: Test One and Test Two and children of the BranchRootParent and as you note, the BranchRootParent itself is not shown. Not critical, but I agree it would be nicer if it was, but from some quick looking around I don't think it's going to be possible at the moment without manually prepending the BranchRootParent to the markup returned by ProcessPageList::executeNavJSON - certainly possible, but not pretty. Any thoughts on my comments? I'd certainly like to help as much as possible for you on this, so just let me know. Cheers, Adrian