ProcessWire 3.0.127 core updates

Version 3.0.127 contains almost 30 new commits, the majority of which are focused on resolving older issue reports.

For more details on those commits, see the commit log. This latest version on the dev branch also adds a couple of new features that you might find useful. Specifically, two new Page status flags: “unique” and “flagged”. Below we’ll go into more detail about what these are and how to use them.

• New “Unique” status for pages
• New “Flagged” status for pages

New “Unique” status for pages

The “unique” status represented by the constant Page::statusUnique is a way of specifying that a page should have a globally unique name. Meaning, no other page in the entire system can have the same name. This status has actually been present in the Page class for awhile, and I’ve been meaning to implement it for quite awhile and finally did so this week.

A significant benefit of this is that you can access a “unique” page from the API without knowing exactly where it lives. No matter where the page moves in the site structure, the same API call to retrieve it always works. This is similar to the benefit you experience when using a page ID, but a page name describes itself much better in your code than a page ID does. Setting a page as having a globally unique name is also kind of like using an “id” attribute in HTML, in that it indicates a single unique identifier for an element (or a Page in this case).

You might create a page named “settings” and set it is globally unique so that you can grab it at any time from the API like this example below, which will work no matter where the page named “settings” happens to exist in your website:

$settings = $pages->get('settings');

Another example might be rendering general purpose links in your site. When building a site, I usually have a common link or two that goes in the footer (like Contact or Disclaimer), but I don’t want them to break if the client later moves the pages. Furthermore, I want it to adjust the URLs and titles automatically according to the page the language is viewed in.

$contact = $pages->get('contact');
echo "<a href='$contact->url'>$contact->title</a>";

The example below does the same thing, using the functions API:

echo pages('contact')->{'<a href={url}>{title}</a>'};

Because the page name is known to be globally unique, a secondary benefit is that ProcessWire will always redirect to the page that uses it, if you happen to access it off the root path. For example, let’s say that I set the /sites/categories/architecture/ page on this website to have a globally unique name. An access to the URL /architecture/ would redirect to the page. This might be a handy shortcut in some instances.

Just for fun, I set this blog post to have the Unique status, so its name “pw-3.0.127” will always be guaranteed unique (not that it’s a particularly good use case). Try accessing it off the domain root URL at /pw-3.0.127/ too if you’d like. Don’t worry, you won’t get lost — it’ll redirect you right back here.

You can set a page as globally unique in the page editor by clicking the Settings tab and then looking in the Status field:

From the API side, you can set a page as globally unique like this:

$page->addStatus(Page::statusUnique);
$page->addStatus('unique'); // this also works

You can find all pages having the unique status from the API like this:

$items = $pages->find("status=unique"); 

One thing to note is that in a multi-language environment, the unique name is only enforced for the default language. It’s kind of common for multi-language page names to cross-over with other languages, plus we always use the default language when loading pages by path or name from the API.

I’ve been thinking that when a page has the unique status, maybe the name should also be locked for changes. Currently it isn’t, but I’ve been debating it back and forth here. What do you think?

New “Flagged” status for pages

The flagged status is represented by the constant Page::statusFlagged. Currently it is used to flag a page as potentially having errors. A page receives this flag from the Page editor when the last interactive save to it produced one or more error messages.

These might be error messages about missing required fields or other types of validation errors. Whatever they might be, the status indicates the page may need help. Technically, it just indicates that an error message appeared during the last save of the page. When a page has this status, ProcessWire disables the publish “Pub” button that appears in the PageList actions for that page, at least until the status has been cleared. In fact, this status was added primarily to answer a GitHub issue/request to have the Pub button disabled in the PageList when it was disabled in the page editor.

This status flag can be cleared simply by saving the page (in the admin page editor) without having any errors occur. Flagged pages can be identified in the page list easily because there is a warning icon that appears next to them. You can also find flagged pages by selecting the “flagged” status in Lister when finding pages.

ProcessWire doesn’t add this status to a page except from the admin page editor when an error occurs. However, module developers and others may find this status useful as something that can be added or removed via hooks due to other installation-specific conditions.

That’s all for this week. Hope that you have a great weekend and be sure to check in at the ProcessWire Weekly too, which just last week celebrated the 250th issue!

Comments

• 

  HMCB

  • 6 years ago
  • 91

  Unique = awesome. Thanks for this addition.

  Reply

• 

  Horst

  • 6 years ago
  • 83

  Great addition: Page::statusUnique!

  Also I definetly see a usecase to lock it for changes. Maybe something like this: when this is set for a page, only superusers can a) remove the status, and b) can change the name.

  Additionally to the superusers, any role can do that if it got added a (new) page-edit-permission-changeunique.

  Reply

• 

  MrSnoozles

  • 6 years ago
  • 22

  Super cool update. Would it make sense to introduce an additional unique identifier that is not the name or would that overcomplicate it?

  Like:
  unique identifier: products
  Page name: /quality-bedsheets/

  Reply