[RESOLVED] 2.2.9 Package Manager Bizarre Problem

Quote from: jrg at Sep 22, 2013, 05:30 PM

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.

I have seen such circumstances before, where automated installers put hardcoded paths into MODX config files and SQL tables. It works fine until someone needs to migrate the site to a different server, then.......

The three core.config.php files provide a path to the core in the case of the core being moved to a non-standard location - it can even be moved outside of the web root for extra security. Since the main config.inc.php file is in the core, the index.php needs to be able to find it to include it, and the connectors and the manager also need it.

All of the paths in the config.inc.php file can also be modified in case you want to change the name or the location of any of the directories. Some of them need to be in the web space, since they have files (such as js and css files or AJAX processors) that are accessed via URL, but their names can be changed to add a bit of security-by-obscurity to them. For example, the /manager/ directory could be renamed to something else so a quick check for domain.com/manager/ wouldn't return the login form to those looking for MODx installations to try to hack into.

Just to add a caution to what Susan has said. If you make a whole lot of changes to directory names and locations, things can get a little hairy when it's time to upgrade MODX.

FWIW, the installs that I've had this problem with, same as this thread's original issue all have had {core_path} set in the workspaces table. The root cause of packages looking to an incorrect path is still unresolved, at least for my sites (and others over the past year or so here on the forum) that have been reported back that the workspaces table value is correct.

Quote from: frogabog at Sep 23, 2013, 01:45 AM

FWIW, the installs that I've had this problem with, same as this thread's original issue all have had {core_path} set in the workspaces table. The root cause of packages looking to an incorrect path is still unresolved, at least for my sites (and others over the past year or so here on the forum) that have been reported back that the workspaces table value is correct.

When I said it was "resolved", I was over-simplyfying a bit. I had to manually download the transport file (zip) and put it in .../core/packages/. Then everything worked fine (but didn't prior to fixing the workspaces table (even unpacking it didn't help prior to the correction).

The error messages prior to manually placing the transport file were (from the error log):

[2013-09-23 04:43:07] (ERROR @ /connectors/workspace/packages.php) MODX could not download the file. You must enable allow_url_fopen, cURL or fsockopen to use remote transport packaging.
[2013-09-23 04:43:07] (ERROR @ /connectors/workspace/packages.php) Could not transfer package gallery-1.5.2-pl.transport.zip to /home/content/53/6837553/html/www/test.teachbridge.com/core/packages/.

Prior to cloning the live site (for testing the upgrade from 2.0.8 to 2.2.9 and other stuff), I upgraded all the packages that needed it (there were 3 of them). That worked fine with no complaints about cURL, etc. So it would appear something has changed between the two releases to cause this problem.

I'll also check out the PHP settings (by running phpinfo.php) to double-check that cURL is, in fact, enabled and that there is no funny difference between the live site and the test sites using sub-domains. I have to admit that I trust this particular hosting provider like a hole in the head (just a personal bias). I'd like to make sure it's not a problem caused by the hosting provider upgrading PHP (or something like that).

The release of PHP is 5.2.17 and cURL is enabled:
cURL support enabled
cURL Information libcurl/7.19.7 NSS/3.13.1.0 zlib/1.2.3 libidn/1.18 libssh2/1.2.2

Hopefully RESOLVED!

I spent some time experimenting (changing some MODX code) and in the process needed to remove and attempt to reinstall packages. I returned the modified code back to the way it was after discovering what was really happening. This is the behaviour — the problem is a situation that can occur that MODX does not detected early enough and results in later code failing and issuing a misleading error message(s).

Let me describe the situation that first prompted this thread and describe what caused the problem.

In 2.0.8, a web develper attempted, unsuccessfully to install the Gallery extra. The attempt mucked up things royally and I was asked if I could get MODX functional again without losing the work done since the last backup (as ususal, backups were not being taken frequently enough).

I went into the Package Manager and clicked "Uninstall", which (if I remember, which I may not) more or less worked. It didn't solve the problem, but then I went into core/packages/ and trashed any files that had any mention of Gallery in their names and also went through all the resources and categories and did the same. I cleared the cache (using the MODX command and by trashing the contents of the core/cache/ directory). Apparent success. Development continued and eventually the site went live.

Fast forward to the present. After an apparently successful upgrade to 2.2.9, I went into the Package Manager and clicked "Install" on the line for Gallery.

If this seems alright to you, then you have missed the point — just as I did

THE REAL PROBLEM

Package Management has two distinct functions when it comes to installation and their counterparts when it comes to uninstall:

• Download the transport file
• Install

• Uninstall
• Remove the transport file

What I had failed to do was use the MODX Package Manager to remove the transport file (I had done it directly in the file system). The result was that MODX "remembered" the package had been installed and showed it in the grid. This "memory" persisted through the upgrade.

CORRECT APPROACH

Correct is always to use the MODX Package Manager to trash the transport files as it will, effectively, remove its "memory" of them.

So installing a new package should involve

• Use the "Download Extras" button of the Package Manger to download the transport file. This will cause MODX not only to download the file, but also remember it and show the package in the grid.
• Use the "Install" button that shows in the entry for the package in the grid.

That DOES work fine. Notice that if the transport file had been trashed manually, but you "put it back" (by downloading it and putting in the core/packages/ directory), the install will work (as long as you download the correct version of the transport file).

FIXING THE PROBLEM IF YOU DO GET IT

If the transport files have been removed, but the package still shows in the grid (hopefully it was either not installed or you uninstalled it before the transport files got removed), then use the "Remove" button for the package. It may produce some error messages, but it will get rid of the "memory" of the package. If there had been prior versions of the same package, use "Remove" as many times as necessary to get rid of them as well (so that the grid no longer shows the package).
______________

Quote from: BobRay at Sep 22, 2013, 10:29 PM

Just to add a caution to what Susan has said. If you make a whole lot of changes to directory names and locations, things can get a little hairy when it's time to upgrade MODX.

Yes. I remember experimenting with a "multi-site" installation sharing "core" when I first tried MODX. One has to be very careful. One issue with the "multi-site" is that ALL the sites have to upgrade at exactly the same time (because of the shared core).

Moving the core seems like a good idea — I like the idea of it being outside the web-root (which is what I do if I get to do the initial installation). Changing names, though, just seems like it is going to be error-prone. It might be alright if one creates documentation, including a good checklist, as one goes along (and keeps it up to date).

By the way, I use your book as a reference (I've not actually read it cover to cover). You did a great job — thank you.

Thanks for the kind words.

If you're going to move the core outside the web root, you probably don't need to change its name, but doing so adds a little more security and not too much more trouble. You have to edit the MODX_CORE_PATH in the main config file and the three config.core.php files in either case, so it's just as easy to change the directory name in the process.

When you upgrade, you just need to put the core files in the new location.