Leaderboard

Fridays are always the days when I'm full-time on ProcessWire. Other days I may be doing client work, or ProcessWire, just depending on the week. This week it's been mostly client work. And I just learned that I'll have to be out of the office tomorrow (Friday) for a family commitment. So I'm writing this weekly update today instead, and just sent out Teppo's great ProcessWire Weekly newsletter with ProMailer today (usually it gets sent Friday). Because of this change in schedule, I don't have much new to report just yet. Instead, I wanted to start talking a little about future plans, so here's a few ideas. I think we should get another main/master version out, perhaps by September. Following that, I thought we should focus on ProcessWire 3.1, or maybe it's time for version 4. What would be in this next major version of PW? For starters, we'll finally drop support for older PHP versions and start taking advantage of all that's been added new newer PHP versions (8+). This will involve lots of updates to the ProcessWire core code base, while remaining 100% API compatible with PW 3.x. I thought that would be a good starting point into our next major version at least. In addition, we'll likely be trimming some things out of the core and into separate non-core modules, such as FileCompiler, CKEditor, the two legacy admin themes, and a few rarely used Textformatter modules. Most likely we'll also have an overhaul of this website and some nice improvements to our primary (Uikit) admin theme to accompany the next major version as well. There will be plenty more too, but this is what I've been thinking about so far. Your feedback is welcome. Thanks for reading and have a great weekend!

Thank you very much, that fixed it @Juergen

Hello @dotnetic Could you please update FF to 2.2.9. The bug should be gone now. Best regards Jürgen

I would say the easiest is to add an "edit bookmark" to this page, it requires no module or hook nor moving the page in a specific location. Go to modules page Click the tab Configure Find the module Page Edit and click Configure Check to enable bookmarks Go to menu Pages > Edit > Bookmarks Add the bookmark for your page with the corresponding user role (select everyone if no specific role is necessary) Now you can access this page with menu Pages > Edit > Your page

To have your page shown in the admin menu, you have to have it under the /admin/ page. Move it there, reload, and you should see "Settings" in the menu bar. Edit: actually it's not that simple as the url in the menu is not the one to edit the page! My bad! Let me check for a fix

I thought I would share this as I am finding it increasingly useful and am often using it to replace the standard PW modal. It allows display and customisation of admin page in front end as well as back end via a modal. In the modules library at https://processwire.com/modules/admin-in-modal/ . Also here https://github.com/MetaTunes/AdminInModal This module provides a Page hook method ($page->aim($array)) for front-end use and a similar Inputfield hook (for back-end use) to render a link to a lightbox modal containing an admin page. Optionally, class styling can be passed, otherwise default button styling is supplied. Full list of options and defaults for the array is : 'href' => null, // the url for the linked page (including any required GET params) 'text' => '##', // the text that will appear in the link 'class' => "uk-button uk-button-primary", // any suitable styling for an <a> tag 'width' => '90%', // size for iframe 'height' => '95%', 'header-text' => 'Save required changes before closing -->', // Text to appear above top left of modal 'save-head-button' => '1', // Adds a save button at the top of the modal. Set to '0' to omit. 'suppress-notices' => 'messages', // e.g. null/[]: no suppression, 'messages': suppress messages, 'warnings messages': suppress warnings & messages, 'errors': suppress errors 'close-button' => '1', // set to '0' to remove close button (but you'd better be sure you know how the modal will be closed!) 'redirect' => '.', // url to redirect to after closing the modal - default is to reload the current page (use redirect => '' to suppress) (From v0.3.0, these defaults can be configured in the module settings). For front-end use, the lightbox will only be rendered if the page is editable by the current user. Configure editability of the page by calling a hook after User::hasPagePermission The lightbox is provided by the Magnific popup, which is in the PW core. Although I have used it quite a lot, I cannot say that it has been fully tested, so is alpha at this stage and should be used with care. It is the user's responsibility to check that it suits their needs. Because it allows access to the admin back-end, particular care should be taken to restrict page-edit access.

That's great @bernhard thanks! All now working as expected!

Hello @dotnetic This is weired, because I do not have changed something like that ?. I will check this and try to add a fix today. Thanks for reporting this issue. Jürgen

Hello @Juergen since the update to the newest version I get extra br elements in a vertical radio button list. That looks ugly, is there any way I can prevent them? Thank you for all the other additions. I think I will need field dependencies in the future.

It worked! Thanks you!

Interesting... I would've thought that HTMX could be an issue. We have ProCache enabled for every page, but we still get page views. When opening a private tab and clicking through our site I can see every click I made in the Dashboard. So I am genuinely confused on how it would not work on your end. When automated page view tracking is enabled, we're writing the page view inside the modules ready function. This should fire on every page load, as the module is being autoloaded. Do you see an issue here?

Hello @marie.mdna I hope I have fixed the problem now ?. For testing purposes I have added the profile form inside segment 2 so it was reachable under /profile/segment1/segment2. After form submission it redirects successfully to the same url (on success and error) - so everthing works fine. I have tested it on a single and a multi-language site and with/without Ajax. On my local installation it works as expected. So please update FrontendForms to 2.2.8 and FrontendLoginRegister to 1.3.4 and let me know if it works for you now. Best regards

Hello @marie.mdna You are right, it does not work inside url segments. The failure is inside the form action attribute and/or the redirects which does not recognize the segments after the url, so every redirect leads to the base url instead of the base url including the segments. I try to fix this now!

I'd like to second this. It would be great if the new/improved admin theme was built with maximum customisability in mind. One use case is so that we can more easily offer a "mostly-frontend" user an admin experience that's radically different to what a superuser or site administrator gets in the uncustomised admin. Another admin customisation issue I've struck recently is when you want to customise markup for InputfieldWrapper. There's InputfieldWrapper::setMarkup() but this is marked as internal and isn't that practical to use because InputfieldWrapper::markup is static. That means any custom markup you set there persists for all InputfieldWrappers that are subsequently rendered, when what I want to do is customise markup for a specific instance of InputfieldWrapper. Edit: pull request When the admin theme is revisited it would be great to ask of each component that's rendered, "Is there an opportunity to make this rendering customisable?"

I think the most talked about feature is an asset manager. The drilling down of file and imagefields so that you can choose assets from a global library that have already been uploaded somewhere, instead of having to upload assets multiple times. Actually, the approach using references is the best I've come across so far. The data remains where it was originally uploaded, but is only referenced in a file/image field on another page.

Hello @marie.mdna Here is the code that should make what you want: $form = new \FrontendForms\Form('myform'); $form->setSuccessMsg('<div class="success"><h2>Everything is fine</h2></div>'); // some more inputs ...... $file = new \FrontendForms\InputFile('fileupload'); $file->showClearLink(true); // show an link to empty the input field under the input field $file->setLabel($page->p_title); $file->setDescription('<span>'.$page->p_upload_label.'</span>')->setPosition('beforeLabel'); // $file->setNotes('Description fileupload notes'); $file->setRule('allowedFileSize', '60KB'); // you can use the unit, if you want $file->setRule('allowedFileExt', ['jpg','png']); $file->setRule('uniqueFilenameInDir', true); $file->setSanitizer('pageName'); // set sanitizer $form->add($file); $button = new \FrontendForms\Button('submit'); $button->setAttribute('value', 'Send'); $form->add($button); if ($form->isValid()) { // save the content as page $p = new Page(); $p->template = $form->getValue('newPage'); $p->parent = wire('pages')->get('template=parent'); $p->title = $form->getValue('title'); if($p->save()){ $destPath = wire('config')->paths->assets.'files/'.$p->id; // the path to the destination directory foreach($form->getUploadedFiles() as $file){ wire('files')->copy($file, $destPath);// copy the file to the new folder wire('files')->unlink($file);// remove the file from the old folder } } } echo $form->render(); A little bit information about the code: First of all, add the sanitizer "pageName" to the file input field instead inside the foreach loop You can set the max filesize now using units (so instead of writing allowedFileSize('60000'), you can write allowedFileSize(60KB) which is more handy I think. This is relatively new and I have added it a few versions before - but it is not wrong if you enter the value in Bytes ?. To get all uploaded files use the getUploadedFiles() method, which outputs only the file paths of the currently uploaded files. You can use the file paths for the next steps to move the files to another directory The copy and unlink methods are PW methods and they are the best way to move files to another directory. Hope this helps!

Since ProcessWire v3.0.152 we have been able to use custom Page classes: https://processwire.com/blog/posts/pw-3.0.152/#new-ability-to-specify-custom-page-classes Some PW users have said that they would like to have all their hooks relating to a particular Page class contained within their custom Page class file (in /site/classes/), to keep things tidy and organised. But custom Page classes do not have methods that fire on states like "init" or "ready", and it also wouldn't be ideal to attach hooks within a Page class because the class can be instantiated multiple times and therefore such hooks would be attached multiple times. I understand @bernhard has a feature that addresses this need built into his RockMigrations module, so check that out. And here's another approach, where hooks are attached in the places where you would normally attach them (e.g. in /site/ready.php or /site/init.php, or in the init() or ready() methods of some custom module) but the method that executes in the hook exists within your custom Page classes. Step 1 In /site/classes/DefaultPage.php, add the method shown below: class DefaultPage extends Page { // Call any Page methods with names that match the HookEvent object and method public function callHookMethods(HookEvent $event) { $objectName = $event->object->className; $methodName = $objectName . '_' . $event->method; if(!method_exists($this, $methodName)) return; $this->$methodName($event); } } This method looks for other Page method names that match the HookEvent object and method and if any exist it calls them. Hooks are attached using the format "Class::method" and this format wouldn't be valid for a method name, so an underscore is used instead of the two colons. E.g. "ProcessPageEdit::buildFormContent" would become "ProcessPageEdit_buildFormContent". Step 2 In any of your custom Page class files, add methods named to match the hookable methods you want to target. These custom Page classes should extend DefaultPage. In the example below I'm targeting hookable methods Pages::saveReady and ProcessPageEdit::buildFormContent in the BasicPagePage class. class BasicPagePage extends DefaultPage { public function Pages_saveReady(HookEvent $event) { // Show a message in the PW admin $this->wire()->message("About to save page named: $this->name"); } public function ProcessPageEdit_buildFormContent(HookEvent $event) { /** @var InputfieldWrapper $wrapper */ $wrapper = $event->return; // Add a custom markup field to Page Edit /** @var InputfieldMarkup $f */ $f = $this->wire()->modules->get('InputfieldMarkup'); $f->label = 'My custom markup'; $f->value = 'Hello!'; $wrapper->insertAfter($f, 'title'); } } Step 3 Attach hooks in the places where you normally would. You need to attach a hook for each hookable method you are targeting in your custom Page classes, but the hook code itself is minimal and where multiple Page classes target the same hookable method you only need it attach it once. In the example below I'm attaching hooks in /site/ready.php. $pages->addHookAfter('saveReady', function(HookEvent $event) { /** @var DefaultPage $page */ $page = $event->arguments(0); if($page instanceof DefaultPage) $page->callHookMethods($event); }); $wire->addHookAfter('ProcessPageEdit::buildFormContent', function(HookEvent $event) { /** @var ProcessPageEdit $ppe */ $ppe = $event->object; /** @var DefaultPage $page */ $page = $ppe->getPage(); if($page instanceof DefaultPage) $page->callHookMethods($event); }); Each hook only need to establish a $page object (often this is available as an argument to the hookable method) and if it's an instance of DefaultPage then it simply calls $page->callHookMethods($event), and any relevant hook-targeting methods for that particular Page class will fire. Here's the result of my two hook-targeting methods in BasicPagePage.php when I save a page of this class in Page Edit:

Hi @Robin S. Please also take a look at my request "automatically call the init method on custom page classes" https://github.com/processwire/processwire-requests/issues/456 and maybe leave a thumbs up. Your method requires changes to /site/ready.php or /site/init.php files. I think self-initiating custom page files are way better, so for example, a blogPage.php custom page class file would automatically create all fields and provide custom methods like `localDate`. This way, you can simply copy the file to a new project, and everything will be set up automatically without needing additional changes to other files.

Hi everyone, quick question: Using the form API, is there a way to render a standards compliant <fieldset> <legend>Legend</legend> /* some input fields */ </fieldset> construct (for use in a frontend form)? Whenever I use $fieldset = $modules->get('InputfieldFieldset'); $fieldset->label = 'About You'; [add a bunch of fields, add them to the fieldset, add the fieldset to the form] not only does the fieldset get somehow mangled in divs, I also don't get a html legend element. I tried using $modules->get("InputfieldMarkup"); and construct the fieldset/legend myself, but that ends up with <div> <fieldset> <legend>Legend</legend> </div> I searched the forum, but only found some similar questions and no real answer (unless I missed it, which is entirely possible )