LostKobrakai

The automatic page creation must be setup in the module config, otherwise the module cannot know which page it should create where. 'page' => array( 'name' => 'guest-book', 'parent' => '', 'title' => 'Guest Book' )

ProcessModules shouldn't be autoloaded, which means run at every possible request, but that shouldn't be the issue why it's not working.

(Process-)Module access is obviously not determined by template access settings, but real permissions, like 'comments-admin' or 'page-edit'. Without such a permission set in the modules config only superusers can see the process module. With it all users having that set permission can see it. If you need more dedicated permissions than "can access" or "cannot access" you can always check for further permissions on the current user in your code manually.

It depends, getModuleInfo() it not required anymore as the config can also be in a separate file. But somewhere there needs to be a config.

Dates are not saved as text, therefore you cannot use any text based selectors. You'd need to compare them based on date values (timestamps).

Is the $config->httpHosts array correct? If not then processwire will internally rewrite the domain name to something whitelisted.

Repeater pages are not removed from the pagetree. They're just in a place most people don't look for them (inside Admin). I'm with you that this is unintuitive and I'm not sure if it's supposed to be that way. At least superusers are excluded from almost all access or otherwise limiting factors.

Make the pages not viewable for anyone (except superuser) and use the module permission system to limit view access of your dashboard module separately.

This might be interesting to you: https://processwire.com/talk/topic/9320-fieldtype-select-external-option/

Do those show up for both superuser and other users with page-template permission or only for one of those? It should certainly not be that way.

The modules does use standard datetime fields, therefore if other datetime fields do suffer from the same issue it's probably a core issue.

Thanks for your thoughts valan. I can certainly see where you're coming from as I'm working on a similarly scoped project, even if it doesn't currently have anywhere that number of users. I think your first point is quite a thing to get to with processwire and it's philosophy of not deleting / overwriting content without explicitly being told to do it (hitting the save button). Introducing functionality like you're describing would certainly need some kind of core field versioning (maybe even event based). This would also need to be deeply considered with the database performance/choice. Event drive admin sounds fun, but it's also a new hurdle for new comers. With a core js api on the roadmap it might become more easily to implement any custom framework into the admin on your own. If there will be a admin js framework to be introduced I'd rather root for vuejs, which from my perspective does have the greater community and drive behind it. But that's to be determined if it comes to that point. Deeply nested selectors would certainly be a great addition.

Posted this to GitHub, so ryan can look into implementing a warning/error.

Why would you want to update a running system and have the slight chance to break something when there's no need to. If you need any of the newer functionality you're needing that for a new feature anyway, so you're already working on a specific website. Same goes for issues with hosting or own security issues one might have introduced. Only thing I'd say is really interesting is having a central point to initiate things like database optimizations or other less critical maintenance tasks, but that's really up to the dev / agency to create, because everybody would need different things to run in different circumstances. Running updates is certainly the least needed at the current stage of processwire.

There isn't, but also there's not much need for it by now. With none known security issues the need for centralized updates is quite slim. Doing updates just for the sake of it doesn't make much sense.

Look for wireMail or one of it's extention modules here in the forum.

$wire->addHookAfter("Pages::added", function(HookEvent $event){ $page = $event->arguments(0); // Do what you need to do with the page's data }); Put this in e.g. /site/init.php or add it to a module.

In the template's settings is a checkbox to disallow template change for just that single template. Would you please make sure that one isn't checked.

Tabs are cached while building the form, so you're renoving the inputfield, but not the tab for it. There's a function to remove the tab as well in ProcessPageEdit. I'm on mobile, so please look for it on your own.

Columns can also be created with flexbox (flex-flow: column wrap;), which does have far better browser support.

As adrian's answer shows you'll need to save the member page, not the user. The user page just holds the reference to the member page, but the fielddata of both pages are fully unrelated to one another.

The datetime implementation certainly should in my mind. But some system fields like created or alike wouldn't really benefit from a change. Not sure if people already used processwire back then

Yeah, it's because the (form)value of the save button is missing and therefore processwire does not save anything. You could try to hook somewhere before processInput() and add the needed input variable to trigger the save.

InputfieldSelect is a form inputfield like any others, so if you submit a form with the inputfield in it, the selector will be sent. You can then use this selector in the module to select the pages. There's no such thing as a prebuild ajax solution to update without an pagerefresh.

Some profiles do have this code in the _init.php $homepage = $pages->get("/");