Leaderboard

Here is another little tutorial about files structure in ProcessWire. https://www.spiria.com/en/blog/web-development/tutorial-the-file-structure-in-a-processwire-site/ Comments welcome as always.

Sure... If you haven't read deeply into htmx, the main premise is that the server is the single source of truth regarding both data and markup, i.e. whole application state. If we need to update either data or markup, the server handles that. We just need to tell it what action to take. Validation has to pass, of course, before the server will oblige ?. Below is a quick example that demonstrates updating the markup using htmx based on user actions. Only 'remove' locations is demonstrated in this example. I wasn't sure whether your app shows the user both their removed and added locations and whether they can reset the session to have all locations reloaded afresh. It doesn't matter much as it wouldn't change much of the logic in the example. Secondly, note that this example makes use of alpine.js and tailwind css just for the pizzaz. These are not required by htmx. To let ProcessWire recognise htmx requests, please refer to this thread. Depending on the approach you take from there, you might not even need a JavaScript file! In the example below, we do have a JavaScript file just because we want to use alpine.js (for notifications) and we need htmx to talk to alpine.js. We also need the JavaScript file to tell htmx to add XMLHttpRequest to its request headers so that ProcessWire's $config->ajax will understand the request. First, let's see a demo then we'll see how easy our work is using htmx. Just for this demo, I have included htmx (and alpine.js and tailwind css via their respective CDNs [in production, you want to purge your tailwind css ?]) in my _main.php. Inside the template I am using for this demo, I have the following code. Here, I have removed the tailwind classes used in the demo so we can focus on htmx. Note that you don't need a dedicated template file for this to work. It will work with any template. As long as htmx is loaded in the page view and your template (in this case, the current page's template) is listening to ajax requests. In the template file, the main htmx magic happens here: <?php namespace ProcessWire; $out = "<a hx-post='./' hx-target='#locations' hx-vals='{\"location_add_id\": \"{$page->id}\"}' hx-include='._post_token' hx-indicator='#locations_spinner_indicator'>Add</a>" . "<a hx-post='./' hx-target='#locations' hx-vals='{\"location_remove_id\": \"{$page->id}\"}' hx-include='._post_token' hx-indicator='#locations_spinner_indicator'>Remove</a>"; echo $out; Let's go through the htmx attributes: hx-post This tells htmx where to send its ajax request. In this case, we are sending it to the same page we are viewing (./) and are using POST. We could have used hx-get if we wanted to (GET). hx-target This tells htmx which markup to replace/swap. The default is to replace the markup of the element from which htmx was called. However, hx-target can be used to specify the element to replace. In this example, we are replacing the whole listing so we target its wrapper element which has the id locations. hx-vals This is optional but we need it in our example. We want to tell the server which location (ID) has been added/removed. If we had a form element, we could have used it for this instead. Since we don't have one, we are telling htmx to process the (JSON) value of hx-vals and send that together with its request. Note: the escape slashes are so we can have raw, valid JSON in the attribute as required by htmx. hx-include This is also optional but important in our case. It tells htmx to include input elements found via the selector in this attribute in its ajax request. In our example, we are telling htmx to include the CSRF token we set on the server together with its request. hx-indicator Also optional. Tells htmx to show/hide this element to show the user that something happened. In this case we use a spinner. We could have used a progress indicator as well, .e.g., if we were uploading a file. That's it really! No event listeners, no handlers! We can add (and I did add one), event listeners on htmx events in order to do something after the event. In this example, htmx fires a custom event which alpine.js is listening to in order to show notifications after the DOM has settled. The notification type (success, error, etc) and the message are all coming back from the server but not as JSON. The markup to update the page is also coming back from the server. htmx receives it and plugs it into the DOM per the hx-target (also see hx-swap) attribute value. In this example, we are updating the whole listing. If we wanted, we could update just the location that was removed, e.g. add it back but with some removed 'indicator', e.g. greyed-out. In this example we use anchor tags as htmx triggers. For htmx, it doesn't matter; button, div, p, li, whatever valid HTML element would work. You already have a backend logic that's working for you but I show an excerpt of mine here, for completeness. Inside my-template-file.php (the template file for the template for the current page, in this example), I have the following code: <?php namespace ProcessWire; if ($config->ajax) { // check CSRF if (!$session->CSRF->hasValidToken()) { // form submission is NOT valid throw new WireException('CSRF check failed!'); } // ................ more code // e.g. check removed locations in the session, etc // get previously removed locations (keeping things in sync) $removedLocations = $session->get('removedLocations'); // REMOVING LOCATION if ((int) $input->post->location_remove_id) { $mode = 'remove'; $notice = "Removed"; $id = (int) $input->post->location_remove_id; } else if ((int) $input->post->location_add_id) { // ADDING LOCATION $mode = 'add'; $notice = 'Added'; $id = (int) $input->post->location_add_id; } // ................ more code // e.g. check if we really have a page by that id, SET $noticeType, $options and update session 'removedLocations' etc // build final content //----------- // @note: buildLocationsCards() is a function that does what it says on the tin. We use it in both the ajax response here and also below, in non-ajax content, when the page loads // the $options array contains a key 'skip_pages_ids' with an array of IDs of locations (pages) that have been removed in this session. We skip these in buildLocationCards(). $out = buildLocationCards($page, $options); // @note - here we always return one input only // we use the values in this input in JS to pass event details to alpine.js to show the correct notification and the notification message. $out .= "<input type='hidden' id='location_notice' name='location_notice' data-notice-type='{$noticeType}' value='{$notice}'>"; echo $out; $this->halt(); } // NON-AJAX CONTENT BELOW.... That's all there is to it ?. I am happy to share the full code if anyone wants to play with this further.

If your module has a lot of config fields you might want to divide them into groups inside a tabbed interface. Here is a demonstration module showing how this can be done. https://github.com/Toutouwai/ModuleConfigTabs Thanks to @kixe for providing my starting point in this forum topic.

Hi @horst thanks for getting back! I guess I have a very specific use case. My client uses a lot of gif’s which are bloating the front end… been migrating most images to webp and found that webp also does animation. Did a quick test and found a webp animation was roughly 10x smaller than the small gif. woudl love to allow my clients to upload and view in the admin as they do a lot of arranging of images. However, encoding an image to webp doesn’t keep any animations on the server (also the quality is worse going from giff to webp instead of jpg slides to webp). I guess I can’t see any reason why if presented with a webp upload the image field couldn’t just display as is in the backend… or maybe toggle this on in settings?

Yes, webp only is an output format, not a source image or master image format. If you want to use only webp as original image and output image (WITHOUT resize methods) you can use it within a files field. Within image fields is not supported and doesn't make much sense.

Be sure to have this in your config.php $config->useFunctionsAPI = true;

@flydev ?? - sorry for the mention, but are we going to have this module soon ?

@neophronYou already know this, I'm just thinkin' out loud. There are three ways to present a segmented data entry interface: 1) A single form with all data fields displayed and editable at one time on the same page. Data is visually isolated usually by framing. 2) A single form with multiple sections (ie, viewable tabs or steps). For example, step 1 could be personal info (name, address, etc.), step 2 could be product customization, and step 3 could be payment information. Having data segmented like this implies a sequential entry method where the user must progress in order. 3) Separate forms for each section (obviously uniquely named) on the same page. Forms are again visually framed. This is random in that the user may complete none or more sections (forms) in any order. Personally, I don't care for this method. I only included it because it can be done (not that it should be done). You say the 'designer' wants the form displayed in the uikit switcher. This sounds to me like they want the second option as they believe the data to be segmented and sequential. I believe Ryan has (or is working on) the Pro Forms module which handles a sequential method rather than coding it yourself. I remember seeing that topic from Ryan but I do not remember the status. Maybe someone can educate me of that status. The first two presentation options are standard practice but depends entirely on the type of information you are trying to obtain and how you as the programmer want the user to perform. For example, an academic test application might be better suited for the sequential method. Since the user should be logged in prior to accessing the form(s) you already have the 'account' information to which the form data belongs. Saving the data from whichever presentation method is easily done to that account via ajax and/or a normal submit function. <Off Topic> I put designer in quotes above because it takes me back many years when I did instructional design work. It is not the designer's job to state how the interface should function. That is determined by you and the SME (subject matter expert). Now if that designer is also the SME, then you're good to go. Otherwise, you should provide the designer with the guidelines to create the necessary interface based off your needs analysis. </Off Topic> Anyway, I hope all this blabberin' helps you some way.

I would like to do this, but right now I just don't have the time. The module is in a state where it needs a significant amount of cleanup before it would be usable for people who are not myself. For example, right now it forces you to install practically all the pro modules (FormBuilder, Matrix, ProCache, etc.) as they are dependencies. Secondly, I've hardcoded various things in there at the moment (due to time constraints) that would have to be cleaned up. Third, right now it's kind of in a frankenstein state of how it works with various CSS frameworks. The goal is to make it work with UIkit3, Bootstrap5, or Tailwind2 (or none at all), but I have to finish making it work with each and do the proper OOP (right now it's a mess). Also, the builder related stuff is constantly changing but nearly settled after 2 years (I've had to re-develop builder pages on a site 10 times once, I don't wish that on anyone). Also keep in mind it forces the creation of a bunch of general fields which I would suspect might be a turn-off if you have a purist approach. For example, I have a text field called "IP Address" that gets created. There's not really a choice in whether you can keep it or not. If you delete it, it will get recreated on a re-install or update. I do wonder though if I released if it would take on a life of its own through contributions (even clean-up related work initially). The vision of this module is to be "the best of ProcessWire" and from that it's highly opinionated. Meaning, it forces the use of Markup Regions and setting() vs other approaches. It uses a built-in menu builder based on repeaters (as opposed to something like MenuBuilder module). It relies heavily on the Mystique field for the builder options. I will make a video eventually.

Hi @horst Thanks for the code. Just one more question, how to update image/width/ratio info in DB for resized image?