PW 3.0.267 – Core updates

[ryan]

This week we've ProcessWire 3.0.267 on the dev branch, here are some highlights (commits): 

The entire WireTests module has been moved into the core. All of the tests now live alongside the classes that they test. The WireTests module is used from the command line. Once installed, you can type "php index.php test" for a list of WireTest commands. If you already have the non-core WireTests module installed, I recommend uninstalling it and installing the core version. 

More than a dozen new WireTests and API.md documentation files have been added this week (this is where the biggest additions of the week are). 

Many improvements to the CLI "docs" command, especially with regard to chapter retrieval. 

New faster $modules->refresh() method from @matjazp

New HOWTO-API.md documentation that outlines how to write API.md files for your own modules.

New getFresh() and getRaw() methods added to $fields and $templates. These do the same as their $pages method equivalents (getFresh and getRaw), except for fields and templates. This was requested by an agent in AgentTools.

This week we also have a new guest blog post! Page's best kept secret: the meta() method

Thanks for reading and have a great weekend!

[szabesz]

@ryan Upgrading from 3.0.266 to 3.0.267 resulted in `Class "ProcessWire\InputfieldSelectMultiple" not found`, see the screenshot:

[ryan]

@szabesz The location of the module changed in this version, so you may need to do a Modules > Refresh for it to see the new location. 

[szabesz]

Thanks Ryan for the swift reply! The issue is that it was a 500 error, so I could no longer access the admin (I reverted to the last site backup). Is there a way to do a module refresh in any other way? This is the very first time a ProcessWire upgrade has ever brought down a site for me, so I am clueless.

[ryan]

@szabesz As far as I know, there isn't any reason why a moved InputfieldSelectMultiple should cause an error on any URLs that don't actually use that module. So if you can go to a URL like the login page or modules page or anything other than a page editor page that's using SelectMultiple or AsmSelect, that should work. But If you are still getting an error, even if a page isn't using that module, then there may be some other issue at play. You can try to refresh the modules manually from the terminal by typing "php index.php modules refresh" in your web root.  Another option is to temporarily copy the wire/modules/Inputfield/InputfieldSelect/InputfieldSelectMultiple.module file into wire/modules/Inputfield/ (its previous location), then do a Modules > Refresh. It will tell you that it found two copies of the same module, click the link it gives you to choose which one you want. Select the one in wire/modules/Inputfield/InputfieldSelect/, and save. 

[szabesz]

Thanks again!

27 minutes ago, ryan said:

if you can go to a URL like the login page or modules page or anything other than a page editor page that's using SelectMultiple or AsmSelect, that should work

I think I tried to access other admin pages as well, but the issue persisted. But yeah, if the module does not need to be loaded, then sure I should be able to access the admin's module refresh page, too.

Anyway, I have just tried the upgrade one more time and after the successful update page in the admin I tried to access the module refresh page (/module/?reset=1) by using the admin menu, and I got the error again, however, simply refreshing the page made the error go away and I was notified: "SystemUpdater: Detected core version change 3.0.266 → 3.0.267"

Could there be a way during the upgrade process when using the Upgrades module to automatically have the modules refresh, so that issues like this can be prevented in the firs place, perhaps?

Thanks for all the other troubleshooting tips too, I'll save them for later.

[szabesz]

2 minutes ago, szabesz said:

But yeah, if the module does not need to be loaded, then sure I should be able to access the admin's module refresh page, too.

One more thing I forgot to add, is that for the first time "failed" upgrade, even the frontend of the site did not load (500 internal server...) and I guess an admin module should not load on the frontend, should it?

[ryan]

@szabesz My best guess is that there must be some other module that is loading AsmSelect, and doing so on every page load. That would explain the error. I've upgraded a few installations and haven't seen this error, but if it starts appearing for more people then we'd have to identify what's in common among those installs. It's possibly a load order issue, which might be solved by asmSelect moving its getModuleInfo() array to a separate InputfieldAsmSelect.module.info file. 

ProcessWire should already do a modules refresh on every version update, but it looks like this error popped up before it could do the refresh.

[szabesz]

@ryan Thanks Ryan for the broader picture. Unfortunately, I do not have time to dig in further, but my issue is definitely solved, so thanks once more!

[jploch]

@ryan Great update! Since the blog post is about $page->meta(), I wanted to share my pull request from 2022 that adds meta support to the pages export/import module 😊:

It adds support for exporting/importing $page->meta() data via core ProcessPagesExportImport Module. Tested with multiple pages and works well so far.

I made changes to the PagesExportImport Module, but it might be better to implement this in the core PagesExportImport Class. That would make the feature available to the API and other modules as well. But I am not sure how to do that, because to import the meta data, the pages must be created first, so the code might only work in the module, after the pages are created.

It would be a nice addition in general, and especially for PageGrid, since it uses meta data for layout and settings. Right now meta data is no being exported/imported at all. The fix should not be too complicated. Maybe you can ask your agent about this 😊