Leaderboard

Another quick and easy one ? Place this in /site/templates/admin.php before the require(...) statement: $this->warning('Attention: We have planned maintenance starting 2021/02/11 from 10:00 AM - log out before that date to prevent data loss.');

Not sure if it is the TracyDebugger one, to indicate site you are on? I could be wrong. I cannot remember if that feature is still supported

One approach would be to use a hook in ready.php, adapting the method described in this post: You'd probably end up with something like this (not tested): wire()->addHookAfter('ProcessPageListRender::getPageLabel', function($event) { $page = $event->arguments('page'); $modifiedFormatted = date("j.n.Y", $page->modified); $event->return = $event->return . ' ' . $modifiedFormatted; });

Last week I asked you what you'd like to see in ProcessWire in the next year (and years ahead), and we got a lot of feedback. Thank you for all the feedback, we've had a lot of great and productive discussion, and of course feel free to keep suggesting things too. Below is a summary of things based on what I thought was feasible from the feedback so far. I'm not suggesting we'll be able to do all of this in 2021, but do think it makes a good preliminary roadmap of things to look closer at and start working on some very quickly. I'll keep working to narrow this into a real roadmap, but wanted to share where we're at so far (consider it preliminary/unofficial): Flexible content or page building One of the most common themes has been that people want more content building options as an alternative to using a rich text editor at one end, and page builder at another. This is a direction that some other CMSs have been going in (like WordPress), and one that many would like to see ProcessWire provide an option for as well. But the needs seem to come from two different angles, and it points to us pursuing 2 directions simultaneously: First would be a flexible content block style editor in the core as an alternative to rich text editor that supports pluggable block types while maintaining best content management practices. If possible, we'd use an existing tool/library like editor.js or another as a base to build from, or potentially build a new one if necessary. To be clear, it would not be a replacement for CKEditor but an alternative approach supported by the core. Second would involve improvements to Repeater/RepeaterMatrix that enhance its abilities in supporting those using it for building more complex content page builders. Since many are already using it for this purpose, the goal would be primarily to better and further support this use case, rather than make Repeater/RepeaterMatrix a dedicated builder. Jonathan Lahijani and others have pointed out some specific things that would help achieve this and I plan to implement them. Admin theme improvements We would like to add additional flexibility to the AdminThemeUikit theme so that people can further customize it how they would like it. What directions this will take aren't nailed down quite yet, other than to say that it's going to be getting some focus (and this has already started). At the very least, we know people want more sidebar options and the ability to tweak specific CSS, perhaps in a preset fashion. Improvements to existing Fieldtypes and Inputfields Things like support for a decimal column type, more date searching options and additional input level settings on other types. Though these are specific feature requests and our focus is more broad, so we'll be going through many of the core modules and adding improvements like these and more, where it makes sense. Pull requests and feature requests People would like to see us expand our code contributor base by merging more pull requests in cases where we safely do it. We will also be narrowing in on the specific feature requests repo to see which would be possible to implement this year. External API There are requests for an external/front-end API that would also be accessible from JS. I support the idea, but have security concerns so am not yet sure if or in what direction we might take here, other than that I would like us to continue looking at it and talking about it. File/media manager and more file sharing options There is interest in an option for a central media/file manager so that assets can be shared from a central manager rather than just shared page to page. There is also interest in the ability for file/image fields to reference files on other file/image fields. External file storage Some would like to be able to have PW store its /site/assets/ and/or /site/assets/files/ on alternate file systems like S3. That's something we'd like to use for this site too. To an extent, work already started on this last year with some updates that were made, but there's still a long way to go. But it will be great for sure. Live preview and auto-save There are requests for live preview and auto-save features to be in the core. Currently they are just in ProDrafts, but there are now more options and libraries that would facilitate their implementation in the core, so I'd like to see what we can do with this. More multi-site features There is interest in ProcessWire natively supporting more multi-site features, potentially with the option of working with our multi-language support.

Was just looking at it. Thank you for explaining ? R

Yep, it's Tracy - it's designed to give you a visual indicator as to whether you're working on a live, local, dev, staging etc version of the site. It is configurable to work with subdomains or TLDs. Take a look at the "Server Type Indicator" section in Tracy's settings. I find this really invaluable, but I know that @kongondo hates it ? Anyway, you can easily disable it if you want, but note that of course it's only visible to users with Tracy permissions, so visitors to the site won't see it.

In the "Selector string" setting for "Selectable pages" you can use "page" to refer to the current page, but only if you also specify a subfield using dot syntax. In your case you would use page.id to exclude children of a parent: template=item, parent!=page.id Unfortunately I don't think this is documented anywhere.

Is this theme still under development @Noel Boss? There are issues from 2019. I really like the theme and think there could be some improvements made. But it only makes sense to contribute, if it is still maintained. Or else we have to fork it and work on an optimized version.

I just released version 1.1.3 which resolves three issues that were reported recently: Fixes an issue with the constructor signature of the modules AppApiException class (by @David Lumm, thanks for PR ?) Fixes an issue with the error-handler, which made it mistakenly catch errors that should have been ignored via @ operator (Thanks to @eelkenet) Switched from `wire('input')->url` to `$_SERVER['REQUEST_URI']` for reading the base-url, because ProcessWire's internal function transferred everything to lowercase. (Thanks to Github-user @pauldro) Thank you all for your contributions!

Just make use of the $page variable like: "template=item, parent!=$page" Note the double quotes, or if you prefer: 'template=item, parent!='.$page

Thanks @wbmnfktr I think the Markup/HTML option refers to the where internal links go to rather than the format. Thanks @Robin S. I do often add that in the notes but it does seem to confuse some users — of they just don't read it. I like your hook idea though; that could be very effective.

Just my 2 cents: it should throw an exception here - this current logic is not good in my opinion.

Great additions - many of these are things that we have setup our own solutions when hitting performance issues on large scale (10 000+ pages with lots of fields) so it is great to see core supporting this kind of things. Thank you Ryan! Quick note on findRaw - it looks like it doesn't support parent? It would be very powerful to be using parent just like any normal field based page relation.

Do you mean that editors are pasting absolute internal links into the link dialog in CKEditor? If so you could try an education approach first, i.e. "Please create internal links via the fields in the link dialog". That way you won't get absolute internal links in the first place. Beyond that you could use a saveReady hook to do a string replacement in the relevant field(s): $pages->addHookAfter('saveReady', function(HookEvent $event) { $page = $event->arguments(0); // Perhaps limit by template as needed if($page->template == 'basic-page') { // Internal links: replace absolute href with relative href $page->body = str_replace('href="https://www.domain.com/', 'href="/', $page->body); } });

Flexible content or page building I've mostly used RepeaterMatrix for this. I think looking at some of the examples above, something in the core would be welcome and something with maybe a simpler interface too. Thing is, in my case, I still probably need the flexibility of what I can do with RepeaterMatrix but just making it even simpler for site owners once I hand things over is welcome. I'll have a think about it. Admin theme improvements 99% of the time all I really need personally is to maybe change the colours. It sounds silly, but anything that shows clients you're paying attention to detail is good - which is why I love that you can link their logo into the masthead and they like that, but colour scheme is the obvious addition if it's something we can just set with a colour picker or by entering a hex colour value or something in the admin theme settings. Improvements to existing Fieldtypes and Inputfields Decimal is something I really need for any site with pricing, or if trying to build any basic ecommerce functionality so +1 for that as I don't think it's something that adds significantly to the core hopefully. Seems small enough anyway. External API I have had more requests in recent years as a developer along the lines of "do you do mobile apps" and for all projects I want to use PW as a backend, so if there was a JS API I guess that would help (don't really know) but I also feel like some of the REST API activity I saw a few months back by someone (sorry, don't remember much!) would help with that. File/media manager and more file sharing options I think it's great to keep the current ability to upload images/files where they're needed in a page (and I know you wouldn't remove that) but if we could use tagging to help categorise images/files and that helps build the file/media manager feature that would make sense. I still think the point of initial upload would more often than not be when you need to upload the file for a specific page, but on a few larger sites I've found myself uploading the same header image to a few different pages because it was appropriate although they weren't in the same tree, and it would have been easier to re-use with a file/media that's tied to the file/images field, so in those fields if we had "Upload" or "Choose from gallery" as options - giving the ability to set a different description, tags and cropping for a single image depending on where we need to use it, and then the file/media manager is in charge of making sure when we delete one instance it remains in the other image field. Does that make sense? It comes up for me more often on larger sites, but also giving folks one place to look to see what images are already available can prevent repeat uploads of the same image. Sure it doesn't add much overhead, but it's still overhead. Not sure I've got the right solution there but something that doesn't require breaking out of the normal workflow is more intuitive in my mind. I think my point is that you don't always want to re-use the same image in a CKEDitor field, you might want to have it in a single/multi image field on more than one page and that's currently not possible to my knowledge. EDIT: I know you could maybe use tags to achieve this, or a field that selects files somehow like ASMSeect, but there are occasions where you want to re-use and re-order and re-uploading seems to be the only way. Maybe my use case is so unique though that it's too much to bother with the more I think about it. Seems pretty unique anyway.

I'm not sure I understand what you mean. We've got templates which define a Page's type in terms of fields, behavior and access. Then we've got custom Page classes which define a Page's type in terms of its API, which can also extend other Page classes. Then we've got Page tree/hierarchy/parents, which define their type in terms of location. I'm not sure what's left. ? Is there some other kind of page type you are talking about? I will update the AdminThemeUikit repo. Unfortunately I've run into some npm error where it wants to do some kind of updates before it will update the UIkit version, but updates it wants to do in npm fail. This seems to happen every time I want to update something that uses npm, but I always eventually find a way around it. This last one has had me stuck for awhile though. I'll revisit it here soon. I've never liked these command line package installers/managers because they always seem to have some problem without a clear answer. I guess it's the nature of the beast. In this case, you've modified the core _masthead.php. Don't do that. ? The intention is that an admin theme would provide its own _masthead.php file (or whatever you decide to name it). Actually I was thinking admin themes would replace all of the markup files. That's in part why they are all split out on their own. The updates added to AdminThemeUikit last week make it so that you no longer have to provide your own markup files if you don't want to, but for your case where you are changing method calls and include statements in those markup files, you'll no doubt want to have your own markup files. This gets into more overhead than I'd want to be involved for rendering the admin theme... at least for the core default one (AdminThemeUikit). I've even tried to actively avoid the traditional type of hooks here, so that the admin theme itself doesn't add its own overhead to the request. There's nothing faster than include() of a php file to render something, so that's the strategy AdminThemeUikit takes. Admin themes use a different kind of hooks for adding markup in parts of an admin theme, and they actually aren't really hooks at all, even though I still think of them as being a type of hook. You can call $adminTheme->addExtraMarkup($name, $value); to add extra markup to various parts of the admin theme. Any module or admin template code can do this any time during the request, up until the admin theme gets rendered (at the end of the request). The $value is the markup you want to add, and the $name is a region name where any one of the following are currently recognized: "head" - adds markup before </head> "masthead" - adds markup in the div#pw-mastheads "notices" - adds markup after the notices/notifications "content" - adds markup in div#pw-content-body "sidebar" - adds markup in #pw-sidebar, only if theme uses a sidebar "body" - adds markup before </body> "footer" - adds markup in footer#pw-footer This is the strategy that the admin themes use to support other modules in adding markup where necessary to the admin theme output. This is faster and simpler than using a traditional hook. More region names can be added easily if/when we need more. If developing your own admin theme, then you don't need hooks or the addExtraMarkup() function because you can already override anything in the AdminTheme you are extending, you can provide your markup files as needed, and add your own methods as needed. Admin themes should still support markup added with addExtraMarkup() though, but it's easy, just $adminTheme->renderExtraMarkup($name); at the appropriate spots in your admin theme template files. If there's anything I can add to make it easier for people to have a dashboard page, I'm happy to. But I don't currently think it should be built into the core. The core doesn't have anything worthwhile to communicate to admin users in a dashboard, so it would just be extraneous fluff (i.e. "numbers", "more numbers", and "numbers again"), like it seems to be in most systems. The kind of stuff that makes a simple system look complicated. Others may have something specific they want to communicate to their logged in users, and that's where I think it becomes worthwhile. If there's demand for it, I'd be more interested in hearing not about a dashboard, but about what one is wanting to communicate with it. Thank you for continuing to develop this. I agree there are benefits. This may be something we should keep talking about for the longer term. With the exception of WireMail, all the classes you mentioned are intended to be available for standalone use. Though it's been a long time since I've used any of PW's classes in that way. This I think is likely an easily attainable thing to support though. Most of the mentioned classes just extend the Wire class, making it the only dependency (and Wire doesn't require a DB connection). A DB connection would be needed for WireMail because it is a module type. Installed modules are known from the database modules table. A WireMail module also maintains its settings in the database. Now is is true that the base WireMail class can operate without a database, but WireMail is only useful because it is a module type. Take out the module aspect and WireMail is just an interface to PHP's mail(). The core datetime field is meant to store a single date/time, but that's it. I agree that sometimes a need arises for more than a single date/time. ProcessWire core is meant to focus on the basics, while supporting modules to accommodate a broader set of needs when they occur. I think this is a good example of a need that is nicely accommodated by a module that you've developed. Thanks for sharing the strategy you are using here. It's great to see the different solutions people are working with these last couple of weeks. From the screenshots I really like the approach you are using here. It looks powerful while easy to understand and client friendly. Yet also looks very PW familiar as well. Visually it might be the clearest I've seen, even relative to something like The Bard. The means of definition does also look simple, though I think for something that other developers would use, they might prefer that the front-end rendering be isolated from the back-end component. Something that makes it easier for you to provide pre-written components, while they provide the front-end markup. For instance, maybe the render() method delegates to a front-end template file somewhere in a subdirectory off /site/templates/fields/? And if there is not file, then maybe it provides a default output. The reason repeaters store their pages off in the admin structure is to solve these things. But it does come with its own challenges as well. Most likely I wouldn't be able to make any more commits to the core if I got run over by a train. I've always thought this was one of the reasons to use open source, ensuring that when someone smacks the tracks, the code doesn't. But it's not just about being open source, the code also has to be clean and well documented so that others can easily take it on board. That's one reason why I put so much effort into code quality and code documentation. My intention is that the code is always ready for others to understand and work with. As for commercial services/modules, it's the same risk inherent with any product or service you pay for. While not open source, the Pro modules do have the same code quality and documentation as the core, and are not obfuscated or encrypted. If it sets your mind at ease, I'm 46 years old (not 76), and am very healthy. I run and lift every day, eat lots of salads, don't eat red meat, and don't participate in any dangerous activities. Most likely I'll be here for at least another 46 years. But if I'm ever derailed then I know the project would still be in good hands. Seems like it might be simple to do. Can you expand on this? When/where would you use it?

+1 for a solid database migration mechanism. Deploying field/template updates to production involves a lot of manual copy/pasting. Having a built-in way of describing changes in database structure would make automated deployments and rollbacks possible.

Hi @ryan thanks for the great info about the future of PW from last week and thanks for the condensed list above. I agree with most of what's already been said, but want to add some points as I've been heavily working on several mentioned areas over the last year. IMPORTANT: Admin Theme As mentioned I've been working on a better admin experience for quite a long time. This is an example screenshot of RockSkinUikit (which I'm not using any more): My key goals have always been easy things: Make it easy to change ONE main color which does look good in most situations (because the secondary colors are gray) Make it easy to change the Logo Make it easy to add custom CSS/LESS -------- I am now using a custom Admin Theme module AdminThemeRock that does look similar to what I've built using RockSkinUikit: Again: Custom color, custom logo, that's it! -------------- Another one: Custom color, custom logo: ----------- Another one changing only the main color (page tree example): ------------- Learnings: If the core changes, my theme breaks!! That's a no-go. I've had to add several custom hacks to my theme that make it out of sync with the core. But important parts of the theme have not been hookable, so that was my only option meaning I have to pull all changes from the core into my admin theme module. I guess nobody else is as crazy as I am and that might be one major reason why we have not seen any other admin theme modules... My theme uses the old admin theme repo sources, because we do not have any source files in the core... https://github.com/ryancramerdesign/AdminThemeUikit/ PLEASE add the source files the core or in a separate repo that we can fork or help with PRs!! I've added you to my private repo on github so that you can see all the changes that where necessary for getting everything to work. For all others, here's an example of how my dirty core hacks look like: getNav() and getSearchform() are hookable methods that I added to my module. I've also built a frontend module that I'm using on my sites. There I use a simple but very effective technique that uses one single render() method to render several code blocks that I organize in files: // file structure foo |-- foo1.php '-- foo2.php bar |-- bar1.php '-- bar2.php // code echo $uk->render("foo/foo1"); echo $uk->render("bar/bar2"); This keeps the files organised and makes it very easy to do custom modifications before or after a file is rendered: $wire->addHookBefore("RockUikit::render(foo/foo1)", function ... ); $wire->addHookBefore("RockUikit::render(bar/bar2)", function ... ); Using a dom parser like https://github.com/paquettg/php-html-parser would even make it possible to modify/add/remove single html elements of the returned output! Of course having custom hooks would be more elegant and performant, but I wanted to mention this option nevertheless. Support for a Dashboard-Page That's another big thing for all my pages. I don't want to show the pagetree to logged in users unless they really want to see it! Take this simple example: Or this more beautiful one: The latter is taken from the Dashboard module which proves the big demand of the community for such a feature! I don't want to talk bad about this module here, I've shared my thoughts in the related thread with @d'Hinnisdaël and should maybe go for a beer with him when all this covid thing is over, but IMHO the module has two major drawbacks that would not be necessary! 1) It introduces a whole new concept to the PW admin that is already there. The PW admin is built upon inputfields and it would be very easy to build a dashboard (or to be more precise, the dashboard widgets) using these existing tools. (this is built using inputfields). 2) Making the admin show the dashboard instead of the pagetree feels hacky in several situations. We've discussed that here: One problem is, for example, that the breadcrumbs do not work as expected any more. Clicking on breadcrumb "bar" in " foo / bar / foobar " would take you to the dashboard and not to " foo / bar ". ############################################ Would be great: Migrations I think the core and all modules could benefit greatly from easy api migrations like I have built in my RockMigrations module. It's far from perfect, it's not very well documented, but it does some things right in my opinion and that's why I have it in all my installs and nowadays have it as requirement for almost all my modules that I build. Why? Because I want to have my fields under control of GIT Because I want to write an easy setup file that creates all fields/templates/pages that I add to this codeblock Because I want to push changes to my live server without exporting fields via mouseclicks, then updloading json files, then going through a migration click-marathon again, when I can simply do git pull & modules refresh Because I want to be able to create reusable components easily. I know that one can do all that using the standard PW API and creating a custom module, but take this example and see how easy and clear things get when using RockMigrations (or even better a solid core migrations API): I've recently added an example module that shows how I'm using RockMigrations now: https://github.com/BernhardBaumrock/RockMigrations/blob/master/examples/MigrationsExample.module.php ############################################ Brainstorming: ProcessWire without DB We all love ProcessWire and it's tools, but there's one drawback: The great API is only available if we have fully installed version of ProcessWire available. That has been a problem for me when I tried to work on a module that installs ProcessWire automatically (PW Kickstart and now working on RockShell). Examples of such classes that might be useful even without a DB connection could be: WireData WireFileTools WireRandom WireTextTools WireHttp Sanitizer I know that there are several cases where DB settings are absolutely necessary (for example page data or sanitzier settings), but there are other frameworks, that show, that such a concept can work and make a lot of sense: https://nette.org/ One might argue, that this might be going too far... But if we are talking about the future of PW, why not thinking of something like this: // copy files to root folder include("index.php"); $wire->install([ 'user' => 'demo', 'pw' => $wire->random->alphanumeric("8-12"), ... ]); Or take another example: https://processwire.com/api/ref/wire-mail/ There's no reason why we need a running PW instance with a DB connection for such a code example. Of course I know that it's technically required in many places in the core, but maybe these places could be identified and removed in the future?! Or maybe PW could support noSQL or something? ############################################ Would be great: A better Date/Time/Range-Field (dream: Support for recurring dates/ranges) I've started a discussion here and as you can see the post got a lot of attention: ProcessWires date field is nice, but it is a PAIN to work with date ranges, to build calender-like applications, to get the proper entries from the DB, etc... Why? Because the only option right now is to add TWO date fields to one template and there the problems begin... What if you want to make sure that one date is after the other? What if you want to show all events of one month? There's a HUGE potential for bugs like "foodate < $lastOfMonth" should have been "foodate <= $lastOfMonth" How to get the timestamp of $lastOfMonth properly? An API like https://carbon.nesbot.com/ would be great! What if events can have a range (like from 2021-01-10 to 2021-01-15), but can also be a single day event (2020-12-24). What if an event is on one day but has a start and end time (2020-12-14 from 18:00 to 22:00)? What about timezones? How to do the proper formatting? Showing a date like this "2020-12-24 18:00 to 2020-12-24 22:00" is a lot worse than "2020-12-24 18:00 - 22:00". This gets even more complicated when you want to show the days... What if you want/need to handle recurring events...? ############################################ PageBuilder I've taken several runs on that topic and finally (?) found a good solution during development of one large project last year. My approach was to make a new Fieldtype similar to Repeater and RepeaterMatrix, but with some big conceptual differences (it's more like Repeater than RepeaterMatrix): Every item is a single page in the tree and has a custom template Every repeater item can live anywhere in the pagetree Every item is defined in a single PHP file (using RockMigrations to make it reusable) This makes the setup very flexible on the one hand, makes it reusable across projects (simply copy the file and do a modules::refresh triggering the migrations) and makes it REALLY simple to use for the clients on the other hand: Setting up such a block is quite easy: class Headline extends \RockMatrix\Block { public function info() { return parent::info()->setArray([ 'icon' => 'header', 'title' => 'Überschrift', 'description' => 'Fügt eine Überschrift auf der Seite ein.', ]); } public function init() { $this->addHookAfter("Pages::saveReady", $this, "saveReady"); } // this method makes it easy to customize the item's edit-form // you can change labels, collapsed state, add notes or custom classes etc... public function buildForm($fs) { if($f = $fs->get('title')) { // dont show label for this inputfield $f->skipLabel = Inputfield::skipLabelMarkup; $f->wrapClass('rmx-pd5'); // add class to remove padding } } // the label of the repeater item public function getLabel() { return $this->title ?: $this->info()->title; } // migrations for this item public function migrate() { // the parent migrate creates the necessary template for this block parent::migrate(); // then we set the title field optional for this template $this->rm()->setFieldData("title", [ 'required' => 0, ], $this->getTpl()); } // code to use for rendering on the frontend public function render() { return "<h3 class='tm-font-marker uk-text-primary'>{$this->title}</h3>"; } // optional saveready hook public function saveReady(HookEvent $event) { $page = $event->arguments(0); if($page->template !== $this->getTpl()) return; if(!$page->id) { $page->title = "This is my initial headline"; } } } As you can see in the screenshot, I'm using CKEditor for editing fulltext. That's great, because I can remove all plugins that do usually need more education for clients (like inserting images) and build custom blocks solely for this purpose that every client can grasp a lot quicker and where I have a lot more control and freedom (since the block is a separate template). This means I've always had the freedom of custom image fields even before the image field supported them. Another example: A gallery block (headline + image field): I'm not sure about the scalability of this approach, but having all blocks as custom pages is a huge benefit in many ways. For example I could create a Matrix field having invoice items. Each item would be a page of type "invoiceitem" and then I could query all "invoiceitems" using RockFinder and build an average invoice NET or GROSS value of all invoices of 2020... Access control, page status, etc etc are still challenges though, of course. ####################### I hope that all makes sense and I'm willing to share any of my modules code if that helps. Or give you a demo/walkthrough via screenshare. One last question, as we are talking about the future of PW: One thing is what would happen to the core of PW if anything happend to you @ryan. But we could at least fork the core and do... whatever then would be necessary to keep all our businesses running and all our clients happy. But what about all the Pro modules? We could not get a copy of them and work on ProCache for example on our own (as a community). Did you think about that szenario and have a reassuring anwer for us? ? Of course, I wish you a long life and many happy years of developing PW - it's absolutely impressive what you have built here ?

Currently version 4.7.0 of Font Awesom is used in ProcessWire for icons for templates and fields. Since its release, both version 5 have come – and version 6 is in the making. I would like to see a newer version in the future in ProcessWire, @ryan 4.7.0 (in ProcessWire) has around 675 icons as far as I can tell. The current Font Awesome version has around 1600 icons. When version 6 comes, theres around 2200 icons I have read.

ProcessWire 3.0.157 on the development branch continues the trend of core refactoring that’s been happening quite a bit in 2020. Rather than doing a rewrite every few years (like some CMS projects) we instead refactor parts as we go, constantly improving and optimizing the core. This works because the core design/architecture is right where it needs to be, even 10 years in. But there’s always still bits of legacy code, and code that can be improved. So in the context of ProcessWire, refactoring means incrementally rewriting code on the inside, without changing its behavior on the outside (other than making it faster and/or more secure). This has been happening regularly over the last 10 years, and will likewise continue happening over the next 10 years and likely beyond. This week the code behind ProcessWire’s core Database and PageFinder classes got a major refactoring. This is some of the most used code in PW, as it handles everything involved in taking a selector and converting it to a database query. But it’s always been a little bit of a pain point for me because it had to build queries in a way that I thought wasn’t ideal, in order to make it possible for lots of different modular parts (mostly Fieldtype modules) to contribute to the query and for PageFinder to put it all together. It was fast and secure, but still one of those parts that felt like a little too much duct tape to me. But considering how crucial the code is, I’ve always been reluctant to make major changes, since it all worked just fine. Spending lots of years thinking about it (on and off), a desire to work out any pain points, and having better tools available (like Phpstorm and Tracy) made it possible to finally massage out this pain point. Some work still remains to be done, but it’s mostly there and I’m feeling good about it. Stuff like this is key for the maintenance and longevity of the core, and involved a lot of time and effort, but makes very little difference to users, even if it makes a lot of difference to me in maintaining the core. It would make a boring blog post for sure—lots of work and changes, but no new toys to show for it. Nevertheless, it has that feeling of a good house cleaning, even if you can't see it from the outside. The scope of changes here means that there may actually be new bugs to work out, so to be on the safe side, consider 3.0.157 to be a little more “beta” than the dev branches usually are. Though I’m running it here on processwire.com and it’s working well. Beyond the fairly major updates to the Database classes, there are also a few new Sanitizer convenience methods that are primarily variations on existing ones, but useful ones for sure. Thanks for reading and have a great weekend!