Leaderboard

I hope that you all are having a great week! This week I've been working on some updates to the User Activity module and have released version 5 in the ProDevTools board. This version focuses on adding several new requested features, including the following: New options to also detect when you (yourself) are editing the same page in 2+ windows and when you have modified a page in a different window. These are the “collide-self” and “modify-self” options in module config. The module now keeps track of what fields have changed in the page editor and stores them with the activity so that they can be shown in the activity viewer or in page edit alerts. When a page has been modified that is also open to another user it now presents them with a dialog giving the option to reload the page or keep editing. A new “lock” option has been added that blocks a user from editing a page when it is already being edited by another. This is an alternative to just warning them with a pop-up, and it literally prevents them from being able to open the page in the page editor. This can be enabled in the module config and can also be optionally disabled for superuser. A new configuration setting has been added that lets you configure the refresh time in the page list (previously it was not editable). Added feature to limit the “you've been idle for awhile…” to the page editor only. When enabled, idle is still tracked for other admin processes, but idle alerts don't appear. Improvements to ProcessUserActivity (the included activity viewer module), including: 1) visible vs. hidden states are now more obvious. 2) Changes made in page editor are now included in the activity information. 3) The ajax drop-down navigation summary has been improved to include more information. Large portions of the module have been refactored into separate classes for better maintainability and other related improvements. This week there have also been a few commits to the core, but mostly just small fixes and phpdoc improvements, so not enough to write about here, but there likely will be next week. Thanks for reading and have a great weekend!

v0.2.0 of the module is released, which is a fairly major update that brings support for Repeater, FieldsetPage and Repeater Matrix fields. Using the "Field widths" field you can quickly set the width of inputfields within a Repeater/FieldsetPage field or within each Repeater Matrix type. Repeater: Repeater Matrix:

Modules Directory: https://processwire.com/modules/rock-frontend Github: https://github.com/baumrock/RockFrontend

The problem here is that $pages->get() can return either a Page or a NullPage. NullPage is a null object that (in terms of API usage) behaves like a Page, but doesn't have any content, and doesn't actually match any page on the system. Thus you can't delete a NullPage. NullPage doesn't have an ID, so here's one way you can solve this, checking for an object with an ID: public function ___uninstall() { // ... $dashboard = wire('pages')->get('/admin/kiosk_dashboard/'); if($dashboard->id){ $dashboard->delete(); } // ... } Edit: just for the record, admin pages can be renamed or moved, so keep in mind that at least technically your uninstall routine may leave "orphaned" pages behind. In case your dashboard page uses your Process module as it's process, here's what you could do instead of relying on the path/name always being /admin/kiosk_dashboard/: public function ___uninstall() { // ... $module_id = wire('modules')->getModuleID($this); $dashboard = wire('pages')->get('template=admin, process=' . $module_id); if($dashboard->id){ $dashboard->delete(); } // ... }

Check out the Options Fieldtype. Sometimes I find a page ref field is better than an Options field - easier to add/change. It depends whether this is something that needs to be flexible or not.

Hi @HMCB Currently it is not so easy to provide an default value option for number fieldtypes other than Integer, because all core number Inputfieldtypes using the same rendering function: InputfieldInteger::render(), converting any init or default value to int. So currently there is no option to define default values with decimal places. The core InputfieldFloat and / or InputfieldInteger needs an update to allow default values with decimals. In a second step number fieldtypes could include an option to define a default value. I wrote a Module as a workaround until the core issues are fixed. https://github.com/kixe/FieldtypeDecimalPlusDefault

v1.13.5 adds notes about installed profiles thx to issue report from @wbmnfktr

Thx @wbmnfktr the issue is fixed in version 1.13.3 I've also added the first WIP version of seo support ? <head> <meta charset="UTF-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <?= $rockfrontend->seo() ->title("{$page->title} | My Company") ->description(function($page) { if($page->template == 'foo') return $page->foo; return $page->body; }) ->setValue('og:image', function($page) { if($page->template == 'boat') return $page->boatpic; return $page->images; }) ?> </head> Tags can easily be set and truncation is as easy as adding an integer to the tag {value:160}

I figure this is an off topic board among friends here (like our pub, or a real one) and it’s okay to write with honesty and engage in spirited or sometimes heated conversation. So just want to be clear that I like and respect @MoritzLost and value his opinions, even if I don’t agree with all of them. We will all have a diversity of views and everyone should feel free to share them, and likewise others should feel free to question those or state their own, which is what I’m trying to do. But I’m glad MoritzLost shares his opinions here. Plus, a little controversy also helps to engage the community, and drags me out of the code for a bit, so I can’t fault anyone for that. Once I can state my thoughts, I carry no concerns, but thought I should defend the things that deserved defending, as I always should. As a caretaker of this project, part of my responsibility to add my honest point of view to a conversation like this, especially when something is posted where I don’t fully agree. I think many in our community know the subjectivity of statements here (whether OP’s, mine, or another’s), but an equal number may not, as this is a public board. So some counterpoint or back-and-forth is not only clarifying to the larger audience, but also useful, as we explore different facets of it all, and lead to the most important takeaways. I appreciate that MoritzLost continues to defend his point of view on parts, despite my own defense or heated questioning of those parts. It helps me to better understand and know which are the parts that he thinks are most important and deserve the attention. We obviously don’t have the resources to pursue everything Craft does, so narrowing in on the most important parts—the meat of it—is helpful here. I’m traveling right now so can’t participate as much as I’d like to at the moment but just didn’t want MoritzLost or anyone else to think I was angry or something. Likewise I didn’t want anyone else to think they had to moderate themselves either. When I’m among friends I feel comfortable to express and be honest, and so should you. If you get a heated reply from me it’s because I care about it and value your opinion. I’ll spend more time reading everything when I get back, but I can see already it’s a good and helpful discussion.

@Denis Schultz FormBuilder already has something like this feature in that it supports partial entries. But this FormAutoSaver does go quite a bit further in that it auto-saves as you type and it emails reminders to the user. FormBuilder auto-saves on paginations instead. Maybe it should be released in the FormBuilder board too. It's kind of a developer tool in that it takes a little code to implement into a form (while FormBuilder does not), so I was thinking ProDevTools was a good fit. But I'll either add a similar capability in FormBuilder or make this module available for FormBuilder users. For FormBuilder, I'll want to figure out how to make it an automatic option you can enable rather than one that you have to insert additional code for.

Hi Ryan, as i read the first lines, i thought it would be a nice add-on for FormBuilder. Special in Combination with Page Break on larger Forms. Why it stick for you better in ProDevTools instead?

$page->files->deleteAll(); $page->files->delete($pagefile); $page->images->removeAll(); // wirearray $page->save(); http://cheatsheet.processwire.com/?filter=filesdelete