ProcessWire Weekly #496

In the processwire.com blog this week: introducing the Page Edit Lock Fields module

In the latest post at the processwire.com blog Ryan provides an in-depth look into his latest creation, the Page Edit Lock Fields module. This module is not bundled with the core, at least for now, but is freely available for anyone to download and install via the built-in modules manager in admin, or the Page Edit Lock Fields GitHub repository.

What is the Page Edit Lock Fields module, and how does it differ from our existing core features?

We covered some of the basics in last week's issue, so you might've already heard of this module. In a nutshell Page Edit Lock Fields bears some similarities with the page and field lock features found from the core, but also goes way beyond their scope by providing extended control and granular settings:

• While the core features make it possible to lock a page from edits, or define that specific field is locked (globally or in the context of specific templates), the Page Edit Lock Fields adds support for locking individual fields on specific page(s).
• In addition to fields, you can also lock native page properties, such as the name, template, parent and status properties of the page — and even the delete/trash option, preventing the page from being accidentally deleted.
• There are various options available for customizing the behaviour of the module, such as whether locked fields should be collapsed, whether inputs should still be rendered (important when working with show-if or required-if conditions) etc.
• The module makes it possible to define users that are allowed to lock fields on a per user basis; an option that can be used to further restrict the list of users with page-lock permission to, say, the developer(s) of the site only.

Fields and properties can be locked with a long-click on the value you want to lock, or alternatively via the Settings tab. The long-click behaviour can be optionally disabled, but most users will likely want to keep it on — unless, as Ryan mentions in his post, it interferes with some other feature of the site.

Page Edit Lock Fields API for developers

It is important to keep in mind that the lock feature is intended for the admin only, and has no effect whatsoever on any actions triggered via the API — but for those looking to manage locks via the API, there is a rather feature-rich API for exactly that purpose:

$pelf = $modules->get('PageEditLockFields');

// get all locks for a page
$locks = $pelf->getLocks($page);

// get all locks for the site
$locks = $pelf->getAllLocks();

// check if a field on a page is locked
if ($pelf->isLocked($page, 'title')) {
    // ...
}

// lock a field for a page
$pelf->addLock($page, 'title');

// unlock a field for a page
$pelf->removeLock($page, 'title');

// add multiple locks
$pelf->addLocks($page, ['title', 'name', 'status']);

// remove all locks for a page
$pelf->removeAllLocksForPage($page);

// remove all locks for a field
$pelf->removeAllLocksForField($field);

That's all for our core updates section this week. For more details, be sure to check out the Page Edit Lock Fields blog post from Ryan at the processwire.com blog. Thanks!

New module: Delayed Image Variations

Delayed Image Variations is a brand-new third party module developed by Robin Sallis. This module was built to resolve an old and rather well known issue that affects image-heavy websites in particular: delays — and potentially even timeouts — resulting from a large number of variations being created during single request.

This issue is most prominent when rendering a page with a lot of images, e.g. an image gallery, or some sort of catalogue of items where each item is or has an image. Default behaviour is to create all those variations right away, e.g. as soon as Pageimage::size() (or another variation creating method) is called.

Delayed Image Variations attempts to resolve the issue by instead writing a queue file on the disk, and only creating the variation when it is requested by its own, individual URL. This means that each variation is created on a separate request, which helps the server distribute the load, avoids creating disk space consuming variations that could never actually be requested — and the page should also load considerably faster, with images popping up a bit later as they get created.

Much like Robin's earlier Unique Image Variations module, Delayed Image Variations is deceptively simple module, yet one that can be a real game changer for certain sites; definitely something you should consider if you're running an image-heavy website!

If you'd like to give this module a try, you can install it via the modules manager in the admin, or clone or download it from the Delayed Image Variations GitHub repository. In case you have questions or require help getting started with or using this module, head down to the Delayed Image Variations support forum thread.

Big thanks to Robin for developing this module and sharing it with us!

Site of the week: San Francisco Contemporary Music Players

Our latest site of the week belongs to San Francisco Contemporary Music Players. They are the Northern California's most longstanding and largest new music ensemble, with more than 50 years of history and still going strong.

For more than 50 years, the San Francisco Contemporary Music Players have created innovative and artistically excellent music and are one of the most active ensembles in the United States dedicated to contemporary music.

— San Francisco Contemporary Music Players

This site provides a lot of information about San Francisco Contemporary Music Players, SFCMP for short, including profiles of the players, discography, and a rather impressive repertoire of 1337 works, as of this writing. The site also features a dedicated concerts section for upcoming events, a donation feature, news and press materials, and more. All that in addition to both the design and UX of this site being top-notch make this a very impressive site altogether.

Marc Wolf of nibiri, the developer behind this project, shared some history and behind the scenes details for this project in the SFCMP website showcase forum post earlier this week. The project involved migrating the site from WordPress to ProcessWire, and some of the technologies used on this site include YOOtheme Pro and UiKit front-end framework, while some of the ProcessWire modules used include ProFields, ListerPro, ProCache, and FormBuilder.

For more details, be sure to check out the showcase forum thread. Big thanks to Marc for sharing this project with us, and our congratulations to the client, San Francisco Contemporary Music Players, for their new, ProcessWire powered website!

Stay tuned for our next issue

That's it for the 496th issue of ProcessWire Weekly. We'll be back with more news, updates, and content Saturday, 18th of November. 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!