ProcessWire 3.0.133 core updates

ProcessWire 3.0.133 adds a useful new $page->meta() method for a new type of page-specific persistent data storage, adds the ability for users to create their own bookmarks in Lister, and has a handy and time saving update for the asmSelect input type. Read on for all the details, examples and screenshots.

New $page->meta() method

The new $page->meta() method is available for any Page (or derived) object, and it’s provides a new storage option for page-specific data, independent of ProcessWire fields. It stores data in a new dedicated pages_meta database table, and it's handy for those times when you want to maintain some data for a page at the API-side, but don’t want to create a whole new field for the purpose.

For instance, this could be useful with page-specific module configuration data. It can store any string or number, or arrays of them. And it can do so for any page (or any derived type like users, roles, permissions, languages, and so on). I expect the most common use case would be to store stuff that you might not otherwise be able to store in regular fields, such as an array of data containing settings or the like.

A good example of the meta() method in action is the new Lister bookmark feature (discussed in the section below this one), which enables any user to create their own bookmarks in Lister. It stores all the user’s custom bookmark data, which consists of an array of their custom bookmarks that can be viewed in Lister.

Because the $page->meta() method does not use ProcessWire fields, it also operates independently of the usual page saving workflow, and it is not searchable from the API. When you set some data via the $page->meta() method, it saves immediately. You do not need to do a separate $page->save() call. In that sense, it works kind of like getting and setting $session values, except that the values are available globally anywhere the API accesses them. Here’s an example of API usage:

// set a “foo” property with the value “bar”
$page->meta('foo', 'bar');

// output the value of the “foo” property for $page
echo $page->meta('foo');

// a more likely use case would be setting lots of data at once
$data = [
  'hello' => 'world',
  'abc' => 123,
  'colors' => [ 'red', 'green', 'blue' ],
  // and so on...
$page->meta('myData', $data);

// get previously set data, anytime in the future
$data = $page->meta('myData');
echo $data['hello']; // outputs 'world'

Accessing the $page->meta() method without any arguments returns an object of type WireDataDB, which has a lot of its own methods that may also be useful in some cases. For more details see the $page->meta() method and the WireDataDB class in our API docs.

Users can now create their own bookmarks in Lister or ListerPro

Previously, superusers have been able to create bookmarks in Lister, via the “Bookmarks” tab. These are called “public bookmarks” and they are visible to other roles that the superuser designates. In ProcessWire 3.0.133, now any user can create their own bookmarks, and they will be visible only to themselves. They can also choose to optionally share their own bookmark URLs with other admin users.

Below is a screenshot of what the Bookmarks tab now looks like in Lister (or ListerPro). As you can see, I’ve created some of my own bookmarks that help me to sift through site submissions in the ProcessWire sites directory. Like with public bookmarks, clicking on any of my bookmarks immediately changes the Lister to show and match only the pages, columns and order specified with the bookmark. The $page->meta() feature described in the previous section is what makes this possible.

To create a bookmark you just setup your Lister to match the pages you want and display the columns that you want, then click the Bookmarks tab and the "Add Lister" field, give it a name, and submit.

New asmSelect feature

The ability to support parent/child relationships for selectable options has been added to asmSelect in 3.0.133. Currently this feature is only used by the ListerPro development version, though I will likely be expanding use of it to the core as well, but needed to add it to the core first, and that’s what’s in ProcessWire 3.0.133. However, I’ll use the ListerPro development version as my example to describe the feature.

In Lister and ListerPro (and elsewhere that might use asmSelect for a similar purpose) you can select columns that will display for each page in the table. It looks like this:

When you want to add more columns, you would click the select to reveal selectable options. Previously you had to potentially sift through a giant select full of options. If you had a lot of fields, it could become quite unwieldy. Here’s what it looks like for the Lister I’m using for our sites directory (and this isn't even all of it!):

That’s just too much. So asmSelect in ProcessWire 3.0.133 now supports ability to collapse the parent options so that only their children (which in this case are subfields) are shown if you first click the parent. With that feature in place, it now looks like this:

That’s much more manageable. If we click on one of the parent options, then we can see the children (subfields) that are also now selectable:

Here’s a short animated GIF that demonstrates it in action:


This week's updates are thanks to Innovation, Science and Economic Development Canada (ISED Canada). They helped to come up with the ideas and funding for these and additional related upcoming core updates.

For additional updates included in 3.0.133 see Teppo’s post in the ProcessWire Weekly from last week—it covers several new methods added in 3.0.133 that we don't cover above. Thanks for reading and I hope that you have a great weekend. Read ProcessWire Weekly tomorrow for a new issue with the latest updates and ProcessWire news. —Ryan


  • Joe


    • 1 year ago
    • 31
    The page meta method is interesting! Should help prevent one off fields.

    So if a page has meta information set with the $page->meta() method using the api, are you planning on having a section in the gui for letting users see or modify the meta information without using the api?

    • Teppo Koivula

      Teppo Koivula

      • 1 year ago
      • 41
      While this is an interesting idea, I'm not sure if it should be added – or, at least, such a feature should only ever be visible to superusers, or perhaps users with a specific permission for it. The kind of uses I can think of for this feature would largely depend on it being only modifiable by code, and any user intervention would be unwanted, and potentially even harmful.

      That being said: even if there's no such feature in the core, a third party module (Fieldtype or something else) could easily add it :)

      • Joe


        • 1 year ago
        • 22
        Thanks for the comment! I didnt think about the permissions angle. Might still be useful though if it would conditionally load for superusers.

        I tried to upvote you but it saved as a downvote. I think its a bug. When I try to upvote again, it just says I already voted for this comment. :\

    • Markus Tiefenbacher

      Markus Tiefenbacher

      • 1 year ago
      • 24
      I think also so - maybe the data should only be visible to normal users but not editible. I have such use case and made the meta data visible through FieldtypeRuntimeMarkup Module. It works well.
  • MrSnoozles


    • 1 year ago
    • 31
    Awesome. Especially $page->meta would have been really useful just recently.
    I don't see why it should behave differently from regular fields regarding saving tough.

    When the meta "field" saves automatically while other fields do not, doesn't that create an unnecessary inconsistency?

    • Teppo Koivula

      Teppo Koivula

      • 1 year ago
      • 70
      Since $page->meta() is separate from the regular save() process, "instant saving" makes sense to me: it's technically not "page data", as in "content within fields of the page", so it doesn't have to behave the same way in this regard. I do see your point, but overall I think it's important to keep in mind that this is not a field, and you don't set (or save) it like you'd set (or save) a field value.

      For the sake of clarity Ryan could've forced us to use meta() (or perhaps getMeta()) as a getter, and something else – like setMeta() or setAndSaveMeta() – as a setter, but I think that the current approach feels cleaner (albeit admittedly not quite as obvious) :)
  • Juan Ignacio

    Juan Ignacio

    • 1 year ago
    • 32
    PW is getting better and better. The meta feature could work perfectly as hit counter.

PrevWEBP image strategies, Google Client API, FormBuilder and more…


This week we’ll take a look at 3 different WEBP image strategies that you can use in ProcessWire 3.0.132+. Then we’ll dive into a major update for the Google Client API module, and finish up by outlining some useful new updates in FormBuilder. • WEBP image strategies in ProcessWire … • Strategy 1: More 

NextProcessWire 3.0.135 core updates

Version 3.0.135 of ProcessWire on the dev branch focuses on .htaccess updates, adds additional layers of security, adds clarity to debug mode, and improves upon the installer. More 

Twitter updates

  • ProcessWire 3.0.161 adds support for selector operator stacking, enabling you automatically broaden searches in a single pages.find() call— More
    26 June 2020
  • ProcessWire 3.0.160 adds powerful new text-searching operators, bringing a new level of power to page-finding API calls, especially when it comes to search engine type queries. Post also includes a demo search engine where you can test it all out live— More
    19 June 2020
  • Preview of ProcessWire 3.0.160 with auto-enable of two-factor authentication, new version of TfaEmail and TfaTotp, and new selector operators coming next week. More
    12 June 2020

Latest news

  • ProcessWire Weekly #319
    In the 319th issue of ProcessWire Weekly we're going to check out the latest core updates, introduce a couple of new third party modules, and highlight the downright stunning new website of Studio Pixelgold. Read on! / 21 June 2020
  • Powerful new text-searching abilities in 3.0.160
    In ProcessWire 3.0.160 we’ve got some major upgrades and additions to our text-search abilities. This brings a whole new level of power to $pages->find() and similar API calls, especially when it comes to search engine type queries.
    Blog / 19 June 2020
  • Subscribe to weekly ProcessWire news

“Indeed, if ProcessWire can be considered as a CMS in its own right, it also offers all the advantages of a CMF (Content Management Framework). Unlike other solutions, the programmer is not forced to follow the proposed model and can integrate his/her ways of doing things.” —Guy Verville, Spiria Digital Inc.