ProcessWire Weekly #335

Weekly update from Ryan: some core news, and Stripe payments module status update

In his latest weekly update Ryan discusses the latest weekly core updates — as well as the latest twists in the ongoing development process of a Stripe payments add-on for the commercial FormBuilder module.

Latest core updates

First of all, this week there have been a total of three commits to the dev branch. Among said commits there were...

• minor improvements to the JavaScript side of admin inputfields (inputfields.js)
• new keepApostrophe option for $sanitizer->wordsArray(); if set to false, this option removes apostrophes from processed value

• improvements to the text searching operators (for $pages->find(), etc.) to support better matching of words with apostrophes and similar, as well as improvements to word boundary detection for secondary ("rlike") queries

The selector updates in this week's commits may seem a little obscure at first, but (as Ryan explains in his post) they were introduced to improve search results when using terms that include apostrophes: “Alpe d’Huez”, “L’estello”, etc.

The core now has the ability to use full-text index for the first pass, and then narrow down the exact results with regular expressions. This update should also solve issues related to having different types of apostrophes in the same query.

On a related note, this week Ryan also mentioned that we might be getting a new master version pretty soon, possibly before ProcessWire 3.0.170. (We're currently at 3.0.167, so that'd likely mean next few weeks). We'll keep you posted about that.

Status update for the Stripe payments module, and new "action" modules for FormBuilder

Last week we mentioned the Stripe payments module for FormBuilder, and also said that the plan was to launch it this week. Well, things didn't go quite according to that plan, and the module is still a work in progress — possibly landing by next week.

On the other hand the work on the Stripe module has lead into a new concept that will likely have even greater meaning in the long run: pluggable action modules. These are essentially optional feature plugins that add new ways to handle form submissions. A lot of potential here, so definitely looking forward to seeing this in action!

For more details about this week's core updates, as well as the FormBuilder updates discussed above, be sure to visit the latest weekly update from Ryan at our support forum. Thanks!

Weekly tips and tricks

Instead of a strict "recipe" format, we just wanted to drop in a couple of little tips. Both have been recently mentioned on the support forum, and while the other is very simple — basically just a reminder of existing Sanitizer features — the other one is a bit more tricky. Anyway, let's get started with the simple stuff: sanitizing dates the easy way.

Sanitizing dates while also limiting the range of available values

Now, let's say that you're dealing with user input, and that user input is a date. Let's say that we also want to make sure that a) it's a valid date in correct format, and b) it's a date that occurs during current year. Here's how we could check this in one go:

$sanitized_date = $sanitizer->date('31.2.2020', 'j.n.Y', [
    'strict' => true,
    'min' => date('1.1.Y'),
    'max' => date('31.12.Y'),
]);
if ($sanitized_date === null) {
    echo "Provided date is invalid! Please try again.";
}

Going over our example step by step:

• First argument for Sanitizer::date() is the date we want to validate. This could be user input, or a value generated with code.
• Second (optional) argument is the date format. This applies to the input value, but if specified, it also makes the method return valid dates int hat format (otherwise a UNIX timestamp is returned).
• Third (optional) argument is an array of additional options. In this case we're using three of those:
  • Setting strict to true means that Sanitizer::date() won't attempt to "fix" our date if it's invalid, but rather returns a null value. For an example an invalid date (such as 31.2.2020, when there were only 28 days in February) is now going to return null instead of 2.3.2020.
  • Setting min to date('1.1.Y') (effectively 1.1.2020, or 1.1. of current year) states that we will only allow dates starting from 1st of January current year.
  • Setting max to date('31.12.Y') (effectively 31.12.2020, or 31.12 or current year) states that the last allowed date would be 31st of December current year.

This is one of those things that ProcessWire's Sanitizer handles right out of the box, but I for one must admit that more than once I've used my own code to do exactly the same thing — so consider this a friendly reminder :)

Disabling multi-language support for a single field with a hook

This one is a little more tricky, and a little less obvious. Consider that you've got a page with multi-lingual field — say, title field — yet in one specific case you don't want users to see this multi-lingual version, but rather a single language only.

If you wanted to disable multi-lingual fields for an entire template, that'd be as simple as enabling the "advanced" mode and toggling a template setting, but our case here requires a bit of code — here's the code snippet, originally posted to the support forum by Robin Sallis:

// Single-language title field for "test-template" at Page Add
$wire->addHookAfter('ProcessPageAdd::getAllowedTemplates', function(HookEvent $event) {
    $tpls = $event->return;
    $t = $event->wire()->templates->get('test-template');
    if(isset($tpls[$t->id])) $tpls[$t->id]->noLang = 1;
    $event->return = $tpls;
});

// Single-language title field for "test-template" at Page Edit
$wire->addHookAfter('ProcessPageEdit::buildFormContent', function(HookEvent $event) {
    /** @var InputfieldForm $form */
    $form = $event->return;
    $page = $event->object->getPage();
    if($page->template == 'test-template') {
        $title = $form->getChildByName('title');
        if($title) $title->useLanguages = false;
    }
});

Code comments pretty much explain what's going on in here: when a new page is being added we're making ProcessWire think that this particular template doesn't have multi-language support enabled, and then during Page edit we're telling the system that the title field doesn't have language support enabled.

Perhaps a border case, but it's something I've run into as well, and Robin's solution is quite ingenious, so we hope that someone else will find this useful as well. Thanks to Robin for sharing this code snippet with us!

Got a good "tip of the week" you'd like to share? Let us know in the comments of this post (or via our feedback form), we'd love to share more of these!

Site of the week: Ordamo

Our latest site of the week belongs to Ordamo. Ordamo is a 100% web-based (no app downloads required), contact-free order and payment system.

The goal of Ordamo is to completely automate the front of the house operations for restaurants and bars, as well as provide an enjoyable experience for the end users, i.e. the guests of said establishments. For this purpose Ordamo provides a full range of software and hardware solutions — not jut for handling orders and payments, but for effortlessly managing pretty much the entire establishment.

The Ordamo website was designed and developed by the ID Studio Web Agency. The site features a gorgeous, modern design, sprinkled with numerous, nice looking screenshots and photographs of the software and hardware solutions provided. Performance of the site is top-notch, and overall it feels quite straightforward — which, just for the record, is in no way a problem; quite the contrary!

The front-end is based on the Bootstrap front-end framework. Apart from that, there's not a whole lot we can say about the implementation side that you couldn't figure out for yourself. A couple of things that could be worth mentioning include quite extensive integrations with analytics and marketing platforms (from GA to HubSpot), and the use of a free SSL certificate from Let's Encrypt.

Big thanks to the folks at ID Studio Web Agency for sharing this project with us, and our congratulations to the client, Ordamo. The site is looking really good!

Stay tuned for our next issue

That's all for the 335th issue of ProcessWire Weekly. We'll be back with more news, updates, and content Saturday, 17th of October. As always, ProcessWire newsletter subscribers will get our updates a few days later.

Thanks for staying with us, once again. Hope you've had a great and productive week, and don't forget to check out the ProcessWire forums for more interesting topics. Until next week, happy hacking with ProcessWire!