Invalid module name: “.Modules.info” after update from 3.0.210 to 3.0.227

[teppokoivula]

Short description of the issue

After updating a site from 3.0.210 to 3.0.227 I started seeing this issue. It remained at the top of the modules screen.

Tried clearing caches, logging out and in again, etc. but that didn't seem to make any difference. Only thing that seems to have helped was removing all .Module% rows directly from the modules table.

I noticed that there was an earlier issue where this error was displaying apparently due to upgrading and then downgrading the site. In this case that was not the case — the site was upgraded from 3.0.210 to 3.0.227.

This site is running on load balanced environment, and each deploy takes a bit of time. It's possible that some requests hit the site while some servers were still running older version of ProcessWire. Is this an issue?

Expected behavior

Not seeing errors, I guess :)

Or, in case simply having those rows in the database is an issue and it can happen due to issues during update (such as the ones mentioned here) or due to the site being upgraded/downgraded, perhaps current versions of ProcessWire could identify this situation and fix it automatically, removing those rows?

At least in my case I couldn't find any way to fix the issue without going directly in the database.

Actual behavior

Errors show up and stick around, apparently indefinitely.

Setup/Environment

• ProcessWire version: 3.0.227

[BernhardBaumrock]

This site is running on load balanced environment, and each deploy takes a bit of time. It's possible that some requests hit the site while some servers were still running older version of ProcessWire. Is this an issue?

Would you mind to post a tutorial about how to build such a setup in the tutorials board? That would be very interesting :)

[adrianbj]

FYI - I've also been seeing this.

[teppokoivula]

Would you mind to post a tutorial about how to build such a setup in the tutorials board?

To be honest it's got relatively little to do with ProcessWire. If you take a look at any tutorial that covers AWS services (EC2, RDS, EFS, ELB) that's all applicable here. Main caveat is the way ProcessWire uses filesystem for various things from cache to asset storage; it's not a great thing for cloud hosting, but nowadays EFS is pretty fast, so it's not a big issue either.

For deployments there are various general purpose tools and strategies, so again not much ProcessWire specificity there.

I'll consider writing something about it, but I'm not sure how deep in the specifics I can go. Also my experience is limited to AWS, and pretty limited in that context as well :)

[BernhardBaumrock]

@teppokoivula anything would be helpful for me - especially when put into context of ProcessWire. New things are always easier to understand or learn when you build upon things that you already know. Thx in advance! :)

[ryancramerdesign]

@teppokoivula .Modules.info actually is valid in current versions of ProcessWire and should be present in the modules table, as it's where all the module info is stored. I thought 3.0.227 would be using it, but don't remember for sure. Anyway, you should only see that error message in a version of ProcessWire that doesn't recognize it. So for instance, if you downgraded from PW 3.0.229 to 3.0.210, then I'd expect to see that error.

This site is running on load balanced environment, and each deploy takes a bit of time. It's possible that some requests hit the site while some servers were still running older version of ProcessWire. Is this an issue?

That could be it. It shouldn't be a fatal issue though. The error should have disappeared on its own once all the nodes upgraded to the newer version. Is it possible that some nodes might still be running the older version?

...perhaps current versions of ProcessWire could identify this situation and fix it automatically, removing those rows?

This wouldn't be possible because current versions of PW actually require those rows. If they don't exist, it creates them.

[adrianbj]

@ryancramerdesign - i am running the latest dev version of the core and every time I do a modules > refresh, I see these errors. I am only seeing it on my local dev setup though (MacOS).

ProcessWire: 3.0.234
PHP: 8.3.0
Webserver: Apache/2.4.58 (Unix)
MySQL Server: 8.2.0
MySQL Client: mysqlnd 8.3.0

[ryancramerdesign]

@adrianbj That's strange, as those entries are excluded by the Modules class. There must be some situation where they get through. ProcessModule gets them by iterating $modules. If you do it on your own, do you see those entries?

foreach($modules as $name => $module) {
    echo "$name<br>";
}

[adrianbj]

They don't appear with that code. In case it helps, I added a bd() call on $modulesArray in ProcessModule.module and got this.

[ryancramerdesign]

@adrianbj Interesting about that array(6), that's the one I'm looking for. Where'd you put that bd() call in ProcessModule.module?

[adrianbj]

Where'd you put that bd() call in ProcessModule.module?

You can see it at the button of the dump - line 840 so it is getting the results of every time the call to renderListTable() is made.

[adrianbj]

Digging deeper, it's the call that uses $missingArray that contains these.

[adrianbj]

Should the the flags for these be 64 instead of 8256? Or is WHERE flags & :flagsNoFile in findMissingModules() not working as expected?

[ryancramerdesign]

@adrianbj The flags should be 8192 for those rows, and so that flagsNoFile is definitely the reason they are showing up in there. I'm guessing that maybe this happens if a downgrade occurs followed by an upgrade, as the older version would assign the flagsNoFile since it doesn't know what those rows are for and won't find a file for those rows. This would explain Teppo's case too, as temporarily some nodes were on the newer version while some weren't, so the flags would have been added. The best bet is for the findMissingModules() method to just ignore any module names starting with a period, which is what it should have been doing already. I'll add this. I don't think I'd have found this without your help, thanks!

[adrianbj]

The flags should be 8192 for those rows

I was just checking other PW installs and was about to report that is what they were :)

I don't think I'd have found this without your help, thanks!

Glad to help!