[RESOLVED] 2.2.9 Package Manager Bizarre Problem

First what happened, as explained by the MODX output, then some background and finally my investigations so far:

/*
* MODX Console Output
*
* @date 2013-09-22 01:23:30
*/
Attempting to install package with signature: gallery-1.5.2-pl

Package found...now preparing to install.

MODX could not download the file. You must enable allow_url_fopen, cURL or fsockopen to use remote transport packaging.

Could not transfer package gallery-1.5.2-pl.transport.zip to /home/content/53/6837553/html/www/live.teachbridge.com/core/packages/.

Could not install package with signature: gallery-1.5.2-pl


/* EOF */
___________________________________________________

THE PROBLEM
The problem (see above output) is NOT allow_url_fopen (not allowed), cURL (definitely works) or fsockopen (I have no idea, but probably works). The problem is "... to /home/content/53/6837553/html/www/live.teachbridge.com/core/packages/."

BACKGROUND

Hosting Provider: GoDaddy.com (not my choice!) Type: Shared Hosting, Linux with Apache
"Primary Domain": ebooksbridge.com
Hosting Account "Root" Directory: /home/content/53/6837553/
Web-root for ebooksbridge.com: ~/html/

For technical reasons, to avoid accidents and for clarity, the "web-root" directories are all located in: ~/html/www/
(except, of courese, for the primary domain, which however, has all its files in a directory in ~/html/www/).

MODX is used for the web-site of the domain: teachbridge.com (and a couple of others that are "parked" on its web-root).

Despite my dislike of the naming convention, a number of the web-root directories have names like "live.teachbridge.com" (I don't like dots in directory names and the directory names look too much like (sub-)domain names).

The "Live" version of the teachbridge.com domain has the above example as its web-root directory: ~/html/www/live.teachbridge.com/

Sub-domains (which I'm beginning to think are the root cause of the problem) are used for testing (again, my preference is to spend the $10 or less and use fully-fledged domains).

The "Test Environment", used by content developers and web-site developers, uses the sub-domain: test.teachbridge.com
and has a web-root directory: ~/html/www/test.teachbridge.com/

The "Testbed Environment", used by me to test MODX upgrades and packages, uses the sub-domain: testbed.teachbridge.com
and has a web-root directory: ~/html/www/teachbridge_testbed/

THE PROBLEM EXPLAINED

Package installations and updates work fine in the "live environment" which is MODX 2.0.8; package updates appeared to work fine in the "testbed environment" and the "test environment" prior to upgrading to MODX 2.2.9. After the upgrade (done first on the "testbed environment" to work out the quirks), both fail with the same error (except I only tested upgrading an existing package in the "test environment").

INVESTIGATION

All done using the "testbed environment" (prior to attempting to install/update packages, the browser cache was cleared, MODX cache was cleared and .../core/cache/ was emptied):

1. I immediately suspected an error in a config file; however, they all appear fine.
2. Next, a MODX system setting. Browsing them all (both via the MODX manager and by looking at the database using phpAdmin) found no references to "live.teachbridge.com".
3. Then I did a recursive grep starting in the ~/html/www/teachbridge_testbed/ directory (the web-root) for "live". It came up with some extraneous hits, but the following contained references to the web-root directory:

./core/packages/getresources-1.5.1-pl/preserved.php
./core/packages/archivist-1.2.4-pl/preserved.php
./core/packages/getresources-1.6.0-pl/preserved.php
./core/packages/simplesearch-1.6.1-pl/preserved.php
./core/packages/wayfinder-2.3.3-pl/preserved.php

core/cache/logs/error.log

Since there was no Gallery refrence above, the "preserved.php" files appear to be a red herring (but I corrected them to reflect the "testbed environment" anyway).

4. I double-checked, via GoDaddy's hosting control panel, that the two sub-domains were pointed at the appropriate web-root directories (they are).

5. I revisited the MODX database: The config file is pointing at the correct MODX database (NOT the one for the live site!). I browsed what looked like tables the Package Manager might use — saw no references to "live.teach...".

HELP!

I will go back over everything and do some triple-checking. I'll download the SQL file backup of the database and search it, in its entirety for references to "live.teach...", but don't hold your breath, I have a feeling it will be clean.

So, where is that reference coming from? Is the Package Manager stripping off the sub-domain part of the URL and then doing something that gets it pointed at the Live site's web-root?
__________________
John ("JRG") [ed. note: jrg last edited this post 12 years ago.]

I forgot to mention something important: I DID check all the .htaccess files in the path from the hosting account's root directory upto and including the web-root directory for the "testbed environment".

Try removing the package entirely, use the remove in the manager and do it over and over till it's gone. If it won't disappear, go into core/packages and remove the transport.zip and the package itself (if it's still there).

Clear the core/cache files, then back to package management. Re-download the package, install.

Likely all the packages will need this process done if you want to upgrade or install them. The issue seems to creep up with sites that are on temporary urls or when sites get moved. The package manager is looking for the wrong path, and it uses a full server path instead of the install path like other parts of the manager. I still haven't figured out what sets this path and why it doesn't get updated by the config.

RESOLVED

Downloading the backup of the MODX database and searching it found that one has to modify the table "modx_workspaces" when moving or duplicating a site (as well as the config files). That's a bit strange as I would have thought "setup" would make any database updates required based on the config file (/core/config/config.inc.php or one of the simpler config files — why does MODX have those other config files anyway?).

Now I do have another question that I need to resolve: The database search showed that the table modx_site_content contains the path as well. Why would that happen? Surely it should only contain file names and the path prefix should be picked up from the config files?

For all intents and purposes, {core_path} is the correct setting for the workspaces table and it should not be hard coded to any specific path. Yes, modifying the table can solve the issue, but it's a bandaid rather than a solution. This path should resolve to the paths set in the config files, regardless of where the installation is.

I can verify this, once when migrating a site database to a new server the workspace table had a hardcoded path in it rather than {core_path}. When I noticed somthing was wrong was when package management wouldn't work. [ed. note: absent42 last edited this post 13 years ago.]

Quote from: frogabog at Sep 22, 2013, 04:44 PM

For all intents and purposes, {core_path} is the correct setting for the workspaces table and it should not be hard coded to any specific path. Yes, modifying the table can solve the issue, but it's a bandaid rather than a solution. This path should resolve to the paths set in the config files, regardless of where the installation is.

Are you saying that the value that should be in the table is "{core_path}" (without the double-quotes, of course)?

If so, I wonder when it got hard-coded — I know I've never changed it (which is why I had so much trouble finding the root cause of this problem). I'll test changing it to "{core_path}" and see what happens.

Thanks for the information, I appreciate your help.

OK. I answered my own question: The workspaces table entry should have the value "{core_path}" as kindly pointed out by Frogabog and Dan. Thank you again. I won't bother pursuing who changed it in our installation.

By any chance, was the original installation done by a "one-click" install system like Softilicious via cPanel?

Quote from: absent42 at Sep 22, 2013, 05:20 PM

By any chance, was the original installation done by a "one-click" install system like Softilicious via cPanel?

Quite possibly, I didn't do it so I cannot be certain. I have, however, corrected the workspaces table in all the installations, so hopefully I won't trip over it when I go to take the current project live.