LostKobrakai

Which format(s) did you setup for the field to use? Could you check if the dates are also saved wrongly in the db (table field_FIELDNAME)?

The most obvious hook would be after ProcessPageEdit::loadPage, which does load the page, which will be edited or if you also want to manipulate the form itself ProcessPageEdit::buildForm. $wire->addHookAfter('ProcessPageEdit::loadPage', null, function(HookEvent $event){ $page = $event->return; // loadPage() does return the page }); // or $wire->addHookAfter('ProcessPageEdit::buildForm', null, function(HookEvent $event){ $process = $event->object; // get the ProcessPageEdit instance $page = $process->getPage(); // Method in the ProcessPageEdit module to get the edited page (not global) $form = $event->return; // buildForm() does return the form });

The pageimages class is actually keyed by filename, so this is the expected behaviour. To remove the keys and get numbered indexes just use $page->logos->getArray()

All the pages in the backend are admin templates, which hold various process modules, which in turn manipulate or work with other pages. In this case you're just editing an user, but the page you're on isn't the user page, but an instance of ProcessPageEdit on an admin page. Depending on which class and method you're hooking there are different ways on retrieving the actual edited page, which is probably more of your interest. As soon as you've the user object you can just iterate over all available roles and use hasRole() to verify if a user is of that role or not.

I'd suggest updating one version at a time just by replacing the wire folder and the index.php. Then go to the admin, do a module refresh and on to the next version. Also 2.4 should be able to run ProcessUpgrade if I remember correctly.

I've just a small suggestion for the module. How about using the actual color picker in the field settings, where one can choose the default value for the field.

This would make you no better than any ddos botnet, but maybe we can create a crazy performant site, which does log all prevented wordpress login/hack attempts (redirect or via some kind of api). Then a few statistics about it and we've some good marketing material for processwire.

if(!$page->isTrash()){…} A page, which should be trashed, is moved to another parent, which in turn needs to be saved. That's actually intended behaviour.

As long as one does not redirect back to the home.php this shouldn't be an issue.

In your home.php: if($config->httpHost == "domaina.com"){ $session->redirect($pages->get("/asection/")->url); } else if($config->httpHost == "domainb.com"){ $session->redirect($pages->get("/bsection/")->url); }

Your code did miss the r, that's why I asked. Multiple paginations are doable, but you need to make use of the getVars setting and manage the start position of both find calls on your own. function pageStart($limit){ $limit = (int) $limit; if($input->pageNum === 1 || $limit < 1){ return 0; } return ($input->pageNum - 1) * $limit; } $limit = 15; $first = $pages->find("…, limit=$limit, start=" . ($input->get->first ? pageStart($limit) : 0); // Will be merged to form getVars // If you don't otherwise use the feature to ship e.g. filter settings to paginated pages // you could also directly manipulate the getVars via the pager settings. $input->whitelist("first", 1); // generate pagination 1 $limit = 12; $second = $pages->find("…, limit=$limit, start=" . ($input->get->second ? pageStart($limit) : 0); $input->whitelist("second", 1); $input->whitelist("first", 0); // generate pagination 2

LazyCron does execute all codes it should execute independent on which page is visited, so that's certainly not the issue. But you're missing all the offsetFormatting false calls.

renderPager() ? Edit: And you need to enable pagination for the template you're adding the pagination to and not the templates you want to paginate.

You could have this in a single selector like so: $tables = $pages->find("fcheckbox=1, parent=[parent.name=pricing]");

Something like that? $children_of_price_lists = $pages->get("parent=[has_parent=/pricing/, template=pricelist], my_checkbox=1");

Here's how you activate all languages for a page: https://processwire-recipes.com/recipes/activate-all-languages/ I like the idea for a language subselector, but there's always the chance of collision with other subfields as language names are arbitrary and there's no support for something like title.lang.de yet.

FormBuilder was actually developed before all the multi language tools came to processwire and if I recall correctly Ryan by now does suggest to create a form per language if you need different languages. And you've always the option to use page inputfields, too. Also there weren't many request for full multilanguage form support at least in the module's support forum; which is also the more appropriate place to express your critic.

On github there's the branch devns, which holds all the 3.0 changes: https://github.com/ryancramerdesign/ProcessWire/tree/devns

ProCache does skip PHP all together and goes directly from htaccess to the cached html, therefore it doesn't honor anything, if you do not set it up to reset the cache properly on the needed status changes.

For that page ProcessUser is inheriting the usage of a customized Lister from ProcessPageType, so you probably need to hook some of the ProcessPageType::execute… methods.

ProcessPageEdit::buildForm is most likely the hook you want to use if you want to add things to the page edit form.

ProcessUser is the module, which handles this section of the admin, and it does by itself use ProcessPageEdit for the user editing, so you'll probably don't need different hooks, but just a check if the current edited page is a user.

Did you add the html entity encoder?

I'd say it's not without modifying the module. $page->seo is an raw data object, where render is not actually a function, but already the prerendered result of the rendering logic.

Ah, same goes for the permission that's installed with the module.