ryan

There's a couple things that made me think this part of the core could be better (and nothing related to middleware). First is that PW didn't originally support multi-language URLs, and so the LanguageSupportPageNames module was built to hook in and add support for that. There are benefits (performance, simplicity, etc.) to having that logic lower-level in the core and part of the same logic that identifies non-multi-language URLs. So that's something I've been interested in for a long time, but it was always more than I wanted to get into. The other thing is that I was working on that SessionAllow module and found it was a real drawback not to be able to know what Page was requested before deciding on things like whether to allow a session or not. Granted, we can still know the request URL before we know the Page, but it just seemed a lot more flexible for the core to know the requested Page much earlier in the boot process. That way, we can do things like configure whether sessions are allowed on a per-template basis, where such an option seems to make the most sense. Another example is 404 pages—maybe we don't need a session on a 404 page. But without knowing whether the URL will resolve to a Page or not, we didn't have that choice. Following these updates, we will. Lastly, I just like to revisit the core logic for things and improve it when/where possible, which helps to keep it fresh on the mind. But I don't like to get into replacing this kind of major core code when it'll soon be merged to the master, as this is the kind of stuff that needs more testing over a longer period of time. So with a comfortably stable master version available right now, it seemed like a good time to work on this.

This week I've been focusing on the dev branch and some low level code optimization, especially as it relates to the PW boot process, translating URLs to pages and identifying the page, language, URL segments, page numbers, etc. from the request URL. I'm breaking down much of the logic (currently in the ProcessPageView module) into more focused parts that can become part of PW's $pages API, increasing reusability of related code. (Don't worry, this won't affect any existing hooks). At the same time, I'm looking for opportunities for optimization and performance improvement, and have already found a few. For instance, the LanguageSupportPageNames module introduces overhead into some page finding operations and there's good improvement potential there, among others. I'm pretty much still in the middle of it all though, so am going to hold off on committing any of this to the dev branch until it's further along. But since we've got a quiet commit log this week, I just wanted to keep you up-to-date. Hopefully some of these fairly significant updates will be stable enough to commit to the dev branch next week. By the way, these updates will also enable the SessionAllow module (from last week) to be configurable by page, as PW will now identify the requested page before starting the session. More soon. Have a great weekend!

ProcessWire 3.0.185 is the latest version on the dev branch this week. Relative to the current master (3.0.184) this is 9 commits ahead and contains various minor fixes, improvements and additions. Since our current master version is quite stable and no significant issues have surfaced since release, we'll likely be focusing on the dev branch for several versions before merging back to the master/main branch. For details on what's new in 3.0.185 dev see the commit log. ProcessWire Weekly #383 also includes some details on a few new selector features added last week that you'll find in this version, read about it here. Today I've posted a new module in the directory called Session Allow. This module enables you to configure whether to allow sessions for each request based on simple configured rules. Currently it requires ProcessWire 3.0.184 or newer. The reason I built this module is that I find the current $config->sessionAllow setting (where you define a custom function) can be a little complicated to work with, especially since it gets called before most of ProcessWire’s API can even be used. This module aims to make control of sessions a lot simpler than that. The benefit of being able to control when a session is allowed is that it lets you better focus your resources for sessions to just the requests where they will be needed, helping to reduce server overhead and improve performance. Currently it supports allowing (or disallowing) sessions based on page path matching rules and hostname matching rules. I also plan to add support for sessions allowed/disallowed per page template, which I think would be really useful. But it'll take some changes to the PW core to support that, as ProcessWire starts the session before determining what page has been requested (and thus what template will be used). So I'm going to make the necessary core updates and then save that feature for version 2 of this module. I'm releasing the module as "alpha" right now because I rushed a bit to get it out for today and feel it needs more testing before I can call it stable. So if you are interested in using it, make sure to test everything out in a development environment first. And if you do get a chance to test it, please let me know how it works for you. Thanks for reading and have a great weekend!

@horst Like with matching a "parent=" or "has_parent=", it just sends the path to another $pages->get('...'); call to lookup the ID, so it should work with any path that $pages->get() would accept.

This week there are a few minor updates on the dev branch, though not enough yet to bump the version. The most notable are a few improvements to the database selectors you can use with $pages->find() and similar API calls. While working through issue reports a few weeks ago, there were a couple issue reports that indicated one selector or another not working. What I found was that it was working as designed/built, but they were just selector features that had never been supported. But they also seemed like good/useful shorthand syntax to support, so I was enthusiastic to add support for them. I just wanted to wait till we were back on the dev branch, as we are now. Here's what's been added: Support for OR values on "status=" selectors. Now you can match one status or another with PageFinder selectors by specifying a selector like "status=hidden|unpublished", and this will find all pages that either have hidden or unpublished status. The hidden and unpublished are just likely the most common examples, but you can use any other status name, or as many statuses as necessary in your OR condition. Previously it was possible to match pages having one status or another by other means, but it was far from straightforward. Now it's nice and simple. Support for OR values on "sort=" selectors. This one isn't technically an OR condition since we are giving a command to the selector engine about how it should sort, rather than trying to match something. You can tell it how to sort with the syntax "sort=date|title" as an example. That would be shorthand for "sort=date, sort=title", which is saying "first sort by date, then by title". Support for combined start and limit selectors. Previously you have had to specify "start=x, limit=y" separately, if you needed it. Now you can optionally specify both as part of the "limit", for example "limit=5|10" which is shorthand for "start=5, limit=10", and actually kind of similar to what it translates to in MySQL, which is "LIMIT 5,10". I suspect that not many people ever use "start=" in their selectors unless using "start=0" to prevent a set from paginating. So if you wanted a set of 10 pages that don't follow the current pagination, you could specify "limit=0|10" in your selector, or the more verbose "start=0, limit=10" will work in any PW version. Support for matching children paths. This is a small one, but previously you couldn't do "children=/path/to/page" to match a page having the given child path. Though you could do "children=123" where 123 is the ID of the child page. It has been updated so that it can now support paths in addition to IDs, just as "parent" does. I'm not sure why we didn't have support for this one before, it likely just hadn't come up yet. You can use OR values here too if you'd like. As before, you can also use subfields on "children" as well. Worth mentioning is that these are additions for our PageFinder engine which queries the database. We also have the lesser used in-memory selectors which don't yet support all of these, but I've put it on my to-do list. In-memory page finding selectors come into play if you are post-filtering pages that you have already loaded from the database into a PageArray. We like these to maintain some consistency with the database selectors when possible, so I'll likely have that working here soon. From this end, I'm also putting ~2 hours of work into the new Pages Snapshots module every day, with a lot of progress but also still a lot of ground to cover. Separately, I'm working on pulling more than 4 million articles out of an older proprietary legacy CMS for a newspaper organization and converting them to a standard XML format for import elsewhere. A lot of data conversion has to take place in terms of cleaning up markup for each article. ProcessWire is the tool that all of this is being done in, and I'm using a lot of $sanitizer methods as well as keeping HTML Purifier busy! Thanks for reading and have a great weekend!

@MarkE Was this bodyFoot thing querying the database, or doing something memory? When querying the database with something that uses an index, it can be affected by what characters MySQL indexes as part of a word. Though I think MySQL would much more commonly index "myText" and not "<p>myText". It may come down to more specifically what the exact text that you are using in that bodyFoot query, like perhaps it's matching a stopword? Or if this is a selector that isn't querying the database, it could be tested like this: $value = WireData([ 'text' => '<p>myText, some more text, ... </p>' ]); $tests = [ 'text*=myText', 'text%=myText' ]; foreach($tests as $test) { $s = new Selectors($test); echo "<li>$test: " . ($s->matches($value) ? 'Yes' : 'No'); } I get "Yes" for both fo the tests, indicating it matches. Though I recognize this is probably not the real text you are matching.

@MarkE That I think may be defeating the purpose of making it load on-demand. What I intended to suggest is to add that adminSite() function, and then replace any of your calls with setting('admin_site') with adminSite(). For example, rather than calling setting('admin_site')->pages->get('...'); you'd call adminSite()->pages->get('...'); and it should do the same thing. The main difference is that your admin site doesn't get booted until the first time the adminSite() function is called. That's desirable because it prevents you from booting it when you aren't going to access it, saving overhead. A function can only be defined once, so it doesn't matter where you call adminSite(); from whether site-admin or site-web. Great! Glad that it seems to be working now. As for why the *= wasn't working, I think we'd need to look at what is in $host in order to tell. It would also be good to know the full context of that bodyFoot*=$host, for instance is that selector being sent to a $pages API call, or to something else? The biggest difference between *= and %= is that *= matches from the beginning of a word boundary whereas %= matches anywhere in the string. So if you've got an instance where %= is matching and *= isn't, then most likely it's because of that difference. If its querying the database, then *= is also subject to stopwords and minimum indexable word length (typically 4) whereas %= is not. @AndZyk Interesting, I'll have to try that out. Are you using the latest German language pack released by @dotnetic or a different/earlier one? I think the capitalization issue might not be specifically with InputfieldTextTags but with its usage in ProcessField/ProcessTemplate. I don't think there's a reason to avoid using it elsewhere. @kongondo The InputfieldPage had to be added because often InputfieldTextTags is used in combination with InputfieldPage. The jQuery selector ".InputfieldTextTags, .InputfieldPage" seems to be valid. Does the error trigger on that line in particular, or does it occur sometime later? Do you find there is any difference if you set $config->debug = 'dev'; ? That will make it use a newer jQueryCore version. That was throwing up the JavaScript error I posted above. My remedy was to let ProcessWire Inputfields trigger the reload, like this: Glad that seems to have fixed it. If this works, and triggering 'reload' manually didn't work, it means that $myInputfieldTextTagsSelectItem is not an .Inputfield element. The 'reload' event is is specific to .Inputfield elements, so the Inputfields.reload() method will attempt to locate the and trigger the .Inputfield element if given something other than an .Inputfield. I think that must be why it is working when the manually triggered one wasn't?

@wbmnfktr I don't see anything wrong there, that all looks like exactly what it's supposed to do. It may be a bit verbose but I think that's best when debug mode is enabled, especially on new installations. Rest assured, all looks well with your installation. It's kind of like how when you buy a new computer or phone, it installs whatever updates are needed to ensure that everything is up-to-date. @shadowkyogre This is not new to 3.0.184, but check to see if your title field is globally required on all templates. If so, you may want to disable that setting. It is in the field editor on the "Advanced" tab, when editing your title field. Or if you just want to disable the setting for the template that you are using, enable $config->advanced=true; in your /site/config.php file, edit the template in Setup > Templates, click the "System" tab and check the box to "Disregard global fields", for that template. Then remove the advanced setting from your config.php file, unless you want it for something else. @MarkE I'm not aware of a difference that would affect that, but wanted to suggest booting your other site on-demand rather than on every page render. So I would replace your setting() call with the following: if(!function_exists('adminSite')) { function adminSite() { static $instance = null; if($instance === null) $instance = new ProcessWire($config->paths->root . 'site/'); return $instance; } } Then anywhere you need your instance, do your calls like adminSite()->pages->get('...'); Next, make sure that your instances are both running the exact same ProcessWire version. The other thing that's a little unconventional here is that the site you are booting is using the /site/ dir, which is ProcessWire's default. Usually if booting another instance, it would be in a different location or be using a /site-something/ dir rather than the default. I'm not sure if that's a potential issue or not, but wanted to mention it just in case. You might want to rename your /site/ to /site-admin/ so that there is no /site/ directory which would typically be the primary instance. I can assure you that PW isn't editing your file. But I agree that is really weird. Whatever is doing that might be the source of the issue. This sounds like the sort of issue I run into when I edit a file on the wrong node of a load balancer, and a moment later it gets replaced by the primary node. Make sure that you are using <?php namespace ProcessWire; at the top of your templates and any other PHP files, just to rule out anything file compiler related. Also check what /site/modules/ you have installed just in case.

Last week we released the new ProcessWire 3.0.184 master/main/stable version. This is our biggest version release in a year. It's been a very smooth stable version launch with no major issues so we're keeping the version number where it is this week. If you haven't upgraded yet, it's an easy and worthwhile upgrade. For full details see the blog post that covers it all. This week I have 3 new Textformatter modules released in the modules directory. These are modules that I developed earlier for recurring needs that I had, but this week decided to finish them up and release them. I hope that you might find one or more of them useful sometime. TextformatterFindReplace This module applies find/replace patterns to formatted text or markup at runtime. The patterns may be simple text or more complex regular expressions. This module can be handy if you perform a text replacement on all output from a particular field, without having to manually make the change on all instances where it might appear. For instance, maybe you need to insert a trademark symbol ™ after every appearance of a brand name, or maybe your website hostname has changed and you need to replace all references to it, or perhaps you need to replace all <h1> headlines with <h2> headlines. These are just a few examples of any number of possibilities. Read more / Usage / Examples TextformatterMarkdownInMarkup Enables you to use Markdown formatting codes in CKEditor (or HTML). A significant amount of content that is populated into the “bodycopy” field of websites is not actually written in the admin and instead originates from text editors, word processors, and other tools outside of the CMS. It then gets pasted into CKEditor, and then manually formatted into HTML using tools in CKEditor. This process of manually converting links, lists, headlines, bold, and italic text and more can be sometimes very time consuming. This module provides a time saving alternative, enabling use of markdown formatted text in CKEditor (or any HTML/richtext editor). It remains as markdown formatted text in the editor, but as soon as it is rendered on the front-end it is automatically formatted as HTML. This means that text like **this** gets converted to this, links like [this](https://processwire.com) get converted to this, and so on for most types of markdown formatting. This enables markdown formatted text to be written anywhere and the formatting to be rendered properly in your bodycopy when viewed on your website. Using this module means that you can mix richtext and markdown in the same copy. No longer do you have to manually convert all of the links, lists, bold/italic, and so on in pasted in text. This module saves me quite a bit of time when writing blog posts like the one last week. Much of the formatting in that post was markdown based, since I wrote the post in my text editor over a period of a couple weeks. Once I got it into CKEditor, I did some formatting with that too, but when it came to other formatting (especially links and inline `code`) it was a big help to have them just work, and not to have to re-do all of them manually with CKEditor tools. So why not just work exclusively in Markdown? Well I don't like working with just markdown most of the time, I much prefer CKEditor. But I also can't deny the convenience of markdown for a lot of cases too. So being able to use Markdown within CKEditor is the best of both worlds, to me at least. Read more / Supported markdown / Configuration options TextformatterEmoji This module converts more than 800 named shortcode emojis in ProcessWire text or textarea fields to the corresponding UTF-8 emoji character. ? This can be especially useful if your ProcessWire database uses the utf8 character set rather than utf8mb4, as it enables you to use emojis on an installation that typically would not be able to save them. This is because emojis usually require utf8mb4 (4 bytes characters) to be used by the database in order to store them. Though when you want to specify an emoji by name, this module will be useful regardless of your database charset. Read more / Supported emojis reference

@AndZyk I haven't been able to duplicate that issue, but to me it sounds like maybe browser cache. I am also using MAMP locally (though not MAMP PRO). You might try incognito mode to see if that makes any difference. If that's not it, then it might be worth checking if any other modules are installed that might be conflicting with InputfieldTextTags, as the error does seem to be originating there. Please let me know if you find anything more. Regarding mixed capitalization in tags, there's an open issue report on GitHub for this. I spent half a day trying to fix it a month or so ago, but couldn't figure it out and gave up on it temporarily to try again later when back to the dev branch. Until we have a solution for that it's likely preferable to avoid mixed case tags for fields or templates.

TextformatterEmoji converts named shortcode emojis in ProcessWire text or textarea fields to the corresponding UTF-8 emoji character. For instance :smile: converts to: ? This can be especially useful if your ProcessWire uses the utf8 character set rather than utf8mb4 as it enables you to use emojis on an installation that typically would not be able to save them. This is because emojis usually require utf8mb4 (4 bytes characters) to be used by the database in order to store them. Note that how the emoji appears (and sometimes whether it appears) can vary from platform to platform, and from browser to browser. Here is an alphabetical list of supported emojis and the shortcodes you can use to show them in your text. If you want to add any emojis that are not already present you can do so in the emojis.json file.

This week we have a new master/main version released after a full year in the making. With nearly 40 pull requests, hundreds of new additions and more than 100 issue reports resolved, this new version has a ton of great new stuff and we’ll cover most of the new stuff here— https://processwire.com/blog/posts/pw-3.0.184-master/

@hollyvalero Looks like I broke it on the dev branch trying to resolve another issue report on Friday. Sorry about that, I have just pushed a fix. Thanks.

This week the dev branch contains about a dozen issue fixes relative to this time last week. (commit log) While these are all relatively minor things, some have been around awhile and it's always nice to get them figured out. Plus it's often a good opportunity to iterate and improve upon related things in the process. While I think we're very close to being ready to merge to the master branch, I'm going to give it a few more days just in case. I want to make sure no new issues arise (no matter how small) as a result of all the commits we've been doing over the last few weeks with GitHub issue resolutions. Most likely there won't be many more commits on the dev branch before the merge, and perhaps by this time next week, we'll have version 3.0.184 as our next master version. Following that, I'll write up a post that documents everything new relative to the previous master version 3.0.165, as there has been quite a lot! But if you want to upgrade now, I do think there's very little risk in upgrading existing master/main installs to the current dev branch, as it is quite stable at this point, in my experience. Thank you for all of your help in testing and/or reporting issues. Have a great weekend!

Work continues on the next master/main version here as we close out older issue reports and finish minor tweaks and adjustments. Eight issues were resolved this week. That might not sound like much, but with the most pressing issues already resolved, more of the GitHub time now goes towards discussion, support and more administrative related stuff, than to actual work in code. Issues remaining and being worked on are those that affect very few and might be more time consuming or difficult to reproduce, or are more subjective. We're very close to our next master version and unless anything new that's particularly pressing arises this coming week, I think we may be there next week. If you have a chance to help us test the current dev branch, please do. Thanks for your help and have a great weekend!

Relative to ProcessWire 3.0.182, today's version (3.0.183) contains about 30 commits and resolves 23 issues. It also contains various small tweaks and improvements throughout. For example, when editing the title of a page, it updates the headline as you type in the page editor (in Uikit and Reno admin themes). I think we've got another 1-2 weeks of these kinds of updates (resolving issues and minor improvements) before we release the next master version, and am currently thinking that version will carry version number 3.0.184. I'm also continuing work here on the page snapshots module I wrote about earlier, but am going to wait releasing it until the next master version is complete. If you have a chance to test out ProcessWire 3.0.183 on the dev branch, please let us know how it works for you, and especially if you run into any issues. Thanks for being here and have a great weekend!

This week we have 12 new commits to the dev branch largely focused on resolving older issue reports. Since the focus right now is primarily on getting the next master version live, we'll likely keep this focus for the next week or two, making sure the next big release version strikes the best balance between new features, issue resolutions and timeliness. Thanks for being here and have a great weekend!

ProcessWire 3.0.182 is now posted on the dev branch. For a review of what's in this version, see the "Latest core updates" section of ProcessWire Weekly #374 and #375 plus this week there have been 12 additional commits with new issue resolutions, improvements and additions which can be found in the dev branch commits log. It's possible that ProcessWire Weekly #376 will also cover some of these updates when it is released too. I'd planned on even more in this version, but ended up losing a day of work yesterday as we had no electricity all day (it happens). So I worked outside in the yard instead— 3 issues were resolved, 4 improvements were made and 1 garage was organized. Focus in the coming weeks is on our next main/master version (core, not yard). If you have a chance, please take a moment to add sites you've built with ProcessWire to our sites directory. And if it's one that's already in the directory, feel free to add it again when/if it goes through a major redesign or redo. I'm really motivated by seeing the great work that all of you do and always enjoy seeing more of it. Plus, I'm thinking @teppo also likely looks at the newly submitted sites when considering the site of the week for his ProcessWire Weekly issues. If you find the existing categories on the submission form don't quite match a site you want to add, please send me a PM to let me know and I may be able to add new categories. Thanks for reading and have a great weekend.

This week has been a continuation of last week in terms of ProcessWire development. While a lot of work has been done, there's not much new to report relative to last week, but I like to check in and say hello either way. I enjoyed putting a lot of time into the PagesSnapshots module this week and it's coming along nicely, getting closer every day. Today I've focused primarily on resolving GitHub issue reports, and am going to keep doing that every week till our next master version, which I hope to be ready in 2-3 weeks (same for the new module). But we'll adjust as needed. The next master version is going to be really solid, so I'm getting excited about it. I will likely bump the dev branch version to 3.0.182 next week. There were a couple more minor issues I wanted to get resolved in 3.0.182 but needed to spend a little more time with before I commit to the dev branch. Thanks and have a great weekend.

While the version remains at 3.0.181 this week, there have been several core updates committed to the dev branch containing a mixture of issue fixes, new features, core optimizations and upgrades. This is likely to continue for another minor version or two while we prepare for our next master branch release. The most visible improvements this week can be found in ProcessField and ProcessTemplate (aka Setup > Fields, Setup > Templates). The main list of fields (Setup > Fields) has been improved with some new supported icon indicators that now identify fields that have template overrides/context settings, among others. All of the existing icon indicators have also been updated with contextual links so that clicking them takes you to the relevant part in the template editor. My favorite update here though is that the "Type" column in the fields list now indicates the Inputfield type in cases where it matters. For instance, rather than saying "Textarea" for the "body" field, it now says "Textarea/CKEditor". Likewise, Page and Options fields indicate what kind of input is used (i.e. "Page/AsmSelect" or "Options/Checkboxes"), as do some other types. Clicking on the "Templates" quantity now takes you to the "Add/remove from templates" field, rather than just showing you a list of templates. Similar updates were made to the ProcessTemplate main list of templates (Setup > Templates) though there wasn't as much to do there. Once you are actually editing a template, the instructions on the "Basics" tab have been improved to clarify what you can do on this screen. For instance, many don't know that you can click a field name/label to edit it in context, or that you can click and drag the percent indicator to adjust the field's width in the editor, all from this tab in the template editor. Now the description outlines these features. When you select a new field to add to your template, it now reveals a note that clarifies you must save before the field becomes editable in the context of that template. These are minor updates, but combined I think they add significant clarity, especially for new users. Stepping outside of the core, I've been working quite a bit this week on the PagesSnapshots module I told you about a couple of weeks ago. It lets you save or restore snapshot versions of pages, and it doesn't have any notable limitations in terms of fields. At this stage it is working fully with repeaters, matrix repeaters, nested repeaters, Page Tables and even paginated Table fields with thousands of rows. It can restore to the original page, to a new page, or to another page of your choice. And it is very fast. Eventually ProDrafts will use its API to handle saving and publishing of draft versions. Initially I plan to release it in one or more of the existing module sets (like ProDevTools or ProDrafts or both), and longer term it may be added to the core. I've got another week or two of work to cover with it, but at this stage the API is fully functional and working well, so I'm now beginning to focus more on the Process module (user interface) side of it. Thanks for reading and have a great weekend!

@thetuningspoon It doesn't have anything related to that, but that example you mentioned could easily be accommodated with a hook to Pages::clone. Or maybe it's something that should be built into FieldtypeTextarea’s link abstraction. @Ivan Gretsky Yes it definitely has the API for that sort of thing. @markus_blue_tomato Yes it does include the $page->meta() data by default, but you can specify an option to exclude it when/if you want to.

ProcessWire 3.0.181 has fixes and improvements as usual, but the biggest addition is a nice pull request from @LostKobrakai, plus major updates to our Helloworld and ProcessHello demonstration modules. This post covers it all— https://processwire.com/blog/posts/pw-3.0.181-hello/

I've got some core updates in progress but nothing major committed yet, so we'll save that for next week. But I wanted to briefly tell you about a module I'm working on here, which I plan to eventually put in core. I built it for some needs I've had here, but it will first be released in ProDrafts (so ProDrafts may start using its API), and in ProDevTools too, since it is also a developer tool. It's a snapshot versioning system for pages, but more of an API tool at this stage, kind of like the $pages API var, but for snapshots/versions of pages. It lets you create a snapshot of any page, including its fields and files (including core fields, ProFields, 3rd party fields, repeaters, nested repeaters, table fields with a million rows, etc.). The snapshots can be restored at any later time. Snapshots may also be restored to a different page, such as a new or existing page. In this manner, a module like ProDrafts may be able to use it to manage draft versions even better than it currently can, or at least that's the plan. Though since it's an API tool, my hope is that when/if it winds up in the core, others may be able to use it for stuff we've not thought of yet too. The module is a little different than my previous attempts (like what's in ProDrafts now) in that it does most of its work directly at the database level (and file system level, where applicable), which enables it work without needing to know much about the Fieldtype. Currently it is fully functional, but I have a few less common cases to work out before it's ready for release. Once installed, every page includes a Snapshots fieldset, which can be located in the settings tab of the page editor, or a separate tab in the page editor (configurable). When installed, every page has one, so long as the user has the appropriate permissions. There's a screenshot of what it looks like in the page editor below, but it is very simple at this stage, basically just enough for testing purposes. Every snapshot has a name that is unique on the page. You can overwrite a snapshot just by saving a snapshot with the same name on the same page. So you could for instance have a hook that creates a snapshot named "undo" right before a page is saved (in a Pages::saveReady hook), and in that way a module could add a basic undo capability to the page editor. This is just a simple example though. Thanks for reading, have a great weekend!

ProcessWire 3.0.180 contains 20 commits containing various minor new features, issue resolutions and pull requests. While there's no single major feature to write a big blog post around, combined there are a lot of worthwhile and useful updates so this version is definitely worth updating to. More details can be found in the dev branch commit log and at ProcessWire Weekly (issue #370 covered an addition to our $files API var). Yesterday the forums were running a little slow because we had our yearly DDOS’er pay the site a visit once again (remember last time?), and from an apparently unlimited supply of IP addresses around the world this time. We shut down the forums to users that weren't logged in while the load was high. Actually, it does this automatically now. We also updated the forums from using memcached to AWS Redis, which should also help as a nice upgrade for the forums. Big thanks to @Pete and @Jan V. for setting it up and keeping everything running smoothly. I'll keep it short today because it's supposed to rain here all weekend, so I'm going to spend some time outside while I can. Thanks for reading and have a great weekend!

@Jonathan Lahijani Good idea, I need to add those to mine too. Note that %= is the default/assumed operator, so you can make it even simpler (if you want) by just entering this: search engine optimization seo The thing you have to consider here though is if "seo" can appear as part of other words? The %= operator is a partial match operator without boundaries (same as in $pages->find), so it'll match words like Passeo, Osseo, Seoul, Seola. Given that, for matching "SEO", you probably want to perform a full word match, i.e. ~=seo