Leaderboard

This week we've had a mixture of core updates and more work on the PageAutosave/LivePreview module. In the core we have mostly maintenance updates and issue resolutions. I'm not going to bump the version number this week as I'd like to get a bit more added to this version first. One feature request that appears in the core this week is the ability to specify colors for RepeaterMatrix item types (idea from @Ivan Gretsky). If you have any version of RepeaterMatrix and you use the current core dev branch, you can specify the background color for any repeater item type by placing a color hex code in the repeater type label (like at the end of it, but wherever). For instance, typing in #777777 (or just #777) would make the repeater items of that type have a grey background rather than the default color background. Though whatever color you choose, note that the text color is white, so don't choose too light of a color. (The hex color code is of course removed from the item labels.) The PageAutosave and LivePreview module also got several updates this week, bringing it that much closer to being production ready: Added support for automatic detection of best placement for live preview window position based on available space. It will choose the correct location and size either to the right, left, above or below your page editor window. Added support for remembering live preview window position in a cookie. So if you setup your preferred layout for editor window and live preview window, ProcessWire will continue to use it. Added a new option to support automatic replacement of individual page field values without having to add your own `pw-value-*` classes. Meaning, you can now gain the benefit of field-value updates in your live preview without PW having to re-render the page. This applies primarily to text-based fields (title, body, etc.) that are part of the page being viewed. LivePreview editor and preview windows now talk to each other with JS rather than use SSE/streaming. I found that it just works more reliably that way, puts less load on the server, and [to my surprise] also seems to be faster. The SSE option is still there in the module config, but it's no longer the default. The only time where I think SSE might be preferable is if you want to monitor changes made to the page from outside of the page editor (like from the API) in a live preview fashion, as the SSE option will pick those up too. In addition to the above, numerous minor bug fixes, improvements and optimizations were added. If you want to grab this new version (which is still a development/testing version), it's posted in the ProDrafts, ProDevTools and ProFields boards. There's more to cover with this module still. I've been so focused on it that I haven't yet started working with htmx. Though I did spend quite a bit of time in the docs and it looks amazing. From what I understand as it relates to this module, htmx could bring a lot of greatness to the front-end preview window, so I'm anxious to get into that, and even more excited to explore the possibilities it opens elsewhere in ProcessWire. Also, how awesome is it that the author of htmx stopped by to say hello and answer questions here in the forums, that made my day — big thanks to @totally not an htmx shill for joining the discussion, I hope I'll have some good questions before long too. Thanks for reading and have a great weekend!

In that case, the most straight forward approach is to add a custom permission through the backend (e.g. 'import-pages'), hook before your module's execute method and check if the current user has this permission. Untested code for site/ready.php: <?php namespace ProcessWire; wire()->addHookBefore("ImportPagesCSV::execute", function(HookEvent $event) { if(wire('user')->isSuperuser() || wire('user')->hasPermission('import-pages')) return; $event->return = '<h3>You do not have permission to import pages. Please contact the administrator!</h3>'; $event->replace = true; }); Of course, this still leaves the backend menu item in place, but unlike modifying third party modules, it is upgrade safe.

For a customer I needed a bunch of pictures to make a mosaic in Photoshop (cropped as a square) ? 20 lines of ProcessWire "et voila": a folder full of first pictures of every page from a certain template. <?php namespace ProcessWire; // boot api include('index.php'); // find estates from web database $estates = $pages->find("template=archief-pand"); // if estates count not zero if(count($estates)){ // loop over estates ($e is single estate) foreach($estates as $e){ // if images not null if(count($e->images)){ // get first image of estate gallery $firstPic = $e->images->first(); // resize and crop image to square 800x800px $firstPic = $firstPic->size(800,800); // if picture not null then copy picture to folder propics if(!empty($firstPic)) copy($_SERVER['DOCUMENT_ROOT'].$firstPic->url, $_SERVER['DOCUMENT_ROOT'].'/propics/'.$firstPic); } } }

Generally that's correct, htmx.onLoad() replaces the standard jQuery initalizer. Only real trick is that you initialize stuff in the content passed in to the onLoad() callback, rather than initializing the whole document like you do normally in jquery: Note that the query selector is run against the newly inserted `content` element, rather than globally, so you can initialize the library just for the new content that has been added to the DOM (and avoid accidental double-initialization of things.) Alternatives are: using alpine to init the element on load using hyperscript to init the element on load The first one is sane, but not how I would do it unless I already had alpine in my code base and I was comfortable with it. The second one is insane and not recommended, but I do love hyperscript.

htmx supports using morphdom for swapping with the morphdom-swap extension agree 100% w/ @Craig's characterization of htmx as lower level than unpoly: it's an extension of HTML rather than a full framework (with, for example, a notion of layers). That can be good or bad, depending on your needs. Unpoly is a wonderful library that follows the same general html-oriented approach, but provides a lot more infrastructure baked into the core. I think either one (or, hotwire, for that matter, which is even higher level than unpoly) is a great choice for html-oriented development. I obviously prefer the lower-level "improve on HTML" approach, but they all have plusses and minuses. I'm (all to) happy to chat about htmx either here, on the htmx discord, or anywhere else. -t.totallyNotAnHtmxShill

If you have the core ProcessPageClone module installed you can copy a page via Page List: But sometimes I don't want to hunt around through Page List to find the page I want to copy, and instead I have found the page via the admin search and have it open in Page Edit. So I used this hook in /site/ready.php to add a "Clone this page" button to the bottom of the Settings tab. // Add a clone button to the Settings tab of Page Edit if this page is allowed to be cloned $wire->addHookAfter('ProcessPageEdit::buildFormSettings', function(HookEvent $event) { $wrapper = $event->return; $modules = $event->wire()->modules; $page = $event->process->getPage(); /** @var ProcessPageClone $ppc */ $ppc = $modules->get('ProcessPageClone'); if($page && $ppc->hasPermission($page)) { /** @var InputfieldButton $f */ $f = $modules->get('InputfieldButton'); $f->value = 'Clone this page'; $f->href = $event->wire()->config->urls->admin . 'page/clone/?id=' . $page->id; $wrapper->add($f); } }); Maybe somebody else has this need and finds this useful.

Thanks @wbmnfktr I fixed the link

That works perfectly, thanks so much for fixing it, and so quickly too!

I think I've found a fix for this. Please update to v0.3.3 and let me know if that version resolves the issue for you.

Apologies, I forgot to announce this topic here. Just cross-referencing this announcement/call for testers: Please note the expression of interest was to close yesterday (Friday 19 November 2021). However, the deadline has been extended until Monday 22 November 2021 to accommodate those who would have expected an announcement here. Apologies again.

Thank you for the great module! Should it still be updating connected fields correctly when duplicating a page with the ProcessPageClone module? I'm on 3.0.186 dev and can't get it to update when cloning a page.

You would need to edit the module to add the permission settings in the getModuleInfo() method or equivalent "info" file. You can refer to Ryan's ProcessHello module as an example: // name of permission required of users to execute this Process (optional) 'permission' => 'helloworld', // permissions that you want automatically installed/uninstalled with this module (name => description) 'permissions' => array( 'helloworld' => 'Run the HelloWorld module' ), If you want the permission to be automatically installed you would need to uninstall and then reinstall the module.

It is a bit "hidden" but somewhat documented over here: https://processwire.com/docs/security/file-permissions/#securing-your-site-config.php-file Quote: "This includes /site/assets/ and everything within it, as well as /site/modules/ and everything in it (if you want to have a writable modules file system). Read the next section for details on how to do this." Also, the PW installer is also informative (sure, these are the conditions required by the installer, so later on /site/modules and config.php can be locked down, as also explained in the docs):

Using Padloper on a daily basis at our University Modelbuilding Lab to sell materials and charge for laser cutting (https://www.mekano.info/en/materials/). The actual shop part is only accessible to our staff members as we only sell stuff at our counter. At busy times we sell over 100 products a day.

Maybe a weird question but... will we buy the dev/testing/beta of Padloper 2 via a Padloper 2 interface? Asking for testing purposes.

@Stefanowitsch in case you are still looking for it: @dotnetic the current download option over on https://processwire.com/modules/german/ doesn't work right now. It's looking for master.zip while it's main.zip now in your repositiory.

@ryan Autosave is very usefull feaature, but in some sceanrios it would be great to have shortcut key (Ctrl+S) to force page save with saving of scroll positon. Maybe it's possible to implement it, while you are in thisfield?

Hi @kongondo, thanks fo your plugin, I just bought and installed it and am now setting things up. Just wanted to let you know I had this same problem and this fix worked for me, but I don't have Media Manager installed in a subfolder (I think). My setup is: localhost (MAMP), Media Manager is installed in Applications/MAMP/htdocs/website/site/modules/MediaManager. When I move on to the live site I will let you know if it happens there as well. If you have any questions to help find out more about this bug let me know. edit: I'm using PW 3.0.165 and MM v0.1.2 β

Hello @Ksenia! That’s a browser feature that’s supposed to prevent users from submitting the same form twice. I believe the quickest way to get rid of it would be to add a redirect to the same page after saving: $session->redirect('./', 303); That sends a 303 HTTP status code telling the browser to reload the page using a GET request, which MDN recommends for this purpose, as I understand it. Be aware that ProcessWire exits after a call to $session->redirect(), so no code below that line will get executed. Hope it works for you, I haven’t tested it though!

? I appreciate that, but htmx is fairly feature complete and is supported by my other work. intercooler.js, the predecessor to htmx, has been up for nearly a decade without any sponsorships: https://intercoolerjs.org I don't anticipate htmx being any different, although I always do appreciate any sponsorships! Thank you for the warm welcomes. I don't know how useful I'll be, but I'll try to answer any questions I can around htmx as honestly as possible.

hi, my name is carson, and I created htmx and, since we're here, hyperscript.org (for lunatics only)

New module: OneTimeOnlyCode https://github.com/benbyford/OneTimeOnlyCode Use this module to create codes with urls (or any of string data) and later check a code and its data e.g. to get one time access to content. I built this to send out specific "exclusive" users codes at the end of URLs to new articles where noramlly they would have to log in -> now they can see the content only once and then have to login if they navigate away. I made it only to show the content not any user profile infomation etc when using the code, be warned not to use it to show user information unless you know what you're doing! Codes can have an expiry and uses lazy-cron to cull codes out of day at a set interval (both in checking and elapsed interval for the codes). Check it out!

@kongondo Thanks, great ideas! Your SSE examples are eye opening. I think I understand a lot of this but not yet all of it, since I'm not deep in htmx yet, so I'll have to return to this once I do. But part of what you covered was the external interface to it that the web developer implements, and I think that's a good place to start, so I'll focus just on that. I understand the benefits of a separate config file, but am not sure how many would go to the effort of maintaining it for live preview. Maybe if PW auto-generates it somehow with functional defaults, it might help. Pros/cons aside, when we need something outside of the defaults, personally I'd rather declare this with markup classes or attributes in a manner similar to how we do for Markup Regions. Maybe I'm lazy, but it's already easy and familiar, and not much new to remember. Like with Markup Regions, ProcessWire can remove the attributes when they aren't needed, so no need for any output downsides. But if I had to declare it separately from the markup, I'd at least like to be able to do it in Setup > Fields > field rather than having to edit a .json file (and maybe this is a good fallback either way). I agree that it's good if the default behavior is to swap the entire <body> / refresh the window. But when we want to declare what gets updated with a live preview, here's an example of one way we could do it. If I wanted a particular section of markup to update automatically when the field "images" changed, I'd like if I could just do something simple like this, where div#gallery is an existing bit of markup a already there, like this: <div id='gallery'> // markup for an image gallery </div> …and I just add a class to that existing markup tag... <div id='gallery' class='pw-field-images'> // markup for an image gallery </div> ...or maybe a custom attribute instead: <div id='gallery' pw-field='images'> <!-- markup for images gallery --> </div> I'm not suggesting to add additional markup, but just an additional class or attribute to existing markup. If that same images field was also used elsewhere in the page, then I could just use that class (or attribute) again, and it would update too: <div id='sidebar-photos' class='pw-field-images'> <!-- markup for the sidebar photos --> </div> One thing I noticed in coding ProDrafts live preview is that field-level granularity often makes little difference in the end result. Replacing larger blocks of markup often is just as effective and visually identical. So I'd want to be able to say "if any of these fields change, update this…": <div id='content' pw-field='title,body,images,sidebar'> ... </div> For fields that already contain markup (like CKEditor), or fields that get rendered from their own /site/templates/fields/* template file, ProcessWire could automatically add the appropriate class by wrapping the value with it (this is similar to what ProDrafts and PageFrontEdit do): <div class='pw-field-body'> <!-- value of $page->body, div wrapper added automatically when live preview --> </div> This enables it to work automatically, without the developer doing anything at all. The only minor downside is that occasionally that can interfere with a CSS/JS selector, like if you are trying to target h1 + p:first-child, where the <p> is part of the CKEditor output but the <h1> isn't. Live preview still works, but the CSS/JS selector no longer matches when live preview is on. It's simple to work around though, and of course only affects output when someone is live previewing. Whether using a separate config file or not, if we use htmx, I think it should be a silent player and the developer wouldn't even need to know anything about how to use it. I'd like to avoid an external config file where I'm having to add 'htmx-attributes' arrays. I don't think we need the level of granularity or features in live preview that would demand the user know this kind of stuff. (Though fine for advanced users if/when needed). The more automatic it is, the more likely one is to use it. I think we'd also like the flexibility of not being dependent upon any particular library in case we ever decide to replace it with something custom. Side note, but one issue I also noticed in coding ProDrafts live preview is that when you update an element that has JS events on it that were added in document.ready, then they no longer work. For instance, an images gallery might have events that make thumbnails open in a lightbox or something. When the images gallery live updates, the lightbox no longer works unless the events were added to the whole document. Does htmx have some magic for this kind of situation?

This is what I am using: $this->wire->addHookAfter('ProcessPageEdit::getSubmitActions', function($event) { $page = $event->process->getPage(); if($page->template != "foo") return; $actions = $event->return; unset($actions['next']); $actions['clone'] = [ 'value' => 'clone', 'icon' => 'clone', 'label' => 'Save + create copy', ]; $event->return = $actions; }); $this->wire->addHookAfter('ProcessPageEdit::processSubmitAction', function($event) { $action = $event->arguments(0); // action name, i.e. 'hello' $page = $event->process->getPage(); // Page that was edited/saved if($page->template != 'foo') return; if($action === 'clone') { $copy = $this->wire->pages->clone($page); $copy->title .= ' (copy ' . uniqid() . ')'; $copy->save(); $this->wire->session->redirect($copy->editUrl); } });

Also, I want to open the page in Page Edit after it is cloned. Here is a hook for that: // Edit the cloned page after it is created $wire->addHookBefore('ProcessPageClone::execute', function(HookEvent $event) { $event->wire()->addHookBefore('Session::redirect', function(HookEvent $event) { $url = $event->arguments(0); $id = (int) filter_var($url, FILTER_SANITIZE_NUMBER_INT); $redirect_url = $event->wire()->config->urls->admin . 'page/edit/?id=' . $id; $event->arguments(0, $redirect_url); }); });

v0.3.0 released. Notable changes in this version: 1. Fix for page clone issue reported by @a-ok in the post above. 2. The module now hooks Pages::save() and Pages::saveField() instead of Pages::saveReady() and Pages::saveFieldReady() in order to work around this core issue. Hopefully that issue gets resolved and then the module can go back to saveReady hooks because those would be preferable, but for now something had to be done because the issue was making page changes unsaveable when "single" Page Reference fields were configured in this module.

I believe so :-).

I've added support for this in v0.2.0.