096 RC2

Most of it’s been merged to trunk already, but there are a few things that stand out as possibly needing to be considered prior to releasing the final code:

Install related (all should be fixed for 096)
Other than needing some clarification on how/when to use the database updater and why we don’t automatically pick up the logins on updates, the following threads/posts could use a once-over. I’m sure a lot have been resolved (in all the following topics) but I couldn’t immediately find anything about them:

• UTF8 database change (needs extended instructions/explaination?)
• paths not updating on move/upgrade causes resource browser failures (if you don’t have to set it the first time, why should you have to set it when re-running the installer ... shouldn’t it at least be an option?)
• bug with trailing slash in cache sync processor? (possible fix included)

Users and Permissions Inconsistencies (bugs?) (first one)

• View/edit in tree menu linked together (This prevents locking down parent containers with editors accessing/editing sub-documents because they’re not viewable in the doc tree.) partial fix committed with full UI addition needing to be addede
• UI for above fix to allow override of behavior
• State/zip in webuser attributes too short
• Problem with NOT NULL and user creation
• Need separate publishing / creation workflow (might be a more workflow oriented feature for 097 or beyond)

General (top 2)

• need to add MD5 checksums of downloads
• distribution should be in an enclosing folder
• base path code borked?
• Base URL/HREF problems seem to be acting up... (Susan’s commented on it numerous times in numerous places ... might be server-related?) (Jason/Netnoise fix coming soon)
• all open tree folds up after saving (annoyance)
• Please wait... JS error?

Deferred to 097:

Document Object (Publishing related)
There is some behavior in general that’s inconsistent or at best non-intuitive:

• Publish checkbox overridden by scheduled publishing dates
• Unpublish date doesn’t work without publish date (if publish date is blank, and published is checked, shouldn’t it enter that as the publish date by default?)

Default Resources

• Weblogin improvment
• Web signup improvment
• Random passwords in websignup improvement
• Weblogin bugfix (committed this at rev 2508)
• Multiple mootools version calls
• multiple mootools calls overwrites effects and breaks stuff (can we check for inclusion in header already before calling regClientJS stuff?)
• QE borks in IE7 (possible fix?)
• include_once fix for ajax search

TinyMCE & FCK Editor

• Problem uploading files (with possible solution) in FCK
• Invalid XML response in MCPuck (same as above?)
• XHTML Compatibility (do it but include the old way for a fallback?)
• Buttons fail in TinyMCE in Fx 2.0.2

Here is an RC2 build (rev 2521) with everything that’s been committed so far. This is for internal testing and review prior to public RC2 release...

http://modxcms.com/testbuilds/modx-0.9.6-rc2-2521.zip

Any feedback or test installs yet? Any ideas on the above list of issues?

OK ... I updated all the raw links to include a description and additional notes as appropriate... maybe now some of you folks will chime in!

Sorry but for the moment I’ll raise more questions than I’ll answer them

I just upgraded one of my websites from 0.9.5 to 0.9.6RC2.

Strange stuff happened at first (when I clicked any manager menu item, the "main" frame was opened full screen and I lost both menu and tree frame ). I cleaned cookies, session and cache from my browser and everything got back to normal.

But the strangest thing happens when I set manager language and character encoding : while the french language file is correctly encoded as utf-8, accents get displayed as question marks ( ? ) instead. I noticed along the way there was a misnamed duplicate in language file (francais-utf-8.inc.php -> older plus francais-utf8.inc.php -> last updated).

Anyway, back to the issue :

1. I re-checked encoding, nuked language file and re-uploaded it (just to be sure) -> no changes. Also made sure the Manager HTML and XML Language Attribute is set to "fr". When I cheked all frames source code charset is UTF-8 and xml language is "fr"...

2. I thought there was a problem uploading MODx files on upgrade, thus I re-uploaded the whole manager directory (since it seems to come from here). No improvement.

3. I checked both config.inc.php and the modx_site_settings table : just noticed the old etomite_charset table was still there and with the bad charset : changed it to UTF-8 just to be sure. But then did a clean 0.9.6 RC2 install, checked for tables there and found out there was no etomite_charset table anymore (correct me if I am wrong). I nuked the old etomite_charset table. No changes. Also noticed The site ID was not identical between config.inc.php and the database : corrected it. No change.

Now I would have understood if I had charset problems with the website’s content since it has been converted from latin1 to utf-8 but content has no issue whatsoever, it’s the character display in the manager that does not work. The clean 0.9.6 RC2 install I did works just fine so it’s definitely not the language file encoding which is at fault. Also, funniest thing is, I did an upgrade from 0.9.5 to 0.9.6RC1 on the same server and I didn’t experience this problems

I’ll keep on digging but if you have an idea...

Update : I have tried to switch manually the manager pages encoding to Latin1 with FF and they display properly

It would seem while the meta charset value is utf-8, the page content is still iso8859-1 (Latin1), there is something wrong elsewhere : I checked the response headers :



As you can see it’s also properly set to UTF-8...
I’ll keep on digging... could there be a remaining etomite_charset in the code conflicting with the modx_charset ?

I can’t think of any explanation

What am I missing and also, has anyone suffered similar problem on 0.9.5 -> 0.9.6 RC2 ?

Re !

I did dig deeper into the config.inc.php file, and while all DB information was correct, I checked the file against a clean 0.9.6 RC2 install and found that the config.inc.php code (the part after line 17 // automatically assign base_path and base_url) had not been updated (maybe there is a problem here...).

Reading both codes, I realized many things have changed (PHP_SELF stuff dropped if I am not mistaken).

Jason and I spent a while re-prioritizing and cleaning up the list above. Any that can be fixed are welcome, but the ones that are required for 096 are indicated in parenthesis next to the section. If they’re striked-thru, then they’ve been fixed and are (or will be soon) committed.

Playing with RC2, I encounter an issue with AjaxSearch resulting in this error :



I have searched the forums and found this :

Quote from: hald at Mar 13, 2007, 05:49 PM

Ryan; Is it a problem having two versions of mootools loades at the same time? I’m having problems getting ajaxsearch to work and I thought this might be the problem.
Hal

Quote from: rthrash at Mar 14, 2007, 07:42 AM

There are issues that are resolved in the latest internal test build with Ajax Search in subversion. We should have another build out soon. To answer your question: I’m not sure!

I just wanted to check if this issue has been resolved and if I should submit this in FlySpray ?

It has not been fixed David, nor is it likely to get fixed unless someone steps up and does it. It only affects front end functionality when logged into the manager so it’s not super-critical. Then again, I could be completely wrong.