Articles problem on upgrade to 3.0.4

Error log is filling up in MODX3.0.4 (phph8.1) with the message below. I’ve upgraded from MODX2.8.6. On upgrading all Articles had disappeared (front end and back end) and the only way I could get them back was to change each class_key to Articles\Model\Articles. Everything seems to be working ok but I’m worried that these errors are piling up quickly…

[2024-02-01 19:24:43] (ERROR @ /var/www/vhosts/sitedotcodotuk/httpdocs/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php : 473) Path specified for package articles is not a valid or accessible directory: /var/www/vhosts/sitedotcodot/httpdocs/core/components/articles/model/

What version of Articles are you using? Version 2.0.0-beta for MODX 3?

Yes Harry that’s correct. I followed the specific instructions for upgrading Articles to a newer version in 2.8 and then then Version 2 in MODX 3. The Articles upgrade hung a few times and I was getting an error…

[2024-02-01 12:07:53] (ERROR @ /var/www/vhosts/mysitedotcodotukk/httpdocs/core/components/articles/model/articles/articlescontainer.class.php : 22) PHP warning: require_once(/var/www/vhosts/mysitedotcodotuk/httpdocs/core/model/modx/modprocessor.class.php): Failed to open stream: No such file or directory

…so I actually uploaded the file modprocessor.class.php to that location and it worked. I’m not sure if that was right or wrong but it is working.

I don’t know. Something seems very wrong with your Articles installation.

The path core/components/articles/model/ shouldn’t exist anymore with version 2.0.0-beta. (In MODX 3 extras (including the current version of the Articles extra), the .../model folder is usually moved to .../src/Model.

Also, in MODX 3, the folder core/model/modx/ should only contain the file modx.class.php. The rest of the MODX classes are now in core/src/Revolution/.

Yep I agree with you. I’m wondering whether to delete the modprocessor.class.php file I uploaded now everything is working. The reason I changed the class_key to Articles/Model/Articles was that when no Articles showed up in the back end or front end, I created a new article and this did show up. I then checked the database and noticed the class_key of the new article was Articles/Model/Articles. I changed the existing articles to that class_key and they showed up fine.

Any clues here I wonder… Uninstalling Articles - #2 by halftrainedharry

…maybe something from the old version of articles didn’t get deleted?

This is really bugging me. In core/cache/namespaces/extension-packages.cache.php I have the following…

  0 => 
  array (
    'id' => 2,
    'namespace' => 'articles',
    'name' => 'articles',
    'path' => '/var/www/vhosts/sitedotcodotuk/httpdocs/core/components/articles/model/',
    'table_prefix' => '',
    'service_class' => '',
    'service_name' => '',
    'created_at' => '2016-02-16 10:27:27',
    'updated_at' => NULL,
    'namespace_path' => '{core_path}components/articles/',

in Namespaces the following paths are set, so where is that coming from?
Core path

Assets path

There exists (sometimes) a system setting extension_packages that can be used to load packages on every request.

In MODX 3 this is usually not used anymore, as the package can be added with a bootstrap.php file.

So if the system setting extension_packages contains settings for “Articles”, remove that part from the setting.

It doesn’t contain any reference to Articles - just gallery and Guzzle7

There is also a database table modx_extension_packages, but I’ve never seen it being used. Is this table empty?

When you manually clear the whole core/cache folder, does the file core/cache/namespaces/extension-packages.cache.php reappear?

That table contains articles, gallery and collections. It has the same creation date as seen in the extension-packages.cache.php. Am I safe to delete Articles from there? Yes that cache does get recreated clearing core/cache.

Interesting. This table is always empty in all my installations.

Probably. Maybe save/export the table content first to be on the safe side.

We’re getting somewhere thank you Harry. Those error messages have stopped piling up and I’m now only getting the following errors when an article is saved…

[2024-02-05 17:41:19] (ERROR @ /var/www/vhosts/mysitedotcodotuk/httpdocs/core/components/articles/controllers/container/update.class.php : 35) PHP warning: Undefined variable $settings
[2024-02-05 17:41:20] (ERROR @ /var/www/vhosts/mysitedotcodotuk/httpdocs/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php : 667) Could not load class: modAction from mysql.modaction
[2024-02-05 17:41:20] (ERROR @ /var/www/vhosts/mysitedotcodotuk/httpdocs/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php : 787) modAction::load() is not a valid static method.
[2024-02-05 17:41:26] (ERROR @ /var/www/vhosts/mysitedotcodotuk/httpdocs/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php : 667) Could not load class: modAction from mysql.modaction
[2024-02-05 17:41:26] (ERROR @ /var/www/vhosts/mysitedotcodotuk/httpdocs/core/vendor/xpdo/xpdo/src/xPDO/xPDO.php : 787) modAction::load() is not a valid static method.

…that’s a vast improvement on getting loads of errors anytime the blog was viewed in the frontend.

The warning occurs on this line

The variable $settings is used here, but only defined on line 70. You could probably move line 70 up (before line 35) to fix the warning.

The class modAction was removed in MODX 3. But somehow it’s still used in this processor. Not sure why.

Thank you for your help Harry - it’s much appreciated. I think ultimately I need to switch this all from Articles to Collections as although there’s some great work been done to bring Articles up to date, it seems so deeply embedded once it’s installed, it’s likely to have more problems going forward.