PW 3.0.219 – Core updates

[ryan]

ProcessWire 3.0.219 on the dev branch focuses primarily on a major overhaul to the core $modules system. The Modules class had grown into more than 5000 lines of code — all related to modules, but with lots of different areas of focus within that. It had become a little bit messy, fragile and hard to maintain at that size. I've had @todo notes in the class to "clean it up" for quite awhile, but this week I finally got to it. 

The approach is similar to that of our $pages API (Pages class), which is split into separate classes for page finding, loading, editing, caching, etc. The Modules class has been split into several much more focused classes for module information, installers, loaders, files, flags, duplicates, and configurations. This leaves the main Modules class as the gatekeeper, making it less fragile and easier to maintain. 

If this overhaul was perfect, you shouldn't notice any difference, and the public $modules API remains as before. But with such significant overhaul that took a full week to complete, there's also an increased potential for temporary errors, so please let me know if you encounter any. Thanks for reading and have a great weekend!

[Ivan Gretsky]

Super! Need to keep everything in order. A Higher Order of Perfection, nothing less)

 

[ryan]

If you upgrade to 3.0.219, grab the latest commits, as the commit labeled "Bump version to 3.0.219" still had a couple of issues that I ran across since then and have fixed. (The issue may have originated in 3.0.218 or 3.0.217 actually). It was primarily "class not found" errors, and I didn't notice at first because the errors didn't appear when doing minor version upgrades and instead would appear when upgrading older versions to 3.0.219. 

[wbmnfktr]

Just dropped the latest/3.0.219 into a local dev instance and was greeted with this:

Besides my gastro modules nothing makes sense here (for me) and I can't find the source of this issue.
Unfortunatelly moving back to another version of ProcessWire didn't solve the issue. I had to import an older version of the database as well.

 

[zoeck]

8 hours ago, wbmnfktr said:

Just dropped the latest/3.0.219 into a local dev instance and was greeted with this:

I had the same problem with 3.0.218. I had to delete the module ".Modules" in the modules table in the database. After that, the error was gone.
Thought this was only a local problem ? 

[ryan]

@wbmnfktr ProcessWire 3.0.218 moved its cache storage from $cache to the modules table, so those module names you see there are actually the cache names from 3.0.218+. This error would be expected if downgrading from 3.0.218 or 3.0.219 to 3.0.217 or prior, since prior versions don't know about those caches in the modules table. It's not a fatal error and it's okay to delete them from the modules table if you downgrade to a previous version. (or it's okay to ignore them). But this error wouldn't be expected if upgrading to 3.0.219. Your message suggests this is what you saw after UPgrading, but this is what I'd expect to see if DOWNgrading, so just wanted to confirm?

[ryan]

Quote

 

I had the same problem with 3.0.218. I had to delete the module ".Modules" in the modules table in the database. After that, the error was gone.

 

@zoeck Just ".Modules" and not ".Modules.info"  ? in 3.0.218+ there should be rows with these names:

.Modules.info
.ModulesVerbose.info
.ModulesUninstalled.info
.ModulesVersions.info
.Modules.site/modules/
.Modules.wire/modules/

[zoeck]

26 minutes ago, ryan said:

@zoeck Just ".Modules" and not ".Modules.info"  ? in 3.0.218+ there should be rows with these names:

.Modules.info
.ModulesVerbose.info
.ModulesUninstalled.info
.ModulesVersions.info
.Modules.site/modules/
.Modules.wire/modules/

Found 1 module(s) missing file: .Modules.wire/modules/ => /site/modules/.Modules.wire/modules//.Modules.wire/modules/.module

And I can already see my problem, I downgraded to 3.0.217 due to another bug.
After that, the problem occurred, just as you wrote, because .217 does not need this entry.

In the meantime, I have updated to .219, where the entry was created again. Without error message.

[wbmnfktr]

3 hours ago, ryan said:

Your message suggests this is what you saw after UPgrading, but this is what I'd expect to see if DOWNgrading, so just wanted to confirm?

@ryan That's correct. Those messages appeared right after I upgraded to 3.0.219, coming from 3.0.217. At least that was what I thought yesterday.

I just gave it another try starting with a fresh database backup from production, and everything went perfectly fine without any issues going from 3.0.217 to 3.0.219.

I really can't remember I ever tried the 3.0.218 in that setup and moved back/down to the 3.0.217 again. That wouldn't make any sense at all.
I made a big downgrade to 3.0.165 a while back for testing purposes but that shouldn't result in issues here.

This is how it looked this time:

 

I will keep an eye on this as I want to upgrade some more local setups to the latest dev version.
And those definitely never ever saw a 3.0.2xx version before.

[gornycreative]

Had an unusual experience trying to get TextformatterTypographer to install. Looks like it is just essentially a wrapper around a composer library install but for some reason the InstallModule process choked on it with v 3.0.220

If this is a plugin problem I can address it there.

The plugin needed to declare the getModuleInfo() function as a static function. Once I added the static attribute the installation went as normal.

  public static function getModuleInfo()
  {
    return json_decode(file_get_contents(__DIR__ . '/TextformatterTypographer.info.json'), true);
  }

I've added the fix request in the plugin thread. I'll leave this here in case there are other older modules that have similar issues.

[hollyvalero]

Edited to say that I found the reference, deleted and it worked... but if it's worth anything, problem showed up with pw master 3.0.227 and dev 3.0.228 -- it may have been old references...

 

 

Edited September 27, 2023 by hollyvalero
figured it out!