Articles problem on upgrade to 3.0.4

chrisandy · February 1, 2024, 7:57pm

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/

halftrainedharry · February 1, 2024, 8:08pm

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

chrisandy · February 2, 2024, 9:16am

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.

halftrainedharry · February 2, 2024, 9:59am

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/.

chrisandy · February 2, 2024, 10:33am

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.

chrisandy · February 2, 2024, 11:18am

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

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

chrisandy · February 5, 2024, 2:39pm

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
{core_path}components/articles/

Assets path
{assets_path}components/articles/

halftrainedharry · February 5, 2024, 2:47pm

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.

chrisandy · February 5, 2024, 3:00pm

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

halftrainedharry · February 5, 2024, 3:12pm

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?

chrisandy · February 5, 2024, 3:20pm

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.

halftrainedharry · February 5, 2024, 4:23pm

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

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

chrisandy · February 5, 2024, 5:48pm

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.

halftrainedharry · February 5, 2024, 7:59pm

The warning occurs on this line

github.com

modxcms/Articles/blob/05386eab390a23f4c82640d4d7013744e8aa28d2/core/components/articles/controllers/container/update.class.php#L35


      
          /**
           * @package articles
           * @var modX $modx
           */
          class ArticlesContainerUpdateManagerController extends ResourceUpdateManagerController {
              /** @var ArticlesContainer $resource */
              public $resource;
              /** @var boolean $commentsEnabled */
              public $commentsEnabled = false;
              public function loadCustomCssJs() {
                  if ($this->modx->getOption('commentsEnabled',$settings,false)) {
                      $quipCorePath = $this->modx->getOption('quip.core_path',null,$this->modx->getOption('core_path',null,MODX_CORE_PATH).'components/quip/');
                      if ($this->modx->addPackage('quip',$quipCorePath.'model/')) {
                          $this->commentsEnabled = true;
                      }
                  }
                  $managerUrl = $this->context->getOption('manager_url', MODX_MANAGER_URL, $this->modx->_userConfig);
                  $articlesAssetsUrl = $this->modx->getOption('articles.assets_url',null,$this->modx->getOption('assets_url',null,MODX_ASSETS_URL).'components/articles/');
                  $quipAssetsUrl = $this->modx->getOption('quip.assets_url',null,$this->modx->getOption('assets_url',null,MODX_ASSETS_URL).'components/quip/');
                  $connectorUrl = $articlesAssetsUrl.'connector.php';
                  $articlesJsUrl = $articlesAssetsUrl.'js/';

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.

github.com

modxcms/Articles/blob/05386eab390a23f4c82640d4d7013744e8aa28d2/core/components/articles/src/Processors/Article/GetList.php#L37


      
          public $editAction;
          /** @var modTemplateVar $tvTags */
          public $tvTags;
          /** @var ArticlesContainer $container */
          public $container;
          /** @var boolean $commentsEnabled */
          public $commentsEnabled = false;
          
          public function initialize() {
          
              // @todo: we need an alternative to modAction as it no longer exists!
          
              $action = $this->modx->getObject('modAction', [
                  'namespace' => 'core',
                  'controller' => 'resource/update',
              ]);
              if ($action) {
                  $this->editAction = $action->get('id');
              }
              else {
                  $this->editAction = 'resource/update';

chrisandy · February 6, 2024, 8:52am

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.

scorchsoft · July 4, 2024, 12:09pm

I had the same problem where I upgraded from MODX 2.8.x to MODX 3, and articles disappeared from he resources list. All resources were gone there initially until I upgraded Articles too, but even after upgrading articles, the articles container had gone and blogs vanished from the website.

I was able to fix it by upgrading Articles and then editing the class_key column in modx_site_content for any articles or article containers.

UPDATE `modx_site_content`
SET `class_key` = 'Articles\Model\ArticlesContainer'
WHERE `class_key` = 'Articles';

UPDATE `modx_site_content`
SET `class_key` = 'Articles\Model\Article'
WHERE `class_key` = 'Article';

So to fix:

Update modx
Update Articles
change the context_key in values for article content
refresh cache