Leaderboard

Hello Bernhard. Congratulations on your module release. I've just been trying this out in your demo at pagebuilder.baumrock.com. I'm using FireFox as the browser and don't seem to be able to drag-and-drop blocks to change their position in the front end view. Perhaps it's just my install. I'm not seeing any JS errors in the console, but I just can't seem to get this working in FF (all good in Chromium.)

This week on the dev branch are some fixes and improvements, but we'll likely wait another week before bumping the version number up. Some new hooks have been added to $pages, including moveReady(), restoreReady() and renameReady(), to accompany the existing moved(), restored() and renamed() hooks. There was also some refactoring with the way that some hooks are called from $pages to improve their reliability and cover some edge cases where they might have not been called before. See the dev branch commit log for more. The biggest addition this week is likely the newly added support for custom page classes for repeater items. This was added to respond to a feature request initiated by @thetuningspoon and @Jonathan Lahijani let me know about earlier in the week. Here's how it works. If you have a repeater field named "menu_items" then you could create a class named MenuItemsRepeaterPage in /site/classes/MenuItemsRepeaterPage.php, and it would use your custom class rather than the regular RepeaterPage. Though note it must extend RepeaterPage. <?php namespace ProcessWire; class MenuItemsRepeaterPage extends RepeaterPage { // ... } This works with RepeaterMatrix and FieldsetPage as well, since both are derived from regular repeaters. But since both have their own Page classes you'd want to extend their page classes rather than RepeaterPage. In the case of RepeaterMatrix, it uses a class called RepeaterMatrixPage. So if your Matrix field is named "hello_world" then you'd create /site/classes/HelloWorldRepeaterMatrixPage.php: <?php namespace ProcessWire; class HelloWorldRepeaterMatrixPage extends RepeaterMatrixPage {} If you want a custom class for your FieldsetPage field named "seo" then you could create /site/classes/SeoFieldsetPage.php: <?php namespace ProcessWire; class SeoFieldsetPage extends FieldsetPage {} Let's say that you want to use a custom class without using the naming convention and/or file(s) above. You can tell the fieldtype what class to use for its item(s) like this: inclue_once('/path/to/MyCustomRepeaterPageClass.php'); $field = $fields->get('your_repeater_field'); $field->type->setCustomPageClass($field, 'MyCustomRepeaterPageClass'); In the example above, MyCustomRepeaterPageClass would extend RepeaterPage. You'd probably want to do this during the "init" or "ready" state, or at least sometime before you load any items from your Repeater (or Matrix or FieldsetPage) field. If your custom class is not in the ProcessWire namespace, then you'd want to include the namespace in your call, i.e. setCustomPageClass($field, "\\MyNamespace\\MyCustomClass"); If your custom page class is already in /site/classes/, or some other path where it can be autoloaded, then the include_once() line isn't necessary. (API ref pages for getCustomPageClass and setCustomPageClass). Big thanks this week to typneun Designagentur (https://typneun.de/) for posting more than 20 awesome new sites to our ProcessWire sites directory! That made my day. Thanks for reading, more next week, and have a great weekend!

Oh, thank you so much for elaborating && kind reply )). Am about to test your solution above #da2#, i believe it should work though.. I've been out for a while and now having an issue accessing an OS(zorin glitch), so i'm gonna start over with fresh installation and work it through. Thanks a lot !:)

After 10 years of PW development it looks like a break-through!? @MarkE thank you! I'll consider using PW again in my next prj.

Create a script that does what you want (publish one page) Trigger that script once a day For (1) read https://processwire.com/docs/front-end/include/ and for (2) you can either use https://processwire.com/docs/more/lazy-cron/ or - the better solution - a regular unix cron if possible.

I edit my response above, you are scary ?

Tailwind? I agree ?

I can sort-of achieve this by explicitly checking in the install() method and throwing an exception in the following manner: if(!wire()->modules->isInstalled('RequiredModule')) { throw new WireException(__("Unable to install MyModule without first installing RequiredModule")); return; } However, that seems rather cumbersome and I would have thought it should be unneccesary when the {module}.info.php already declares the requirements. Update: I have tried to investigate where the requirements are checked and dealt with, but it's very confusing. ModulesLoader.php (463) gives an error message, but just when listing, not as part of the installation. ModulesInstaller install() method seems to be the main place - line 96: $error = $this->_('Unable to install required module') . " - $requiresModule. "; but that doesn't always seem to operate for reasons I have not yet been able to ascertain. Am I alone with this problem??

It is on the list as an additional feature, but not in the next time, because I am using the module only to send emails.

Here are listed some: