Leaderboard

Is it really necessary to introduce a third-party dependency to do a comparison and updates the parts that were updated? Since the whole process won't be instant, couldn't it just be a matter of reloading an iframe showing the page? (which is what you're doing already with ProDrafts I assume) I feel you could (should?) come up with your own minimal implementation of SSE to signal an autosave to a "preview" tab and have the js simply reload the iframe. Reading the Mozilla page I guess you could have two EventSource : one signaling a global autosave for PW's "preview" tab to automatically reload and another one signaling specific changes (in JSON format?) that developers could eventually listen to on their own using htmx or what, which is what you're actually suggesting with ?change=body, my bad. I hope I'm not saying obvious things or misunderstanding what's been said, sorry if I did. A question though re the autosave feature: since this is partly meant as a way to preview changes on a page, what happens if one wants to roll back to the initial state of the page ? Could you provide a way of cancelling all of the auto-saved changes ? Actually now that I think of it and re-reading your post, how would you do if you have a published page that you want to edit but don't want the edits to be seen by a guest ?

Thanks for all of the replies, this is great information. It sounds like SSE is the way to go here. I don't have any experience with that yet so am looking forward to learning more. I'm basically repeating what's been said above, but it sounds like htmx has this built in and may be a simple way to get started with it. Since this is a front-end modification (where PW doesn't usually venture into), the more lightweight we can be with it, the better. So we might eventually consider putting together just the functionality that we need for this part, as I know htmx does quite a bit more. But since I know almost nothing about SSE, htmx sounds like a great place to start. Since the front-end comes exclusively from user's template files, I don't think there's a way that ProcessWire can selectively render one thing or another in the page. It has to render the entire page. But it does sound like the actual JS-update part of it could certainly be more selective. For users that want selective server-side rendering of elements, it's certainly possible that we could provide some kind of suggestion that the developer should follow, as a means to increase performance of live preview. For instance, if the URL is /path/to/page/?change=body then the developer might detect $input->get('change') === 'body' and render the markup appropriately. But I think most will just want a drop-in solution that they don't have to code around. And that means how fast it works would have more to do with how efficiently the site is coded and how fast the environment is that it's running is. I don't think this will ever be a "see each character as you type" type of live preview, but I think most of the value of live preview will still be present even with a small delay.

Unfortunately, we cannot get a way from a full page refresh no matter how desirable a partial refresh is. htmx deals with selectors, to find the element(s) to swap. It would be very onerous for ProcessWire to read through a template's code to find the element to swap. This means this: <div hx-get="/some-url" hx-trigger="some_event" hx-target="#body" > </div> OR this.. <div hx-get="/some-url" hx-trigger="some_event" hx-target=".body" > </div> What @ryanis suggesting is that the target for htmx can be read from the GET variable. Whilst this might work for simpler cases, and it is a nice idea, the fact is there are myriad ways for building templates. What about fields that are split into various fragments on the page, how do we update those? What about the concatenated ones? This also means developers need to code for the live preview and in a certain way. Having said that, htmx has hx-vals. <div hx-get="/example" hx-vals='{"myVal": "My Value"}'>Get Some HTML, Including A Value in the Request</div> OK, that might work. This would tell ProcessWire if this changes, give me the changed values for 'myVal'. All these lead nicely to the next headache. What happens when your site goes live? It means you have to delete all those hx-attributes as you only needed them for live preview. Just playing devil's advocate here ?. If live preview was about rendering an Inputfield's content, that's easy. We would let individual Inputfields' __render()s handle it. I am using this quite a lot with partial updates (i.e., only those bits that have changed). However, if it is about previewing the site, how it would appear when rendered on the frontend, then the many difficulties of adapting to a developer's code in their template files make partial updates quite difficult, if not impossible.

There's lots of use cases mainly related to module development as well as internal ProcessWire use. You can also use it (with caution) for housekeeping. Let's say you created a number of fields for testing purposes on a site or module you are working on. You gave your fields a specific prefix to easily identify them as test fields, for instance. You now want to delete them. They are not in use in any template. There are a lot of them. Instead of deleting them manually, you can use the API to do it for you. <?php namespace ProcessWire; // get your 'test' fields // their names start with 'test', e.g. 'test_some_field' $testFields = $fields->find("name^=test"); d($testFields,'TEST FIELDS'); foreach($testFields as $testField){ $fields->delete($testField); } Run that in Tracy console and you are done.

Hello, Ksenia! On a bit unrelated note, you can use Tracy Debugger instead of vanilla `var_dump`. You can output the variables to the debugger using `bd()` function like that: `bd($matches->getSelectors())`.

Hi @horst Thanks for the code; I have found that there is 'saveFileCols' method that can be used to set values of these properties in DB. $fieldtype = $fields->get('image')->getFieldtype(); $image = $page->get('image'); $fieldtype->saveFileCols($page, $fields->get('image'), $image, [ 'width' => $image->width, 'height' => $image->height, 'ratio' => $image->ratio, 'filesize' => $image->filesize ]);

@ryan As a possible alternative to having something polling for changes, have you considered some kind of server side push technology for signalling changes to the connected browsers as mentioned above by @Ivan Gretsky? I've been playing with using a thin ReactPHP layer that sends DOM mutation messages to clients using SSE (which has really good support in browsers) and have about 20 lines of vanilla JS in the browser that does the element replace in the DOM when it gets a message over SSE (though htmx could be used for this too). None of the connections in the video are polling. nifty-reactivedash-demo.mp4

Now that we're in the last couple months of this year, I've been trying to implement a lot of plans that we discussed early in the year. That meant a lot of updates to repeaters in the last couple of weeks (and likely more on the way). But this week, I've been working on another thing we discussed earlier, which is bringing automatic save and live preview capabilities to ProcessWire, independently of ProDrafts, and with full repeater support. In ProcessWire, it's your own code (in template files) that renders the site’s output. ProcessWire delivers a $page to your template file(s), and your template file(s) render it in whatever manner they see fit. In this environment, we need an automatic save capability before we can have a live preview capability. Working on that automatic save capability is what I've been doing this week. I figure that once that is finished, then we'll be able to start developing the live preview capability. I'm glad to report that we now have automatic save fully functional and have tested pretty thoroughly with every Fieldtype/Inputfield I can think of. Unlike in ProDrafts, it also fully supports repeater, repeater matrix, and even nested ones. Actually, it looks like we'll be able to support everything you would want it to. But it's early yet it'll need a lot of testing before its production ready. I've built it into a module called PageAutosave. It requires the latest version of ProcessWire on the dev branch (3.0.189). I'm not yet positive whether this is going to end up as a core module or not. I thought I would gauge interest and see. For now, I'm posting a limited release test version of it in the ProDrafts support board and ProDevTools support board, if anyone is interested in trying it out. The PageAutosave module lets you configure whether you want it enabled for all pages or just for unpublished pages. When needed, you can also optionally choose to limit it to certain templates, certain fields, or certain user roles. Autosave isn't always desirable as it literally means your changes get saved to the $page as you type, so I imagine it's something people might use more for unpublished pages. Autosave is one side of the coin and live preview is the other. The current goal for live preview is to not depend on any particular view or admin interface and instead to just simply have the option of having a window open to a page in the website that detects changes and updates them automatically. So if you had one window open to the page edit screen, and another window viewing the page being edited, you could observe your updates as you made them. Once that is working reliably, we can decide on how best to put an interface around it, and maybe some will also like the option of just having two browser windows open wherever they want them. This won't be the kind of live preview where you'll see every character as you type it, but more likely you'll see updates a second or so after you make them. That's because your edits have to be auto-saved in the page editor, ProcessWire has to call your template file(s) to render the output, and the live preview has to update whatever has changed since the last update. It's that last part of it that I'll need the most help on. Some of you have mentioned htmx as a potential way to accomplish that and I think it looks compelling. And if you know of any other [likely JS-based] tools or technologies that we should also look at, please reply and let us know. I've bumped the core version to 3.0.189 primarily because the PageAutosave module requires updates that are in this version. This version also continues some longer term build out of a couple Fieldtype interface methods across multiple modules, and adds a new 'sorted' JS event that is triggered during sort actions (also used by PageAutosave). But if you aren't going to be installing the PageAutosave module, there's no urgency to update to 3.0.189 if you are on the dev branch and already using 3.0.188. Thanks for reading and have a great weekend!

Never mind! I solved it! Just was looping selector in the wrong place! foreach ($selected_techniques as $selected_technique) { $selector_ind .= ", relation_individual_technique.relation_individual_technique_select=$selected_technique"; $individuals->add($pages->find($selector_ind)); $output = ""; foreach ($individuals as $match_ind) { echo " <li><a href='$match_ind->url'>$match_ind->title</a></li>"; foreach ($match_ind->relation_individual_organisation as $relation_individual_organisation) { $organisations->add($relation_individual_organisation->relation_individual_organisation_select); $allorganisations = $organisations->explode('id'); foreach ($allorganisations as $item){ $output .= "$item|"; } $final_output = mb_substr($output, 0, -1); } } $selector_org .= ", id=$final_output"; } Never mind! I solved it!

Yes. Using Ajax. There are many way to send an Ajax request to the server: vanilla JavaScript, jQuery (?), Axios, htmx ?...etc. A workflow like this maybe: Create buttons of type 'button' - to avoid them submitting the form normally. Choose the client-side library (or pure JS) that will to talk to the server. Listen to the click events on the buttons. I would probably toggle the buttons. User clicks on I am here: this sends an ajax request to your server. Create a session (or if you wanted, a cookie) to 'register' the user's presence. Populate your log-page. Send back a response to client, toggling the I am here button to a I am out button. This would be trivial if using htmx. User leaves: delete their session in #6. Amend your log-page. If stream still continuing, show I am here button. Stream ends: clear all sessions from #6. Something along those lines, assuming I understood your question ?.

I am finishing the next release right now and will be pushing a new version. In this version you can customize all Fluency UI strings for any default language, using the translation service if desired.

Thanks, @ryan! This year's end seems to be even more interesting than its beginning) If that is required for the live preview it should be in the core, IMHO) If I understand it right, the core of what we need to build is something listening to a page save event and refreshing the preview page when it happens. Now we have an autosave to generate the events. The other part is reacting to that autosave. I can see 2 ways of doing that: ajax polling and sse (we probably do not need WebSockets as the preview doesn't need to send anything to the server... yet?). The latter (sse) seems to be a better fit, as it should use less server resources, but might be harder to implement (maybe not). Anyway, htmx supports sse (and even ws to an extent), which makes it a better fit than unpoly that doesn't (at least it didn't not so long ago when I checked). Actually, we could go without htmx, just taking inspiration from the principle it is based on. Though taking the ready-made library could be easier. The other part where htmx (or unpoly, or turbo or...) could help, is refreshing not the whole preview page, but only a part of it. Regenerating the whole page markup could be a long process (those 2 seconds in the OP are way too optimistic for many of the sites I have seen). For example, we could regenerate only one PM block markup and sent it to the preview for htmx to swap. But that would require either some standardization of the frontend or some hookable architecture for a developer to implement. The former would break the core PW principle of leaving frontent to the developer. The latter should be possible and would work nicely when rendering RM based content builders the standard way or with a Wireframe. Unpoly is complete framework, which could be used to upgrade PW admin as a whole, but would probably require to do everything its way. For a one place thing or for a more-work-more-customization htmx is a better suit, as it is lower level, as both of you @Craigand @kongondoagreed. If we bring in unpoly, we need to be ready to slowly redo all the admin area with it (which might be a nice thing in the long term). But for one task htmx is lighter solution. And we could even go without it only getting inspiration from it.

One of the many reasons I like htmx. It reminds me of ProcessWire a lot. Out of the box all it does is give you the necessary tools then stays out of your way. Even the author, for some reason, reminds me of Ryan ?.

I'd like to add another vote to the notion of using something like htmx or Unpoly - I like them, a lot. Having used them on various projects, both have pros and cons (like most things) and satisfy different use cases. I know PW is quick, and the template caching improves on things, but I recently launched a site that made use of Unpoly's up-preload and up-instant functionality - the perceived speed of page loads makes it feel like a static site. The client's response on seeing the dev preview was "I was not expecting a like for like copy! Especially one that is that fast." (their emphasis; it was a redevelopment of a bad WordPress build). With Unpoly, I find the modal, popup and drawer UI are great. Having those integrated with the dynamic functionality is a plus, and means I don't have to worry about whichever underlying CSS framework is being used or pulling in a separate dependency to provide that. It's not perfect; some interactions, particularly nested ones, need a bit more care to make sure the server responses and front-end attributes are all present and correct. I also make heavy use of the "compiler" functionality. This is essentially your "$(document).ready()" equivalent which lets you initialise your client-side components (like maps or colour pickers, for example) on both initial page load as well as any time they happen to be added to the page dynamically via AJAX as the result of an Unpoly request. htmx sits at a bit of a lower level, and provides events and a plugin system to extend it and hook into different interactions. When you need to do client-side things, you will still need some javascript to get the job done; or you could use htmx's sister project _hyperscript. Either way, I'd be happy to see any of these become part of the PW admin. ?

Dear Ryan, I think you have not been "trying" to..., instead, you have been working hard on them (not just big features you mentioned today, but smaller yet still useful ones, as always). Thank you so much! Maybe it is worth taking a look at Unpoly as well: https://unpoly.com/ Various opinions: https://groups.google.com/g/unpoly/c/aKfjcIZKi4w https://groups.google.com/g/unpoly/c/w5mVyqA5zmg Demo site created by the author: https://demo.unpoly.com/

Update: Blog 2.4.6 Changelog Fixed fatal error when installing Blog (thanks @Orodreth , @lele_ballack and @Sascha Nos for reporting. Various other minor fixes. Please test and let me know. Thanks. PS: Not sure when it will propagate in the modules directory. I couldn't log in to force a re-trigger as I seem to have forgotten my password for that area ?.

I am happy to help in this regard in any way I can.

Hi Ryan, I just gave the module a quick test with my super advanced out of this world builder setup and wow, this really works well! It even auto-saves Mystique-based fields which is absolutely perfect. Also, replacing a single image-field autosaves correctly too. So sweet.