ryan

This week we'll take a look at a newly released module that enables you to lock page fields or properties from editing on a page-by-page basis. Originally planned as a core feature, I found it worked just as well built as a focused module, so here it is. This post serves as both an introduction to, as well as documentation for this new module— https://processwire.com/blog/posts/page-edit-lock-fields/

This week I've been working on various ProcessWire related projects, but haven't pushed much to the core. There was a core feature I've been working on which I decided to instead put in a module. It's one of those things that should be be really beneficial for some people, but not necessarily needed by everyone, so it makes more sense as a module. This particular module expands upon the page-lock option and permission in ProcessWire. The page-lock option (which you'll see as the "Lock" status in the Settings tab of the page editor) provides the ability to lock a page for edits. This can be really useful if you want to prevent a particular page from being modified for whatever reason. For instance, maybe you are doing a $pages->get('/some/page/'); on the API side and if the path /some/page/ got changed, it would break something in the site. So to prevent clients from breaking the site, you lock the page to prevent them from screwing it up and breaking something on the site. This is quite useful, and often a life saver. But I don't use it as much as I'd like because of one downside. That downside is that it locks the entire page so that nothing on it can be edited. So it's just too heavy of a lock. What if you just wanted to lock the page so that the name, title and parent couldn't be edited, but everything else could be? That's what this new module enables. To lock a field in the page editor, you click its header and hold until a dialog pops up asking if you want to lock it. To unlock, you do the same thing. Once a field is locked, it remains locked (non-editable) until unlocked. Only users with page-lock permission on the page can lock or unlock fields. Locks can also be managed with checkboxes in the page editor Settings tab as well, just in case that is more convenient in some contexts. While these are editor locks rather than API locks, the locks do affect contexts outside the page editor too, such as actions in the page list. For instance, if you locked "parent" then you wouldn't be able to bypass it dragging a page in the Page List. I finished developing the module today, but I've not yet written documentation for it or uploaded to GitHub, etc., so I'm going to give it another day of work and testing before releasing it next week, and will cover more details in next week's post. Thanks and have a great weekend!

This week there are a few updates on the dev branch. Since I'm short on time today, I'll just briefly cover the most interesting ones. Support for OR-groups, sub-selectors, and match same (1) @item groups (see last example at that link) have been added to ProcessWire's in-memory page matching selectors, as used primarily by the $page->matches() method. Previously these features were supported only by the database selectors from $pages->find() and methods that delegated to it. The $page->matches() method that gained these features is used by the core in various places for runtime matching of pages, such as when finding/filtering in a PageArray, for example. Support has also been added for OR-groups to the base Selectors class, which makes it possible to use OR-groups on non-Page objects too. These database-specific selector features were added because there's been a recurring request to support OR groups in places that currently use memory selectors, so this should do that. Though it'll remain just on the dev branch until it's had more thorough testing. While there will always be some differences between database and memory selectors, this does narrow the gap a bit. Thanks for reading and have a great weekend!

This week the ProcessWire core dev branch version has been bumped to 3.0.230. Currently we are about 10 commits ahead of the main/master branch. Relative to that branch, we have 5 issue fixes, 2 pull requests, major improvements to the wireIconMarkup() function and some minor improvements to the ProcessLogger module. We may merge these updates (among others) to the main/master branch as soon as next week. This week I also developed a new security module called LoginTimer that helps to prevent timing attacks in ProcessWire. Admittedly, I started this more for fun than anything, as I don't think timing attacks are a common problem in ProcessWire. But the more I got into it, the more I became aware of the potential dangers of timing attacks (particularly outside of the ProcessWire world). In any case, I now view it as an important security consideration and definitely thought we should have a module for it. Maybe someday we'll have it in the core too. The module is now available in the modules directory and on GitHub, and I wrote up a blog post to accompany the module and that is located here: https://processwire.com/blog/posts/timing-attacks-and-how-to-prevent-them/

There hasn't been a lot of activity on the core this week, as I've been wrapped up in a ProcessWire-based client project (same one as last week). I'd like to put in a few more updates before bumping the version number, which will likely be next week. This week I also released a new module to accommodate a feature that had been requested more than once, but since it's not that commonly needed, I thought it was better to put it in a module rather than the core: Custom Inputfield Attributes for ProcessWire This module enhances both the interactive and API configurability of fields in ProcessWire (both admin and front-end). It can add custom attributes to Inputfields in ProcessWire, FormBuilder, or other Inputfield forms. Custom attributes can be configured interactively in the admin, or they can be added via this module’s API method. Custom attributes can be added to the <input> element of an Inputfield or they can be added to the wrapping .Inputfield element. You can add any attribute that you want (with a few exceptions), whether replacing or appending existing attributes, adding data-* attributes or any other named attribute. This module is available for download now on GitHub with more details on the module info page. Thanks for reading and have a great weekend!

@MarkE The Modules class supports a lot of different options for this, and it figures out which you are using automatically according to how you've defined it. The one that I prefer to use is your second example, that is not static and has the InputfieldWrapper $inputfields as the argument. The static method is the old/original way from when ProcessWire first was released (13 years ago), and it was used primarily so that one could configure a module without booting up an instance of the module. Later on (like ~8 years ago?), the Modules class was upgraded so that it could instantiate the module without initializing it, which made the static option obsolete. The only reason ProcessWire still recognizes it is for backwards compatibility, or if it happens to be preferred by the module developer for one reason or another.

@Jim Bailie Your _init.php is called for every $page->render(); so if you've got more than one page rendering in the request, _init.php will be called for both of them. One example of that would be if your template file does a wire404(); then _init.php would be called for the page that started rendering, and also for the 404 page. The reason for this is that _init.php usually establishes variables and such that you might want to populate or use in your template file or in your _main.php, so it has to be called on every page render. If you have a need for it to only be called once, such as if you are defining functions in it, then just move the contents of your _init.php to another file, like _init-once.php (or whatever you want to name it), and then do this from your _init.php: include_once('./_init-once.php');

I've been working nonstop in ProcessWire all week, but for client work. So this week there are just a few updates on the dev branch, mostly attending to minor issue reports from the last week or so. I have another week of client work left, so next week may be similar, though we may be able to bump the version number next week (on dev but maybe also master/main). Following that, I'm looking forward to working on and collaborating on some more substantial core development and upgrades. I hope that you have a great weekend!

This week we have ProcessWire 3.0.229 on both the dev and master/main branches. At this moment, both branches are equally up-to-date. Though I've not yet added the 3.0.229 tag just yet, as it is Friday after all. 🙂 So I'll tag it this weekend or Monday. If you are already running the dev branch on version 3.0.228, then this version contains a few issue fixes and is worth the update. If you are running the previous master/main version 3.0.227 then this version has quite a few worthwhile fixes and I'd recommend upgrading, at least once we add the 3.0.229 tag. Here's a link to the current commit log. That's all for today, have a great weekend!

@Roych That's coming from the SystemNotifications module because it has the "Active automatic notification hooks > 404 page not found" option enabled in its module configuration. I would recommend uninstalling the SystemNotifications module (Modules > Wire > System), as it's not needed and adds some overhead to your admin. But if you find you do need it for something, then you could disable that 404 option in the module config. As for those 404s, those are very common and many sites get thousands of them a day. They aren't a cause for concern unless you are running a non-updated WordPress or something. But even without WP, they are a nuisance and consume server resources unnecessarily, so if you want to block them the ProDevTools Request Blocker module does a good job of it.

@elabx title!=Test|test seems to work okay in testing here. Though note that there's no reason for the OR condition there, unless you've manually converted your database collation to be case sensitive, which I don't think I've heard of anyone doing before. Other parts of your selector to look at would be the created_users_id!=41, since that would exclude all pages created by the original superuser. Also city_id|cities=11669 seems like it might be worth removing temporarily to test as well, since it looks like it's two different fieldtypes (integer and page field?). In any case, if using 3.0.215 you probably want to update to 3.0.228.

Last week we had a big update of Pro modules and this week we have another batch of Pro module updates. These are now posted and available for download in the relevant boards: ProDevTools Profiler Pro (v3) ProDevTools Sitemap XML (v4) ProDevTools ProcessWire API Explorer (v5) ProDevTools User Activity (v7) LoginRegisterPro Frontend File Inputfield (v3) FormBuilder Stripe Processor (v3) FormBuilder Stripe Inputfield (v9) If you use the ProcessWireUpgrade module, it can also tell you when Pro module updates are available. In addition to the Pro module updates, we also have a new dev branch core version available: 3.0.228. ProcessWire 3.0.228 primarily focuses on fixing newly reported issues. We'll likely merge this version to the master/main branch sometime early next week because it contains a couple of fixes that belong on the master/main branch. For instance, there was a bug with ProcessWire's pages_parents table (present for the last year) that could affect the result on has_parent selectors in some situations. There was also a bug found by @Robin S where ProcessWire's image fields weren't using the stored/cached value for width/height on images, and instead was pulling it from the image file, which takes more time. So for image-heavy pages, 3.0.228 theoretically could offer a nice performance benefit (especially in the page editor), and is a worthwhile upgrade. Thanks for reading and have a great weekend!

This week I've been finishing updates for many of the Pro modules with new versions posted today for the following modules: FormBuilder (v55) ProCache (4.0.5) ProMailer (v13) ProDrafts (v10) ProDevTools Form Auto Saver and Reminder, also posted in FormBuilder (v3) ProDevTools Page Auto Saver and Live Preview (v8) ProFields Combo (v12) ProFields RepeaterMatrix (v11) ProFields Table (v25) ProFields Verified URL (v6) ProFields Textareas (v10) ProFields Multiplier (v15) These new versions don't necessarily contain new features, with a few exceptions. But they do contain maintenance updates for PHP 8.2+ and jQuery 3.6+ where needed. They also contain various small fixes, improvements or documentation adjustments. Pro modules not mentioned above will also receive updates in the coming week (or weeks). I thoroughly tested all of these modules with ProcessWire 3.0.227 before posting. But all of these versions are posted as "dev" or "development" versions. What does that mean? It means that that at the time it was uploaded, I was the only one using it so far, and thus they've only been tested thoroughly by me, today at least. The term "dev" doesn't mean that the version isn't stable. In fact, often times the dev version may be more stable than the last posted non-dev version. (Kind of like how the core dev branch is often more stable than the master branch). The dev designation just means that I can't claim it to be the most stable version until it's been out for a little while longer, with more people testing it. If you see a dev version posted that has been out for several weeks, then you can usually consider that the current stable version. The exception would be if it also says "beta", or something else to indicate it's a testing version. Early this week the core master/main branch was also updated to version 3.0.227. This version contains fixes for bugs reported since 3.0.226 master/main was released. A 3.0.228 bump is also in the works for the core master/main branch. I'll likely be working on Pro module updates for another 1-2 weeks here, along with issue fixes to the core. As a result, the 3.0.228 version will likely be merged to the master/main branch in the next couple weeks as well. I figure we might as well keep updating the main/master branch with small fixes and such until we get into more major dev branch updates. Thanks for reading and have a great weekend!

@joe_g In that case the $user must have been a NullPage. I'll set it up to throw an Exception with a more clear error message when you try to save a NullPage.

This week there have been a few updates to the core on the dev branch, but nothing major. Next week I'll be bumping up the version to 3.0.227 and then likely merging back to the master/main branch again. While there aren't major updates relative to 3.0.226, that means there isn't a lot to test or break, so it makes sense to keep updating the main/master branch until we get into more significant updates on the dev branch. In addition to getting into more significant dev branch updates, I'm also planning to put out version updates on nearly all the Pro modules in the upcoming weeks. Thanks for reading and have a great weekend!

You would think that Stripe could come up with at least one web design/development related category. After all, they have "Alcohol", "Marijuana-related products", "Weapons Or Munitions", and "Betting Or Fantasy Sports", but absolutely nothing for folks like us… no web design, development, or any kind of design or programming topics. The only one that mentions anything online/internet related would be "Online gambling", so maybe that's the closest one?

If you want to add hooks in your ready() method, you could probably call the ready() method at the end of your install() method?

@prestoav Is it possible you've turned off URL segments for your admin template? That error comes from /wire/core/ProcessController.php (here) when it can't match up the current URL segment to a method in the Process module. It would be worth looking at the Network tab in your browser to see what the full URL is when it's failing.

Happy 1st of September! Now that we've got the new main/master version out and running smoothly, I've been catching up with some client work this week. I'll need to do some of that next week too. But we'll also be fine tuning the core and fixing anything that comes up in issue reports. We may have have another master version out with these kinds of minor updates before digging into more major updates, feature requests and PRs on the dev branch this month. If you've not yet upgraded to 3.0.226 yet, I'd encourage you to give it a try. So far all reports have been positive and I've not heard of anyone running into any upgrade issues yet. Thanks and have a great weekend!

After 8 months in development we are excited to bring you ProcessWire 3.0.226 main/master. This version has a ton of great new features, improvements and optimizations, plus more than 100 issue fixes. This post takes an in-depth look at highlights from this great new version. While there's even more in this version than is covered fully here, we hope this gives you a good taste of what you'll find in 3.0.226! https://processwire.com/blog/posts/pw-3.0.226/

The master/main branch is now updated to version 3.0.225. Early next week I'll be adding a git tag for the version number as well. I usually like to merge dev to the master/main branch first, let it marinate for a day or two, and then tag it. That's because once we tag it, it triggers other services to pick it up and broadcast it. So letting it marinate for the weekend just adds a layer of comfort, for whatever silly reason. That's pretty much how I've always done it. When I did the merge, it reported 511 files changed, 76421 insertions(+), 23539 deletions(-), so there's quite a lot in this version. There's enough, that I'm going to need another week to document it all into a new blog post, which should be ready by this time next week. Our contributors list also continues to grow nicely with this new version. Thanks to all those that have submitted PRs, reported issues, and submitted feature requests. Big thanks to @matjazp in particular who has been helping a lot in identifying, testing, organizing and even coding the solutions for numerous issue reports. More details on this new version next week. Until then, thanks for reading and have a great weekend!

This week we've been resolving a few more remaining issues, mostly those that take more time or discussion. So there's not many commits to the dev branch this week, but that also means we're very close to having the main/master version ready. I'm hopeful we'll be there by this time next week. If you have a chance to test the current dev branch please do, and let us know if you run into any issues. Thanks and have a great weekend!

This week on the core dev branch is ProcessWire 3.0.224! Relative to 3.0.223 it has 25 commits and 17 issue resolutions (see dev branch commit log). I think we are within 1-2 weeks of having the new main/master version, so I'll be looking closely for any new reports. Consider us now in a dev branch feature lockdown in preparation for the main/master version. At this stage, there likely won't be any new features added or issue resolutions that would require significant field testing (at least not until the merge to main/master). If you have a chance to test the current dev branch version, please do, and let us know if you run into any issues. Thanks and have a great weekend!

In a recent GitHub issue report, I was asked about output formatting in ProcessWire, and where more information could be found about it. I know I've written about it numerous times, and went to locate the documentation page, only to find we didn't have one! Output formatting is such an important topic, so here is everything you need to know. I hope you'll find it simple enough, but also useful and thorough— https://processwire.com/blog/posts/output-formatting/

Like last week, work continued on preparing our next main/master version by working through remaining issue reports, this week with a focus on older and previously missed reports. Thanks for bumping up any that we may have previously missed. Thanks also to @matjazp for helping to identify and prioritize them. In addition, the version number was updated to 3.0.223 this week, as there were enough changes to warrant differentiating it from 3.0.222. It wasn't all issue fixes this week, as several minor additions and improvements were completed as well (see the dev branch commit log). Next week will continue along the same path. Thanks and have a great weekend!