Leaderboard

Hello, my Processwire family. Just minutes ago I flipped on the switch for my agency's new website. Check it out here: https://supertiny.agency/ This is a year of changes. I've finished my collab with a major studio, focused back on Supertiny, Liliana joined me for marketing, campaigns and strategy services, and over the last few months I've been working on the agency's website overhaul. Curiosities: Threejs based intro: After learning a few new tricks from the Awwwards winner Bruno Simon and his incredible course, I went oldschool and made an intro for this website. The intro runs once, the session remembers it's been played and turns to a discreet mode if users return to the homepage, allowing a replay. Using my Tiny Cookie Consent as a web component, I made an approach that I'll probably use a lot going forward. I have a text field in the CMS for all the scripts, and with some PHP find/replace that's undone on the client side, trackers and stats are being turned on only when the user allows it. As usual, repeaters and content blocks allow mix and match when building content. The design and overall vibe takes cues from 80's sci-fi. When I started designing this I was playing Control on my PS4 and overloaded with nostalgia, and attempted to convey some of that in this website. Now, there's a bit of an experiment here. All UX bibles are saying that it's a sin make an intro, lock scroll and whatnot. But this is a site users are probably only going to see once. So my approach here is more like a Yield sign. There's an intro, the scroll is locked, but you have a skip button. I'm basically trying to make the user slow down a bit and take in the concept, but let them through if they're really in a rush. Also, as a communication strategy, I'm placing my bets on case studies that will be promoted in social networks, and also new content on the Insights which will hopefully become more interesting with video content. Users coming from there will only see the intro if after seeing that content they get curious and have a lookaround. This is making sense in my head, but it's a bet. I'm curious to see how it performs and if I have to change the approach. Let me know what you think.

@Ivan Gretsky That part I know I can handle. It's the front-end JS side of it that I don't know a lot about, yet. I mean this just to suggest the possibility of establishing some sort of guidelines for how a developer might implement selective rendering. I don't know what those guidelines would be, and just use that GET var as an example of how a request might indicate a change for a particular field (named "body"). Trying to communicate that in the simplest example possible. The developer would decide what that meant in terms of output that should be produced. But perhaps this example is too far from the context, I'm still learning how this SSE stuff works. PW can't generate partial markup for anything (outside of the admin at least), so it would be up to the site developer to implement whatever methodology we suggest for this, at least if they want higher performance live updates. From what I can tell, htmx can handle both cases... replacing partial markup, or selecting a part (hx-select) from a larger portion of markup, like the full document. @kongondo Yes you are right, it wouldn't be very practical. But the benefits of selective markup rendering may be enough that it's worthwhile for us to establish some guidelines for supporting selective rendering. Like that ?change=body example earlier, that's what I was trying to communicate there even if it's likely not a good example. The guidelines could be as simple as just letting the site developer know when they can skip over expensive things to render, like primary navigation or footer, etc. Something like if($config->livePreview) { // skip rendering unnecessary primary navigation } else { // render primary navigation } I was actually thinking of "body" as a PW field name, and the developer would decide what that means to the output in terms of what should be replaced. But you guys have a lot more experience with htmx than me so I think my example is likely flying a little blind, as my focus so far as only been on the auto-save part that identifies field changes. I need to start playing with htmx. ? The way that ProDrafts live preview works is by having the editor window communicate to the preview window and notify it when a field changes (JS based window-to-window communication). The preview window does pull a fresh/updated copy of the rendered page, but it attempts to only replace the markup that changed. It does this by having formatted values for fields like "body" include an extra <div> around them that identifies what it is, and then ProDrafts can replace just that element with JS. You can see things as you type in the editor, with a short delay, unless your page is very slow to render. This works well for formatted text fields (which is usually most of what one wants to see in live preview), but it does have to refresh the full document for other things where the site developer may be responsible for more runtime markup related to the field output. @monollonom ProDrafts only reloads the whole frame as a last resort. For most cases it can update just what changed. This is helpful for avoiding a very visible and distracting page refresh. Such page refreshes kind of kill the live-preview effect and can more easily draw your attention away from the content you are working on. I don't know if it'll be necessary to introduce a 3rd party dependency or not (htmx), but it does seem like a good place to start, even if we end up rolling our own later. That's more the domain of ProDrafts, and PagesSnapshots (another module in development). I think any kind of core autosave and live preview will focus on just those features (autosave and live updated view) and making them as good as they can be. It might be that one only wants to use these features for unpublished pages, but I think that's where it is most useful in the first place. If you wanted autosave/live preview on a published page, you could always clone it and then replace the original (or not) when you were done. This is essentially how PagesSnapshots manages drafts.

In preparation for testing of the initial (alpha/early beta) release of Padloper 2, I would like to gather expressions of interest. In the past, some of you expressed a willingness to help with testing. It has been many days since and your position might have changed. In addition, I would like to do this in an organised manner so we cover as much ground as possible. The grounds I’d like to cover are usability and technical aspects with a bias towards the latter. Please also note that there are a number of planned features that will follow the initial release. Hence, we shouldn’t focus much on those. These and similar thoughts will be added to a planned features list (more on this below). The main focus of this testing is to make Padloper 2 production-ready. In order to properly organise this testing, I will need to gather some information from you. I will be doing this via Google Forms. The most important detail will be your email address. I will need this in order to inform you how to access Padloper 2 as well as for other necessary communication. I will not use your email address for any other purposes nor pass it to any third-party ?. Other information to be captured in the form would be what areas of testing you will you want to be involved in and your preference for planned features (since I will need to prioritise them). Forms are better than plain emails in this respect. Please note the following if you wish to be involved in the testing programme: Pricing and subscription will follow the model I have previously stated (similar to ProcessWire Pro Modules). However, for the testing programme, your subscription period will NOT start counting down until after the production-ready release. You will still also have VIP support (please note the nature and location of this may change). To be fair to other testers, anyone joining the programme needs to actually spend time testing the product. If you won’t have time to do this, please wait for the production release. This initial release is NOT a production release. Although it may work for some in that regard, it will not be tagged as production-ready (hence the alpha tag). Licences will be the usual three: (i) Basic/Single Site Licence, (ii) Developer Licence and (iii) Agency Licence. I can explain the different between these three if anyone needs clarity. The initial release will have the introductory prices of €150, €300, €900 for single, developer and agency licences respectively. Cooling period will be 14 days (within which a full refund can be requested, no questions asked). Please note that this time period may change for the production release. Here is the link to the Google Form to express your interest in the testing programme. The form will close in 10 days. Many thanks for your patience. Hope to see you soon in the testing programme. I trust you will enjoy Padloper 2 as much as I have had the pleasure (and honour) of developing it ?.

Hi! I am trying to build a new version (open source) of the recurring dates module released a few years ago. And I've found myself with a couple doubts. I am building it as a single value Fieldtype module where I want to save the rrule string (to render the UI) but I want to save the actual occurrences of the rule in a second table, so I can use mysql to query the actual dates. Does this make sense? Is there another field around that uses a secondary table to save data? If this is sensible, where should I do it?? sleepValue()? savePageField()? @adrian I think I saw you suffering with the bugs a lot around the support thread haha, so any input on how you would approach the development/refactors of this would be appreciated. Right now on the "big picture" I want to use Alpine.js to redo de Inputfield and looking for advice here on how to do the actual Fieldtype. Also it's the plan to completely rely on rlavin/php-rrule . And this module will only involve the fieldtype/inputfield not the whole rendering modules that came along the original one.

I think so. It is only used with passwords: https://processwire.com/talk/topic/6629-config-httphosts-and-passwords/?p=64888 Quoting Ryan: "That particular value is generated randomly when you first install ProcessWire. It is forever tied to the passwords as a secondary salt. It's not technically necessary to have it, and passwords are already blowfish'd, but I've always felt better having one part of the salt disconnected from the database itself. If that salt changes or is lost, then all the passwords are forever broken."

Hi @abmcr I think you can try to use wireLangReplacements https://processwire.com/blog/posts/pw-3.0.155/#new-wirelangreplacements-function

Pete and I have been using Postmark in some PW based projects at reasonable scale (>13k emails a month) and have found it to be an exceptionally good API-based transactional email provider with fast delivery times and great availability. It seems strange that there is no WireMail offering (as far as we know of anyway) that supports Postmark, so we thought we'd throw one together in case anyone else in the community wants to give Postmark a try. NB: This is not the code we use in our production systems, just a rainy-day project to fill a gap in the WireMail ecosystem. However, it should be sufficient to get you going with Postmark. We hope you find it useful and please let us know if you find any issues. WireMailPostmark module on Netcarver's github account. Screenshot from my test account:

This is the new topic for the Settings Factory module (formerly known as Settings Train). Repo: https://github.com/outflux3/SettingsFactory I'm not sure what versions this is compatible with, it has only been tested on 3.x branch; it is not namespaced, and i'm not sure if namespacing is necessary or a benefit for this module; if any namespace or module gurus can weigh in on this, let me know. I'm also not sure if there needs to be a minimum php version; I have one live site using this now and it's working great; But before submitting to mods directory, would be better if there was some additional testing by other users.

Like last week, this week, updates continued on the core and matrix repeater fields. Repeater and matrix fields can now be configured to use fewer pages. When set, it won't create placeholder pages for repeater items until at least one repeater item exists for a given page and field. This can drastically reduce the number of pages consumed by repeaters in your system, and even more so if you are nesting repeaters. Eventually, this will become the default setting, but for now we are playing it safe and making it optional with a new toggle that you'll find on the Details tab when editing a repeater or matrix field: After enabling the "Use fewer pages..." Setting, the "Find an optionally delete unnecessary pages" checkbox will take care of cleaning up anything that isn't necessary for existing repeaters already in the database. If you have a large site with a lot of repeaters, this could be deleting a lot of now irrelevant stuff, so just be aware of that and backup ahead of time to be safe. Thanks to @Jonathan Lahijani for the idea/suggestion. Also new this week is the ability to copy and paste repeater items, as well as to clone above or below existing items. It handles this by replacing the existing "clone" icon action with a dialog that now lets you choose among various related actions. Among them is the ability to copy/paste from the same page or between different pages. The only requirement is that the repeater (or matrix) items are from the same field. See the video below for an example of how this works: This works with either Repeater or Repeater Matrix fields. But if you want this feature in Repeater Matrix, you'll want to upgrade to ProcessWire 3.0.188 and download the new version posted today (v8 beta) in the ProFields download thread. The ability to copy/paste repeater items was an idea originally from @David Karich and a module he developed called Repeater Matrix Item Duplicator. Thanks for reading and have a great weekend!

Please count me in. Looking forward to seing the power of the framework applied to ecommerce.

Yes please @kongondo - I have a need for a store right now, so definitely keen to put this through its paces.

Agreed - I found that interface quite effective as well.

I've put quite a lot of work into this now. There are lots of additional units added plus a greatly extended API. This enhances the formatting capability and introduces 'dimensional analysis'. So it is now possible to (say) multiply measurements and properly interpret the results. - e.g (as a simple example) speed x time = distance $speed = new Measurement('Speed', 'furlong per fortnight', 20); $time = new Measurement('Time', 'hour', 3); $length = $speed->multiplyBy($time, 'Length', 'yard'); d($length->render(['decimals' =>2])); Result is '39.29yd' Omitting the 'Length', 'yard' specification means that the result is returned in base units for the first compatible quantity for the computed dimension: $length = $speed->multiplyBy($time); d($length->render(['decimals' =>2])); Result is '35.92m' See https://github.com/MetaTunes/FieldtypeMeasurement for full details. The module is still alpha, so use in production systems is not advised. However, the functionality is now pretty complete but I have a bit of tidying up to do - and some more extensive testing in a new app. New units will probably also be added (but users can add their own anyway). Try it out and let me know of any issues or suggestions ?

@Gideon So, Please correct your code. It is broken in several places (missing braces, etc.). For instance: Here you close </li> early, before its children (nested ul). I think you meant $pages->get(1) ?.

Great, thanks.

Mine's still open and bleed once in a while with support emails lol so that's why I've decided to tackle this once and for all. I have a vague memory of this but don't clearly remember why momentjs was introduced. I'll just start without it? x10000000 I understand the issue well here. My guess if that it should work just as a FieldtypeMulti? If anything I appreciate your time to answer my questions! I am a bit nervous cause I know it's no easy feat, but excited to try to bring this to a more stable status. I will try to reuse most of the UI design wise at least to start with something, I think that part could be salvaged and is already a great deal of work? I'm sure it might have some areas improvement but I have used it successfully with a lot of people (when it works :D) that's why I feel it's really worth saving.

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.

This thing looks like an ideal new admin action)

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 ]);

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 ?.

Thanks for tackling this project! If the rrule for an event doesn't need to be searchable via $pages->find() then you could store it in $page->meta() and use the standard field table for the event occurrences. And if there really was a strong need to find event pages by rrule then you could add a custom search method that queries the pages_meta table.

@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

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.

Although, I wrote my shop a long time ago. But with pleasure I will test yours too. My store was founded 10 years ago on the Shop-for-ProcessWire v-001 module that @apeisa wrote. But I've rewritten pretty much everything, and I'm constantly adding new features. Conventional store systems don't work for us, as we have many different product properties. In addition, the store has a peculiar sales algorithm. As well as a special payment gateway for a local bank. And also loading goods from the warehouse accounting program.

For more advanced uses (api or even json-api by specification) I'd recommend something like fractal.

For simple json outputs, you can use WireArray::explode and json_encode() or wireEncodeJSON() methods https://processwire.com/api/ref/wire-array/explode/ $myPages = $pages->find('template=basic-page'); // extract required fields into plain array $data = $myPages->explode(['title', 'created']); echo wireEncodeJSON($data);