Jump to content
ryan

PW 3.0.157 – Core updates

Recommended Posts

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!

  • Like 34
  • Thanks 6

Share this post


Link to post
Share on other sites

Love this Ryan. Are you about a couple of weeks away from finishing? You noted there needs a little work to be done.

  • Like 1

Share this post


Link to post
Share on other sites

Great job!

With the time you start appreciating such things as robust and maintainable core as much if not more than some shiny new features) And doing it little by little is surely better than a death by rewrite) Way to go, @ryan! And I'm sure you'll fix a lot of bugs by the way in addition to make a few new ones)

  • Like 4

Share this post


Link to post
Share on other sites

@HMCB Not a lot left to be done for this particular update. Mostly just details as I come across them. For instance, this morning I noticed that FieldtypeMulti needs some of the same updates I applied to Fieldtype, but nothing that's going to change the way it works or how it behaves. So while not particularly urgent, I just want to cover all the related updates while still fresh on the mind. 

  • Like 1

Share this post


Link to post
Share on other sites

@ryan sounds good. Have a great weekend and thanks for the continued improvements.

Share this post


Link to post
Share on other sites

@ryan

In this version if you try to access an unpublished page that is selected in a page reference field like this:

$page->page_ref_field;

It returns false. In 3.0.153 it returns the (unpublished) page object.

I don't know if this is expected behavior but it will break some things in my site.

  • Like 1

Share this post


Link to post
Share on other sites

@ryan Thank you for your insight, it was an interesting read to learn more about your current refactoring efforts.

I am wondering if it is the right time for you to also start working on the Javascript API perhaps? I don't remember since when it is on the roadmap, but in this post from 2017 you wrote:

"...so I'm going to continue to keep this in our roadmap."

  • Like 3

Share this post


Link to post
Share on other sites
17 hours ago, szabesz said:

I am wondering if it is the right time for you to also start working on the Javascript API perhaps?

Would be interesting to hear about your use case where you'd need such an API 🙂 

  • Like 1

Share this post


Link to post
Share on other sites
2 hours ago, bernhard said:

Would be interesting to hear about your use case where you'd need such an API 🙂 

Alpine.js & Vue.js & Tabulator but it would also be a use case for any other JSON powered solution out there, of course.

  • Like 3

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...