0.9.6 Release Candidate Support

Wow. I just had a pretty excruciating upgrade experience. I’ve had minor glitches before, but nothing that was quite this stressful (lesson learned: don’t start an upgrade after 3 am thinking it will be a breeze and you’ll be in bed in 15 minutes...).

This site was originally built in Etomite and then later upgraded to MODx 0.9.2.1. I hadn’t had any problems with it at all since the upgrade, but I figured it was time to cross the 0.9.5 barrier. Since I’ve now done about a half dozen such upgrades and more fresh installs of 0.9.5+ I figured it’d be a piece of cake.

After uploading the latest 0.9.6 RC2 SVN files and running the installer (using the upgrade option but entering in the database connection info), I found that some pages on the site (about half, including the home page) returned 404 errors every time, while the rest worked perfectly. There seemed to be no rhyme or reason to which pages were failing, but they were consistent. So I tried everything I could think of (clearing the cache, overwriting the cache files with blank versions and reinstalling, changing character sets, etc.). I even rolled back all of the critical files to the 0.9.5 release, and nothing helped. After about three hours of that, I figured it out. I had been using TraceWatch for visitor stats, and it seems as if 0.9.5+ does not play well with that (at least the version I had installed). Disabling it fixed the 404 errors immediately. I was going to switch to Google Analytics anyway, but I had planned to do it tomorrow...

So the other issue that caused me to pull out a bit more hair is that TinyMCE is throwing errors like mad and not working. It seems to just be a minor path error caused by a typo somewhere, but while I was struggling to figure out the TraceWatch problem I thought the two might be related and that sent me down a few garden paths. The errors are all things like:

Warning: Unknown(/home/xyz/pdq-www/assetsassets/plugins/tinymce/tinymce.lang.php): failed to open stream: No such file or directory in /home2/xyz/pdq-www/manager/includes/document.parser.class.inc.php(724) : eval()’d code on line 12

So obviously "assetsassets" is the problem, but it’s morning now and I’m going to bed (the clients can use FCKEditor and like it).

Anyone else have this TinyMCE problem?

Zap, did you use the internal SVN branch or public trunk?

Zap, try setting the correct path for the File Manager Path (under Tools->Configuration->File Manager). The path should be set to the root of your site. Based on the path given above, I think it should be set to this:

/home/xyz/pdq-www/

Give that a shot and see if it helps!

Jeff

I had the same experience zap, and simply editing the TinyMCE plugin to use base_path instead of file_manager_path solved the issue. The plugin code should not reference paths that are not automatically set based on the actual deployment.

OpenGeek: Yep, that did indeed solve the problem. Thanks for the tip! I knew that posting the issue here and going to sleep was a better idea than to keep at it a while longer.

Bravado: My File Manager Path is actually /home/xyz/pdq-www/assets. That seems correct to me, since I want the File Manager to start from the assets subdirectory. So although changing that setting would’ve also corrected the problem I think it would be better to modify the TinyMCE plugin to use base_path.

Ryan: This is the public SVN (rev 2446).

So my long-winded story that ended by removing TraceWatch doesn’t require any action from the dev team. I just thought I’d share it because it took me so long to figure out what was going on and there may be other scripts that cause the same bizarre symptoms (consistent 404 errors for seemingly-random pages). Plus it made me feel better to vent...

I successfully separated folders with site content related files from the `/assets` folder. I put them in a separate folder in the site root. Thus my `[(file_manager_path)]` points to a subfolder of the site root, which contains 4 folders: `/files`, `/flash`, `/images`, and `/media`. It works with no problems in 0.9.5. Will the changes in 0.9.6 that make use of `[(file_manager_path)]` make that scenario feasible or will it have bad side-effects?

I haven’t tested it yet, and I’m not aware how far does this change go.

Given that the resource browser will probably be changed soon, it would be great if there were more flexibility in the assets paths (and their subpaths: images, files, flash, etc.) in the future. One thing that I’ve run into multiple times when converting existing websites is dealing with an images directory in the site root. I don’t like to move these so that existing links and search engine references work, but the resources browser makes this more complicated than I’d like.

I had problems with the latest from SVN.

I see in the config.inc.php file that it’s using $_SERVER[SCRIPT_NAME] to set up the base_url. Problem is that my $_SERVER[SCRIPT_NAME] is /execscriptdir/php.cgi. So the execscriptdir ends up getting added into the base_url and base_path.

Older sites on the same server have $_SERVER[PHP_SELF] being used in the config.inc.php file instead, and they work with no problems.

Quote from: sottwell at Mar 28, 2007, 10:28 AM

I had problems with the latest from SVN.

I see in the config.inc.php file that it’s using $_SERVER[SCRIPT_NAME] to set up the base_url. Problem is that my $_SERVER[SCRIPT_NAME] is /execscriptdir/php.cgi. So the execscriptdir ends up getting added into the base_url and base_path.

Older sites on the same server have $_SERVER[PHP_SELF] being used in the config.inc.php file instead, and they work with no problems.

Hmmm, I tracked this down to a commit on Dec 28, 2006. See http://modxcms.com/bugs/task/429 for details, which I have reopened to track this issue.

oops... I looked, but didn’t see anything, and opened a new bug report on it. Sorry... feel free to delete it.