0.9.5 Issues

There are some odd corner cases or caveats where issues crop up with 0.9.5, especially with upgrades. This thread should serve as a pointer to interim solutions:

Can’t publish documents after upgrading to 095? workaround

QuickEdit not working in IE7? here’s a solution

Caching seems to be broken? Disable or remove the Template Switcher plugin.

Blank pages on the front end? Disable or remove the Template Switcher and Page Hit Counter (if installed) plugins. Also make sure your not found/not authorized and site start pages are all public (not protected) and exist. Clear/truncate your error/event log.

Added two entries.

The QuickEdit menu displayes the opposite value from the value set in the Manager. Is this a known, related bug? It seems not to be solved by disabling the Template switcher plugin (which solves the caching problem).

Many thanks
Gino Lardon

Template switch is going away completely in the next release.

I remember that there was an issue reported during the beta stage of TVs not always saving. I had never experienced it and I assumed that it had been squashed. However it has suddenly reared it’s fugly little head on a site I’m working on now...

This installation is 0.9.5.1 RC1 (Rev 2258), and it was upgraded from 0.9.2.2. The content editors report that this was also a problem before the upgrade. I was skeptical and asked them about any auto-form fillers, browsers, etc., but after some experimenting it happened to me as well.

The TVs in question are simple text fields, and the best way to get this bug to occur seems to be to enter a value into one document, save it, and then edit a different document and enter the same value in the same TV there. After saving the document, the TV is empty. Retyping the entry (instead of choosing from the browser’s pop-up list of recent text) does not work either. If, however, you change a single character (from the text you entered previously), the TV is saved with the document.

I’ve tested this with IE7 and Firefox 2 on XP; same results in both browsers. The content editors are mostly using Firefox on the Mac. So this doesn’t seem to be browser-related...

Any clues on what might be going on here?

* bump? *

That’s an RC that I think still had that issue, but I’m not certain. You could browse the commit logs. There were exactly 200 commits between RC1 and the final release. Reason for not using 095 final?

Maybe I’m confused, but I’m running 0.9.5.1 RC1 (rev 2258) on this site. The final version (0.9.5 - which I’m running on some other sites) seems to be rev 2106. So either the bug wasn’t fixed before the final version or it was reintroduced afterwards (or there’s something that I’m not getting, which is always a strong possibility).

After upgrading to 0.9.5 I had an issue that really isn’t a bug and probably doesn’t affect many people but I thought I should post it here in case someone else runs into the same problem.

If you are experiencing this problem please leave a short comment letting us know. If it affects more than just a few we should probably implement a permanent solution.

Problem:
Bad URLs are sent to the login page or homepage instead of the 404 page (affects non-numeric URLs only).

Reason:
Because of reasons I wont get into, a NULL value in the site_content.alias field makes MODx think a non existent page actually exists.

Solution:
Run this SQL code in your MODx database using phpMyAdmin or some other mysql client (replace [prefix] with the table prefix for your installation).

Adam, would that make sense to implement across the board? I think more than just you have bumped into it... :/