Robin S

This feature sort of exists already, and it's set on the parent template. If a template is allowed to have only a single child template then there is a setting "Name format for children" available on the "Family" tab. Info: https://processwire.com/docs/modules/guides/process-template/ There is a module that extends the feature: But my preference is to just set a date format like "Y/m/d H:i:s" for "Name format for children" and then set the final title/name in a hook to Pages::added, e.g. $pages->addHookAfter('added', function(HookEvent $event) { /** @var Page $page */ $page = $event->arguments(0); if($page->template == 'your_template') { // Set whatever you want the title and name to be $page->of(false); $page->title = "Page ID: $page->id"; $page->name = $event->wire()->sanitizer->pageName($page->title, true); $page->save(); } }); Unfortunately "modified" and "created" cannot be used in a Pages::added hook because these properties are not populated on new pages until the next request. But you could use time(), or subsequently use the modified/created properties to set the title in a Pages::saveReady hook.

@Pete, the reputation count seems to have disappeared (Ryan's is around 20K). Deliberate? Also, the rocket that is poking everyone in the face looks stupid. Can we lose that? Like, what exactly is a "hero" member anyway and does anyone really care about that status? ?

You could edit /site/templates/admin.php so that it looks something like this: // Get the user's IP address $ip = $session->getIP(); // Define the allowed IP addresses $allowed_ips = ['111.111.111.111', '222.222.222.222']; // Check user's IP is allowed if(!in_array($ip, $allowed_ips)) { return 'Access denied'; } require($config->paths->adminTemplates . 'controller.php');

Given how simple FieldtypeRuntimeOnly is, it might be good to avoid the dependency in your module and just render your own markup directly. I haven't looked closely at your module but it just seems like it would make sense to keep it self-contained and avoid any fragility due to the chance that FieldtypeRuntimeOnly changes in the future.

I can't reproduce that. It's showing collapsed => 4 when I dump the field in a FieldtypeRuntimeOnly render file. This module doesn't do anything regarding inputfield visibility so I think your issue must be a general one relating to the PW API rather than specific to this module. Really all this module is doing is rendering a TemplateFile via $files->render(). One thing though... take note of the readme regarding the variables supplied to the render file: I don't know if it relates to your issue but I suggest you avoid overwriting the $field variable by choosing a different name for the field you are getting.

Here's a hook that might help: $wire->addHookBefore('ProcessModule::executeEdit', function(HookEvent $event) { if($event->wire()->input->get('name') !== 'YourModuleName') return; $event->wire()->addHookBefore('InputfieldForm::render', function(HookEvent $event) { /** @var InputfieldForm $form */ $form = $event->object; if($form->id !== 'ModuleEditForm') return; $your_module = $event->wire()->modules->get('YourModuleName'); if($your_module->foo === 'bar') { $uninstall = $form->getChildByName('uninstall'); $uninstall->description('You may not uninstall this module because foo equals bar.'); $uninstall->attr('disabled', 'disabled'); } }); }); Update: an example in the context of your module... public function ready() { $this->addHookBefore('ProcessModule::executeEdit', $this, 'disableUninstall'); } protected function disableUninstall(HookEvent $event) { if($this->wire()->input->get('name') !== $this->className) return; $this->wire()->addHookBefore('InputfieldForm::render', function(HookEvent $event) { /** @var InputfieldForm $form */ $form = $event->object; if($form->id !== 'ModuleEditForm') return; if($this->foo === 'bar') { $uninstall = $form->getChildByName('uninstall'); $uninstall->description('You may not uninstall this module because foo equals bar.'); $uninstall->attr('disabled', 'disabled'); } }); }

In my opinion the best solution would be to use a ProFields Table field because it has less overhead than pages and everything is viewable inside a single compact inputfield. But if you go with a page-based approach (which will be just fine if not 100% optimal) then your options are: Repeater PageTable Child pages Another opinion: purchasing the ProFields bundle should be a no-brainer for any regular PW user. Any one of the Table, Repeater Matrix and Combo fieldtypes alone is worth the purchase price, but you get all of them, plus several more goodies which are just cherries on the top. And as Ryan explained in the most recent blog post, the purchase of Pro modules is an important part of what keeps the ongoing development of PW viable. So it's a nice way to play a part in that. ?

@ryan, regarding the update to ProcessWireUpgrade, could you please add an option to skip this interstitial screen? Because it doesn't add much value and just requires an extra click. If you are visiting the Upgrades page it already implies that you want to load the latest core and module versions to check if there are any upgrades available and the few seconds needed isn't going to be a big deal to you. Thanks.

If you have the "Preset field values from GET variables?" setting checked you can use embed option B (Template Embed) and set field values in a second argument to $forms->embed() echo $forms->embed('your_form_name', [ 'vacancy' => $page->title, 'pageid' => $page->id ]);

If you're seeing an uncaught exception (i.e. an error screen) and have the latest version v4.22.5 Tracy Debugger installed then you might be affected by this issue: https://github.com/adrianbj/TracyDebugger/issues/59 (Update: fixed now in v4.22.6, thanks @adrian) But there's also a core bug that makes the "Move" action appear in Page List in situations where it shouldn't, and I've opened a GitHub issue and suggested fix for that here: https://github.com/processwire/processwire-issues/issues/1394

It sounds like it might be a namespace issue. Check that your template files and included files start with: <?php namespace ProcessWire; FileCompiler tries to automatically fix files that don't declare the PW namespace but I think the most reliable approach is to always add it yourself.

Create a new permission named "page-lister-lister" to signal that you want to have access control over the Find lister. Then you can give that permission to any roles that you want to be able to access the Find lister, and other roles won't be able to access it.

It's working here for me. $config->sessionAllow = true; $config->sessionAllow = false;

Read about the $config->sessionAllow option here: https://processwire.com/blog/posts/multi-instance-pw3/#more-session-control

Very cool, thanks @bernhard and @ryan! Any thoughts about supporting an SCSS version of AdminThemeUikit and customising via an admin.scss file? Uikit offers a Sass (SCSS) version and my impression is that SCSS is more popular than LESS. Google Trends: One person's opinion from 2015: https://www.telerik.com/blogs/why-bootstrap-4-means-sass-has-won It would be interesting to conduct a poll of PW users to see which is the more popular CSS pre-processor.

Rather than being nonsense, it actually tells you exactly what you need to do to fix the situation: But maybe you haven't learned about translations in PW yet so you don't understand. For each language in your site, navigate to Setup > Languages > [your language] and in the "Core Translation Files" field click the "Find Files To Translate" button. Then locate the LanguageSupport.module, click on it to highlight it, and click the "Submit" button. Then locate the "C" item and translate it to the value that should be set via setlocale(LC_ALL, [value]) for that language. Now click "Save".

What sort of field is user_id? If it's an integer or text field that only stores the ID (I assume it is because of the name and way you are getting the user page via the ID) then you should change to a "user_page" Page Reference field that will hold the actual User page object. On the Advanced tab of the settings for the user_page field tick the Autojoin checkbox. That way the User object associated with each portfolio-detail page will automatically be loaded in a single database query when you do... $profiles = $pages->find("template=portfolio-detail"); ...rather than needing multiple database queries within the foreach. In the foreach you will get the field values from the User object like this: echo $portfolio->user_page->firstname;

I just tested here and no problems with either of those things, but it might depend on what panels you have activated. Maybe some JS error in the browser console will give you a clue?

I can confirm, and it seems like a bug. Please open an issue in the repo so that Ryan can investigate.

I think you must have something else going on that's causing the problem, because using a page ID does work in PW v3 and it's included as an example in the documentation. // Get a page by ID $p = $pages->get(1234);

I would question why you are going down the road of a Process module rather than the standard way of entering and storing data in PW, which is via pages and the Page Edit interface. I expect you will want to store the data that your users are entering, and the simplest way to do that is in pages. And when it comes to providing edit forms for that data Page Edit is going to have a lot of advantages: You probably already understand how fields are added to templates and how fields are presented in Page Edit, so there's less to learn. You can add/sort/arrange fields via the admin GUI rather than in code. You get access control for editing out-of-the-box. You can use the full range of PW fieldtypes and inputfields, many of which wouldn't be usable within a Process module (Repeater, ProFields Table, etc). Is there something in particular you are wanting to do that you don't think would be possible via pages and Page Edit?

You can use a hook to AccessByQueryString::replacementMarkup (see the readme for more info) and do a redirect inside your hook, e.g. $event->wire()->session->redirect('/your-login-page/'); I imagine that these pages are subject to view restrictions by role, i.e. you have to be logged in with a particular role to view those pages. The AccessByQueryString module isn't going to override any existing view restrictions you already have in place - it's only going to add additional restrictions. So if you have existing restrictions like that then you'll have to log your users in somehow ($session->forceLogin ?) but then if you're doing that you don't need AccessByQueryString to restrict/grant view access. So probably this module isn't going to suit your use case.

Info: https://processwire.com/blog/posts/introducing-iftrunner-and-the-story-behind-it/ GitHub repo: https://github.com/ryancramerdesign/IftRunner I don't know if it was ever available via the PW modules directory.

The email notifications for subscribed topics now seem to be truncated when they used to include the full post. @Pete, is it possible to change a setting so that emails are not truncated?

The issue occurs because both InputfieldURL and FieldtypeURL put the value through $sanitizer->url(), and by default the "convertEncoded" option is true. It would be good if this option was configurable for InputfieldURL/FieldtypeURL. As a quick fix you could copy the modules to /site/modules/ and edit usages of $santizer->url() to set convertEncoded false, and maybe open a GitHub issue/request to have that added as a configurable option.