ProcessWire 3.0.213 core updates and new WireSitemapXML module

This week we’ll look at the new WireSitemapXML module, a new WireNumberTools core class, and a new ability for Fieldtype modules to specify useful ready-to-use configurations when creating new fields.

I don't usually post weekly updates here in the blog, as it seems maybe too formal for the scope of the weekly updates that we post in the forum. But for those that may not visit the forums, I wanted to post in the blog today, and we'll still keep it informal. 😁 This is in part as a reminder that there are weekly updates in the support forum, but also because we've got plenty to report (and the blog hadn't yet had a Feburary update).

I'm also not positive the audiences are always the same between the blog and our forum. So if you are reading this and were't aware of the weekly updates, be sure to visit our News and Announcements board. There you'll find everything between the last blog post and this one (which also includes a couple of dev branch versions).

In addition, the ProcessWire Weekly (an independent website/publication by Teppo Koivula) publishes a weekly newsletter that's much better than my weekly updates, so don't miss that, and subscribe to receive the weekly email too.

• New sitemap.xml module in ProDevTools
• New WireNumberTools class
• Predefined Fieldtype configurations for creating new fields

New sitemap.xml module in ProDevTools

This week I've released a new WireSitemapXML module in the ProDevTools board. There are more details on the dedicated Sitemap XML product and documentation page, but here's a summary of features:

• Support for up to 50,000 page URLs.
• Creates a turn-key, ready-to-use yourdomain.com/sitemap.xml just by installing the module.
• Custom configurable changefreq and priority on a per-template basis in module configuration.
• Option for automatically generated changefreq (change frequency) based on page modification times.
• Add pages to the site map (or remove them) on a per-page basis from the module configuration.
• Built-in cache option, ensuring you don't have to re-render the sitemap on every pageview.
• Ability to add custom URL segments on a per-template or per-page basis (requires using the API).
• Supports multi-language sitemaps (hreflang).

WireSitemapXML can be downloaded now in the ProDevTools support board download thread (login required).

New WireNumberTools class

A new WireNumberTools class has been added to the core dev branch. This will be a utility class for number functions, but for now it just has one method named uniqueNumber().

This uniqueNumber() method never returns the same number twice, for the life of the site. And the numbers it returns are not date/time-based. It's good for generating unique auto-incrementing numbers for any need, whether IDs or something else, and it avoids any potential race conditions, ensuring there is no overlap even if they are generated at the same exact time.

I've had a need for this ability a few times now and decided it would be a good first method for a number utility class. After all, we have a WireTextTools class already. Like the WireHttp class, this one has no API variable/method of its own, so if you want to use it, you'll have to create an instance of the class yourself:

$numberTools = new WireNumberTools();
$n1 = $numberTools->uniqueNumber();
$n2 = $numberTools->uniqueNumber();

// start a new unique number set under namespace "receipt"
$n3 = $numberTools->uniqueNumber([ 'namespace' => 'receipt' ]); 

• Numbers returned by this method are incrementing, starting from 1.
• The unique number counter is stored in the database so is unique aross all time/requests.
• Returned number is guaranteed to be unique among other calls to this method.
• When using the namespace option, it will generate a new DB table for that namespace.
• Use the reset option to delete a namespace when no longer needed.
• You cannot reset the default namespace, so any caller is always assured a unique number.

Predefined Fieldtype configurations for creating new fields

Added in 3.0.213 is a new method to the base Fieldtype class which any Fieldtype module can implement. This new getFieldSetups() (see code) method enables a Fieldtype module to specify different setup configurations for newly created fields that use that type.

The new method is also hookable, enabling you (or other modules) to also specify unique configurations for new fields on your own as well. These configurations become visible when adding a new field in ProcessWire. For instance, I've updated several of the core Fieldtypes to support it, and this is what the "Fieldtype" dropdown looks like now, when creating a new field (on this site):

A few of the groups in that screenshot above are not the result of the new getFieldSetups() feature. Some additional logic was added so that Fieldtypes can be grouped together when their title is in the format "GroupName: TypeName", such as is the case with ProFields, and this is why they get automatically grouped together. In addition, it automatically groups the core "Text" and "Number" types for convenience.

In the screenshot it also shows Fieldtype modules that are on the file system but not yet installed. I thought this would be helpful for people that may not realize there's an optional decimal type, or Repeater type, etc.

Part of the reason I added this is because of the recent update (a couple weeks ago) where ProcessWire now enables the Entities Textformatter automatically for newly created text/textarea fields. I found that to be kind of a hassle when I'm creating a lot of rich text fields, and I really wanted an option to just create a TinyMCE (or CKEditor) field directly, without having to go back and both enable and disable different things on it just to make it work.

I also wondered whether new users would even know about the rich text editor options, since they didn't appear until after a Textarea field is created. So that's another part of what inspired this feature. No doubt, having these different setup options could be useful for a lot of different Fieldtypes, so I built it out further, and that's what you see in that screenshot above.

You can also implement your own setups pretty easily. For instance, let's say that you wanted ready-to-use "Signed" and "Unsigned" configurations for Integer fields. And we also want them to use the HTML5 "number" input type rather than the default "text" that it uses. You could add this hook to your /site/templates/admin.php file (or /site/ready.php):

$wire->addHookAfter('FieldtypeInteger::getFieldSetups', function(HookEvent $event) {
  $event->return = array_merge($event->return, [
    'signed' => [
      'title' => 'Signed integer',
      'inputType' => 'number',
    ],
    'unsigned' => [
      'title' => 'Unsigned integer',
      'min' => 0,
      'inputType' => 'number',
    ]
  ]);
});

Now when you go to create a new field, you'll have 2 new options for Integer fields:

For those that want it, this can be used from the API also. When creating a new field and assigning the Fieldtype, you can specify the Fieldtype name and setup name in the format FieldtypeName.setupName for the $field->type property:

$field = new Field();
$field->name = 'hello';
$field->label = 'Hello';
$field->type = 'FieldtypeInteger.signed';
$fields->save($field);

That's all for this week. Thanks for reading and have a great weekend!

Comments

• 

  Marty

  • 1 year ago
  • 11

  WebP has such a nuance - not all browsers support it.
  For example, some version of iOS Safari, regular Safari, IE - do not support WebP.
  https://caniuse.com/#feat=webp
  Therefore, you must always store at least two versions of each image. Webp (for WebP-enabled browsers) and original image.
  And give the right version depending on the browser.
  And the original image must also be optimized/compressed - so that even for browsers without WebP support, images will be optimized (lighter in weight) - this is the third! version of the file..
  At the optipic service, I recently noticed a new functionality in which all of this is already in the box.
  https://optipic.io/en/cdn/
  You can even connect everything so that the urls of the images do not change (they remain exactly the same and look like internal urls on my site). But in fact, they are loaded through their system with automatic compression, conversion to webp and recognition of webp support.
  It turns out that everything is simple and beautiful, and inexpensive))

  Reply

• 

  HMCB

  • 1 year ago
  • 42

  ★★★★★

  Lots of good stuff in this post. Unique Numbers is going to come in handy. Thank you!

  Reply

• 

  T

  • 1 year ago
  • 32

  Are multi-domain websites supported in the initial version of WireSitemapXML?

  Reply

  • 

    ryan

    • 1 year ago
    • 11

    The initial version is fairly basic and doesn't have support for multi-domain websites. Though I suppose you could do it from the module's API. But I would probably take a more manual route at present, and maybe this is a feature we could add in a future version.

    Reply