Leaderboard

There are several updates on the dev branch this week (commit log), including issue fixes, feature additions and minor class improvements. One of the updates I'd planned to add this week was moving InputfieldTinyMCE into the core. However, I noticed that TinyMCE was up to version 6.4.1 now and we were still running 6.2.0, so I decided instead to upgrade ours to the latest and test it out for another week in its own repository. If all continues to work well, I'll likely commit it to the core in 3.0.215. If you have a chance to test the latest version of InputfieldTinyMCE, please do, and open an issue report if you run into any trouble. Last week the Wire Request Blocker module was released in the ProDevTools board and this week we have version 2, which includes several new additions: Added support for blocking groups. Added configurable settings for immediate block (rather than just a strike) for URLs and user agents. Added support for using RequestBlocker in other applications (like we use it here in IP.Board). Added a feature were you can manually test URLs or user agent strings to see how they match your rules. Added a configuration setting so you can choose whether or not to use a log file. Added a section to the docs on how to block URLs from your .htaccess file. As I wrote this post, the processwire.com site is getting hounded with dozens of IPs trying to locate backup or database zip/rar/tar/gz files, using every possible combination of filenames and extensions you can think of, including those that include the term "processwire". Remember to never leave backup files or DB dump files accessible by URL lying around on your server, because they will get eventually found. Adding these rules (below) to WireRequestBlocker's URL matching rules seems to mostly stopped those DB/backup hunting bots: /ba=/backups/|/backup/|/bak/|/back/ .txt=credentials.txt|backup.txt|password.txt|passwords.txt .sql=.sql.gz|.sql.tar|backup.sql|dump.sql|db.sql|database.sql|mysql.sql|.com.sql .tar=.tar.gz|.tar.sql|dump.tar|backup.tar|bak.tar|website.tar|backup.tar|www.tar .zip=backup.zip|bak.zip|.com.zip|well-known.zip|index.zip|public_html.zip|website.zip|dump.zip|wallet.zip|application.zip .rar=bak.rar|website.rar|backup.rar|www.rar .gz=website.gz|bak.gz|backup.gz|.com.gz /old/ WireRequestBlocker only knows its rules and doesn't know who's real and who's a bot, so be careful not to hit URLs containing those strings on this site or it might hit you with nothing but 403's for a few hours. ? Next week is Spring Break here, so I'll likely be on a reduced schedule with kids home from school. Thanks for reading, have a great weekend! +75 more blocks (not shown)

Another way you could do it... In my example the parent template is "countries" and the child template is "country", and there are 195 child country pages. Using the PageEditPerUser module the user is only allowed to edit country pages "Zambia" and "Zimbabwe": Page List before: The problem being that lots of uneditable pages are included, with the two editable pages being at the end of the 4th pagination. I'm not using Admin Restrict Branch here so (presumably) that's why all the non-editable pages are listed, but that doesn't matter for the purposes of this example. A solution is to add the following hook to /site/ready.php: // Only for a particular role if($user->hasRole('editor')) { $wire->addHookBefore('ProcessPageList::find', function(HookEvent $event) { $selector = $event->arguments(0); /* @var Page $page */ $page = $event->arguments(1); $user = $event->wire()->user; // If the parent template is "countries", restrict the children list to only the pages that the user may edit if($page->template == 'countries') { $selector .= ", id=$user->editable_pages"; $event->arguments(0, $selector); } }); } That fixes it so that only the editable child pages are shown, but the incorrect child count and unnecessary pagination controls are still visible: So the simplest thing is just to hide those things with some custom admin CSS only for the relevant role (if you're not sure how to do that something like this should work, with a check first for the user role). /* Adjust the parent template name to suit */ .PageListTemplate_countries > .PageListNumChildren { display:none; } .PageListTemplate_countries + .PageList > .uk-pagination { display:none; } .PageListTemplate_countries + .PageList > .PageListActions { display:none; } End result:

A module for ProcessWire CMS to integrate a user registration/login functionality based on the FrontendForms module. This module creates pages and templates during the installation for faster development. The intention for the development of such a module was to provide a ready-to-use solution for user management, which can be installed and put into operation in a few minutes. It works out of the box, but it provides a lot of configuration settings in the backend: Highlights "One-click" integration of an user login/registration system without the hazzle of creating all pages and forms by hand "One-click" switch between login or login and registration option Double opt-in with activation link on new registrations Option for automatic sending of reminder mails, if account activation is still pending Option for automatic deletion of unverified accounts after a certain time to prevent unused accounts Option to use TFA-Email if installed for higher security on login Mutli-language Select if you want to login with username and password or email and password Select the desired roles for newly created users Select, which fields of the user template should be displayed on the registration and profile form (beside the mandatory fields). Fields and order can be changed via drag and drop functionality Offer users the possibility to delete their account in the members area using a deletion link with time expiration Customize the texts of the emails which will be send by this module Usage of all the benefits of FrontendForms (fe. CAPTCHA, various security settings,...) Support for SeoMaestro if installed Lock accounts if suspicious login attempts were made Support of Ajax form submission This module runs on top of the FrontendForms module, so please download and install this module first. UPDATE 03.11.2023: The module is now available inside the Processwire modules directory: Frontendloginregister This module is early Beta stage, so please do not use it on live sites at the moment. If you discover any issues, please report them directly on GitHub ?. Thanks!

TextformatterFootnotes Github: https://github.com/eprcstudio/TextformatterFootnotes Modules directory: https://processwire.com/modules/textformatter-footnotes/ This textformatter adds footnotes using Markdown Extra’s syntax, minus Markdown About This textformatter was primarly created to ease the addition of footnotes within HTML textareas (CKEditor or TinyMCE) using Markdown Extra’s syntax. It will also retain any inline formatting tags that are whitelisted. Usage To create a footnote reference, add a caret and an identifier inside brackets ([^1]). Then add the footnote in its own line using another caret and number inside brackets with a colon and text ([^1]: My footnote.). It will be put automatically inside the footnotes block at the end of the text. Notes: the identifier has to be a number but it is permissive in that you can put in the wrong order and it will be numbered back sequentially there is no support for indentation, though since <br> tags are allowed you should be fine if a footnote has no corresponding reference, it will be ignored and left as is Options In the module settings, you can change the icon (string) used as the backreference link but also the classes used for the wrapper, the reference and backreference links. You can also edit the list of whitelisted HTML tags that won’t be removed in the footnotes. Hook If you want to have a more granular control over the footnotes (e.g. per field), you can use this hook: $wire->addHookBefore("TextformatterFootnotes::addFootnotes", function(HookEvent $event) { $str = $event->arguments(0); $options = $event->arguments(1); $field = $event->arguments(2); if($field != "your-field-name") return; // Say you want to change the icon for a <svg> $options["icon"] = file_get_contents("{$event->config->paths->templates}assets/icons/up.svg"); // Or change the wrapper’s class $options["wrapperClass"] = "my-own-wrapper-class"; // Put back the updated options array $event->arguments(1, $options); }); Check the source code for more options.

Not a problem, this time, but an FYI and a solution in case anybody needs it. When using a Dynamic Options field as an images/files custom field, the 'page' value of 'arguments(0)' is not the page being edited, but instead it's a dummy page used for the 'field-fieldname' template. If the actual page is required for some logic (a need I had), then this poses an issue... but there is a solution! In your 'getSelectableOptions' hook, do the following: $wire->addHookAfter('FieldtypeDynamicOptions::getSelectableOptions', function(HookEvent $event) { $page = $event->arguments(0); // Page data (which will be wrong for our specific use case) $field = $event->arguments(1); // Field data // 'foo' is an images custom field if ($field->name === 'foo') { /* Get the page -- where we get page from will be different in the admin (edit) and frontend.*/ $page = $this->page; // the current page route (sufficient for the frontend) /* However, in the admin edit page (check the process) */ if ($page->process === 'ProcessPageEdit') { // Get the id of page being edited from $input and then use that to fetch the page $page = $this->pages->get($this->input->get('id', 'int')); } $options = []; // empty array to return if no valid page is found // If it is a valid id... continue as usual, using the $page var if ($page->id) { if ($page->template->name === 'gallery') { $options = ['foo' => "Foo", 'bar' => "Bar"]; } else { $options = ['lorem' => "Lorem", 'ipsum' => "Ipsum"]; } } $event->return = $options; } // ... other fields as required can use the $page from args }); No idea if there is a different way, but this method is fairly simple, besides, it's not going to be a common issue. Hope this helps somebody. Here's the Tracy dump of the custom field "page" for the curious: ProcessWire\DefaultPage id: 0 name: '' parent: '' status: 'corrupted' template: 'field-images' caption: '' foo: => '' data: array 'caption' => '' 'foo' => ''

Hey @gornycreative, Great write-up, insights and suggestions! This is very inspirational! It is going to be very helpful, thanks!

Test the solution below if it fit your needs : if ($user->hasRole('testrole')) { // $ap = $user->editable_pages[0]->id; //there is always only one page // $wire->addHookBefore('Page(id!=' . $ap . '|1023)::listable', function ($event) { //1058 is the id of the parent page // $event->return = false; // }); // ? // get the parent id of the user's editable page $parent_id = $user->editable_pages[0]->parent_id; //there is always only one page $this->addHookBefore('ProcessPageList::execute', function (HookEvent $event) { // hide root (/) page in list (optional) $event->object->showRootPage = false; // limit number of pages shown - that's the trick to avoid pagination in the lister $event->object->limit = 100; // you might need to adjust this value }); $this->addHookAfter('ProcessPageList::execute', function (HookEvent $event) use ($parent_id) { // run only on ajax requests if ($this->config->ajax) { // manipulate the json returned $json = json_decode($event->return, true); // remove any pages that are not editable or addable and not the parent page foreach ($json['children'] as $key => $child) { $p = $this->pages->get($child['id']); if (!$p['editable'] && !$p['addable'] && $p['id'] !== $parent_id) { // remove the page from the json unset($json['children'][$key]); } } // set the json back to the event $json['children'] = array_values($json['children']); $event->return = json_encode($json); } }); }

I'm also reusing generic fields in my templates with renamed labels. Keeps the DB cleaner. I use custom page classes, a great feature that was introduced in 3.0.152 to map those generic field names to more meaningful properties. This way I get intellisense in my editor and don't have to look up the mappings of generic field names to meaningful ones. Here's an example page class: <?php namespace ProcessWire; use RockMigrations\MagicPage; /** * Custom page class that provides properties/methods for pages with template glossary-item * * */ class GlossaryItemPage extends DefaultPage { use MagicPage; /** * holds the glossary term * * @var string $term */ public $term; public $hide; public $exclude; public $tooltip; public $meaning; public $description; // set custom properties in loaded public function loaded() { $this->set('term', $this->title); $this->set('hide', $this->checkbox); $this->set('exclude', $this->checkbox2); $this->set('tooltip', $this->text); $this->set('meaning', $this->text2); $this->set('description', $this->rte); } /** * Magic Page hook for clearing cache for terms from module Glossary * */ public function onSaved() { $this->wire->cache->delete(Glossary::CACHE_NAME); } } The property->fieldname mapping happens in the loaded() method. you can comment the property definitions so you get some meaningful info with code intellisense. In the template where I want to use pages with template glossary-item, I define the type for those pages to get intellisense: /** @var GlossaryItemPage $p */ <?= $p->term ?> Some notes on the page class code: The GlossaryItemPage extends DefaultPage. My DefaultPage class is a base class for all other page classes which holds generic methods that I want to have available in all page classes I'm using @bernhard's fabulous RockMigrations module which, apart from migrations, provides MagicPages. This makes it super easy to add commonly used hooks to your page classes. I have a Glossary module installed which handles migrations and logic for the glossary. In the migrations for that module I define the custom field labels in the template context: 'glossary-item' => [ 'fields' => [ 'title' => [ 'label' => 'Name of the Term', ], 'checkbox' => [ 'label' => 'Hide', ], 'checkbox2' => [ 'label' => 'Exclude this term from parsing', ], 'text' => [ 'label' => 'Text Shown in the CSS Tooltip', ], 'text2' => [ 'label' => 'Meaning', ], 'rte' => [ 'label' => 'Description of the Term', ] All in all this is a very structured approach. It surely takes some extra time to setup. But this pays back, especially for larger, more complex projects. It took me quite some time as PW developer to come to this kind of setup. I started out with very simple procedural code. I wish I had all these tools available when I started out developing with PW that we have now (page classes, migrations etc.) thanks to this great community. Everyone here has their own approach and workflow. So you will surely get some inspiration.

With a bit of hooking it is possible to both dynamically control the selectable pages for a PageAutocomplete inputfield, and dynamically set the parent/template of new pages created from the inputfield. I have only played around with this and haven't used it in production, so use it at your own risk. Dynamic selectable pages for PageAutocomplete The idea is that in the field settings you define a broad selector that includes all of the pages you might want to select. It could be something really broad such as "has_parent!=2". Then you modify the selector in a hook according to the page being edited. In /site/ready.php... $wire->addHookAfter('Field::getInputfield', function(HookEvent $event) { $field = $event->object; $inputfield = $event->return; // Only for this one Page Reference field if($field->name !== 'test_page_field') return; // Only for ProcessPageEdit if($this->process != 'ProcessPageEdit') return; $page = $this->process->getPage(); // Get findPagesSelector (or findPagesSelect if you used that) $selector = $inputfield->findPagesSelector; /* Now append to or overwrite $selector however you like, depending on $page maybe. You can even define some $allowed PageArray like with the "Custom PHP code" option that is possible with other Page inputfields, and then use it in the selector as "id=$allowed". But note that there is a 500 character limit enforced on selectors. */ // Set the modified selector back to the property you got it from $inputfield->findPagesSelector = $selector; }); Dynamic parent and/or template for pages created from the inputfield The idea is that in the field settings you do not define a parent or template for allowed pages, but then set these properties in a couple of hooks according to the page being edited. In /site/ready.php... $wire->addHookBefore('InputfieldPage::renderAddable', null, 'dynamicParentandTemplate'); $wire->addHookBefore('InputfieldPage::processInputAddPages', null, 'dynamicParentandTemplate'); function dynamicParentandTemplate(HookEvent $event) { $inputfield = $event->object; // Only for this one Page Reference field if($inputfield->hasField->name !== 'test_page_field') return; // Only for ProcessPageEdit if(wire()->process != 'ProcessPageEdit') return; $page = wire()->process->getPage(); // Now set $parent_id and $template_id dynamically depending on $page $parent_id = 1234; // demo value $template_id = 56; // demo value $inputfield->parent_id = $parent_id; $inputfield->template_id = $template_id; } Have fun!