Leaderboard

The following video demonstrates how to set up a development server that is 100% ProcessWire friendly and uses all the latest software (PHP 8, MySQL 8, Apache 2). While there are other approaches to it (such as using tasksel lamp), the video demonstrates an efficient and clean way in getting all the latest versions of the software, advanced configuration settings, in addition to setting up SSL. This could also be used for WSL2 since it's ultimately a barebone virtual machine, much like DigitalOcean and similar providers.

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!

Watch out with this. If you're running a cli script or cron job, the SERVER_NAME will not be set and you may end up running it on your live database instead of your development!

This could be seen as cloaking by Google so be very careful doing things like that. More details here: https://developers.google.com/search/docs/advanced/guidelines/cloaking?hl=en&visit_id=637711928893360718-3584950016&rd=1 Feedback on this from Google in the past: Quite a nice read over on this blog about this topic: https://www.findabledigitalmarketing.com/blog/age-verification-gates-and-seo/

Let's not forget Bulma and Spectre, both powerful alternatives

You are up late @Jonathan Lahijani ?. Thanks for the tutorial!

The folks at YOOtheme revealed a little more about UIkit 4 recently: https://yootheme.com/blog/2021/10/28/uikit-3.8-reworked-focus-style I liked this part the most:

@adrian That issue has been there for a couple years. I spoke about it with Ryan on a thread in the RM forum, but I can't find it. You can ignore those errors. I do however wish they would not appear since it feels like like a bug.

@Ivan Gretsky Sure, I can add that.

I just re-read the previous post. It is what i did ask for not knowing we already have it) Could you please consider also allowing to put color code in that item headers string, so we can also define a per-type color? That would make different types really stand out)

If your CSS skills are limited you could use a CSS framework to get you up and going more quickly. ProcessWire itself uses UIKit for the backend admin UI. https://getuikit.com/ Bootstrap is another fairly popular CSS framework https://getbootstrap.com/ The down side of CSS frameworks is that they include a lot of CSS that your site probably won't use, and this can slow your site down, so eventually, writing your own responsive CSS will provide you with better performance, but if you need a fairly quick solution to make the website responsive where someone's already made and tested the CSS, the using a CSS framework can be helpful.

Yes 100%. I built and run a client-specific CRM/membership system for an arts organisation using Processwire. It started out relatively simple and has grown, but allowed us to build exactly what was needed and cut-out the over-complication of the many off the shelf systems they had already tried. Without PW's baked-in features development of this system would have taken an immeasurable amount of time longer.

Here's another one that does the "same" with a different hook on Page::addable. It's basicly the same, but this time we just set Page::addable to false and since the page list tree actions do check for this permission to add the "new" button, they simply won't get rendered anymore. So two ways, same result. The difference is that Page::addable is also used by ProcessWire in other places not just page tree. So will not be able to add a page and see an error when you try to add a page manually with a link like /processwire/page/add/?parent_id=1001. So this may the better solution here. Here the example module on my ever growing gist archive (hmm btw are those limited?) https://gist.github.com/somatonic/9494427

Enable advanced mode config. Select fieldgroup underneath the fields from the original template instead of adding them again. It then references the fieldgroup. Or have a hook into the page list action to remove or don't allow 'new' from those pages that have certain level.

Great tutorial Soma! This is the best summary of using PW's Inputfields that I've seen. I noticed you did $field->attr('id+name', 'email') so just wanted to explain what that is for those that may be unsure of the syntax. That syntax is basically saying to set the 'id' and 'name' attribute to have the 'email'. While every field needs a 'name' attribute (like in HTML) the 'id' attribute is optional… if you don't assign an id attribute, PW will make one up. If you intend to custom style a field with CSS or target it from javascript, then it's best to assign your own 'id' attribute. Otherwise, it doesn't matter. // this… $field->attr('id+name', 'email'); // …is the same as: $field->attr('id', 'email'); $field->attr('name', 'email'); // …as is this (direct reference): $field->id = 'email'; $field->name = 'email'; The advantage of using the attr() function over direct reference is that attr() can't ever collide with other Inputfield properties that might have the same name as a field attribute. It's basically your way of saying "this should definitely be an HTML attribute and not anything else." For recognized attributes like 'name' or 'value' it doesn't matter what syntax you use because an Inputfield already knows 'name' and 'value' are standard HTML attributes. But if you needed to add a custom attribute like "data-something", well then you'd definitely want to use the attr() method of setting. That attr() method should only be used for things that would actually be HTML attributes of the <input>, because they will literally end up there. So if you do an $field->attr('label', 'Hello'); you'll end up with an <input label='Hello'> in the markup, which is obviously not something that you want. That's why you assign a non-attribute property like 'label' or 'description' directly, like: $field->label = 'Something'; Last note about $attr() is that it can be used for both setting and getting attributes: $field->attr('value', 'something'); echo "The field's value is: " . $field->attr('value'); // same as: $field->value = 'something'; echo "The field's value is $field->value"; To extend your example, lets say that you wanted the 'email' and 'password' fields in a fieldset titled "About You". You would create the fieldset, and then add/append the fields to the $fieldset rather than the $form. Then you'd add the $fieldset to the $form: $fieldset = $modules->get('InputfieldFieldset'); $fieldset->label = 'About You'; $field = $modules->get("InputfieldEmail"); $field->label = "E-Mail"; $field->attr('id+name','email'); $field->required = 1; $fieldset->append($field); // append the field $field = $modules->get("InputfieldPassword"); $field->label = "Password"; $field->attr("id+name","pass"); $field->required = 1; $fieldset->append($field); $form->append($fieldset); Or lets say that you wanted those 'email' and 'password' fields to be each in their own column so that are next to each other horizontally rather than vertically. You would assign the 'columnWidth' property to both the email and password fields. In this case, we'd give them both a value of 50 to say that we want them to be a 50% width column: $field->columnWidth = 50; To jump out of tutorial mode and into idea mode: lately I've been thinking that PW should have a YAML to Inputfields conversion tool in the core (something that would be pretty easy to build), so that one could define a form like this: And create it like this (where $yaml is the string above above): $form = $modules->get('InputfieldForm'); $form->load($yaml); echo $form->render();