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
• Users can now create their own bookmarks in Lister or ListerPro
• New asmSelect feature

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:

<?php
// 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

Comments

• 

  Joe

  • 5 years 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?

  Reply

  • 

    Teppo Koivula

    • 5 years 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 :)

    Reply

    • 

      Joe

      • 5 years 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. :\

      Reply

  • 

    Markus Tiefenbacher

    • 5 years ago
    • 25

    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.

    Reply

• 

  MrSnoozles

  • 5 years ago
  • 32

  ★★★★★

  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?

  Reply

  • 

    Teppo Koivula

    • 5 years 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) :)

    Reply

• 

  Juan Ignacio

  • 5 years ago
  • 42

  PW is getting better and better. The meta feature could work perfectly as hit counter.

  Reply