Support/Comments for UpgradeMODX (1.2.0-rc)

Greetings Bob,

Ran across two things. One's likely a misunderstanding on my part, so I'll start with that and ask for a "help me out of my confusion" tip.

I couldn't successfully see more than 5 versions on www.mysite.com/upgrade.php. I changed the versionsToShow property to 10 but still saw only 5 recent versions. Cleared out the upgrademodx content from the MODX cache, deleted upgrade.php, then used the widget to generate a new upgrade.php in a freshly-opened incognito window, so don't think it's server or client caching. Desire to see more than 5 stems from your comments elsewhere about walking through a few steps when going up several versions. In this case I wanted to go from 2.2.15 => 2.3.0 => 2.3.6 => 2.4.0 => 2.4.2, but 2.3.0 isn't in the last 5 releases. Thoughts?

The other thing appears to be a less common use case. On some sites I have a different config_key than the MODX default (debate about that logic -- and I'm debating with myself too -- can be a separate subject; I've stopped doing that for new installations).

Problem comes when running the setup portion of upgrades where the config_key is different from the MODX default. The advanced install distributions contain setup code that asks for the config_key. Non-advanced (I gather that's the one you're grabbing) does not ask, and thus, when proceeding through install, it never recognizes that it's an upgrade install because it's looking for a different config_key.

Cheers and thanks for a great product.

On the number of versions, try changing line 416 of the core\components\upgrademodx\model\upgrademodx.class.php file

from this:


to this:



On the config key -- UGM uses the config key defined in config.core.php to find config.inc.php. Apparently the traditional distribution doesn't (and doesn't gracefully recognize the moved core either). I don't download the advanced version because it won't run on some servers and requires a different process to put the files in place.

I've argued for a long time that the traditional and advanced distros should be unified or at least that the traditional one should handle a moved core and renamed stuff without user intervention.

As a workaround, I think that you could temporarily create a copy of your config file with the traditional name. After the upgrades, you could check to make sure it hasn't changed. If it has, you could copy it back to your custom file.

Seems as though that patch should do it. Don't have an upgrade need to test on right now.

Understand your perspective on not using the advanced install in UGM. Because of my (past) use of differing config_keys, it pretty much counts me out of using UGM for those. The work-around could work, but the time to do it would probably equal the time savings of using UGM vs "old fashioned" upgrade.

Question: For those installs I made with the advanced distribution, that do use the default config_key, each has the core moved outside document_root, and both manager and connectors directories renamed. Will UGM handle sites installed with the advanced distro and/or previously upgraded the "traditional" way with the advanced distro?

I believe it will, though I don't think I've tested it directly on an advanced install site. I've tested it on several sites with a moved and renamed core and a renamed manager folder.

OK. Thanks for the clarification. Appreciate it.

Let me know if it works. I'm curious.

BTW, when I get a chance, I'll look at the MODX setup code to see if there's an easy way to make the traditional install respect the MODX_CORE_PATH and MODX_CONFIG_KEY settings.

I have renamed the manager-folder. Can I use UpgradeMODX or will it not work?

It should work fine in that case.

Thanks

Hi Bob,
great tool!!!

BTW: We deleted the check for new downloadable versions to always have the possibility downgrading very quickly if an update/upgrade leads to problems.

Thanks again for this time-saving tool!