095 Release Candidate

Remaining work for final release
[*] languages updated as appropriate (any ones that can make it into the release)
[*] remove cb2.js and modx.js stuff from Docmanager module -- then delete cb2.js!


Known issues
Because we had to remove webelm.js from the header and in the process lost cb2.js (cool buttons) in order to get rid of a Tiny MCE conflict, there’s a few things that could use some patching up. (tested in Fx 2 with Firebug extension):

1) Tree no longer refreshes when saving / adding a new document.

2) There is always a delay for the ajax loading window thing even if it’s done... it should not have an extended delay and get out of the way ASAP. Seems like a delay of 1.5-2 seconds, which gets annoying quickly.

3) Manager system events log, manage modules, manager users, web users has a weird JS error every time the page loads (but it seems to function fine ... the line number changes but the error text is the same):

uncaught exception: [Exception... "Not enough arguments" nsresult: "0x80570001 (NS_ERROR_XPC_NOT_ENOUGH_ARGS)" location: "JS frame :: http://blah.com/manager/index.php?a=106 :: <TOP_LEVEL> :: line 181" data: no]

4) Doc Manager gets a warning: Use of captureEvents() is deprecated, see bug 330494 (also need to remove cb2.js /cool buttons) done after public RC1, but in SVN trunk

5) When logging in (and one other time... can’t find it off the top of my head), an error:

[s]top.mainMenu.stopWork is not a function.
rpcLoadDataindex.php?a=1&f=t... (line 187)

Go get it here actually preferably from latest SVN as several bugs should be fixed mentioned in this and the public thread

Ah, the joys of public SVN access. Someone’s added 1) as http://modxcms.com/bugs/task/643 but annoyingly bundled it in with another bug:

when adding a new document and setting ’published’ to yes, and ’publish date’, the document still remains unpublished when you save it. The publish date remains saved, but ’published’ is set to No. - you have to edit the document and set published again.

To me, this seems entirely unrelated. Should I split them out into two bugs, and add issues 2-5 just so other people know we’re working on them.. or are they already added?

Bug #655.

A bit of a nit-picky bug... in the Combined View in Manage Resources, all locked items say "this plugin is locked" no matter what they really are.

In the rest of the tabs, they all say "this template is locked"

Version 1914

http://modxcms.com/bugs/task/512 seems to be missing in latest RC1, rev1909

reported at: http://modxcms.com/forums/index.php/topic,8574.msg60742.html#msg60742
and few other places.

Quote from: Dimmy at Nov 06, 2006, 01:11 PM

I noticed in Safari 2.0 Mac OS X when you complete the installer it takes you to the first page of the manager without the frames. Has anyone else experienced this or was it a fluke?

Did you file a bug report on that?

this happend to me lots of time but only when I was logged in the manager (to make a database backup before upgrading) then when finish upgrading it wil send you directly to a frame instead of the manager login or manager homepage

Quote from: sottwell at Nov 06, 2006, 11:00 PM

Same here. Firefox 2.0 on Mac, if I’m already logged in and do the upgrade. Log out and log in again and it’s fine.

Why not just modify the installer to look for a manager session? If it exists then it can be set to kill the session when the user clicks the first Next button. That’ll solve that problem.

Quote from: PaulGregory at Nov 07, 2006, 02:47 PM

In the light of OpenGeek saying Resources = Documents, web links and Elements = templates, chunks, snippets, TVs, plugins...

Should we change the Resources tab?
Should we change the phrase "Manage resources"?

The second use of Resources can be changed to Elements, but this section also includes "Manage Files" as well as "Manage META tags and Keywords" - and I really don’t think Files count as Elements.

My view therefore is that the menu entry (and on-page phrases) should change, but the tab should remain.

On the one hand, I don’t think we should change terminology if it’s likely to be changed again soon, but if Elements is the future then it should be considered now before we release a version that is likely to see a lot of documentation work.

I think things should stay as they are for now. The "resources/elements" bit is still just an interesting discussion, and will eventually evolve into something we can all more-or-less agree on.

Ryan adds: agreed ... the next release will likely have lots of semantic differences

In RC2 (possibly earlier), QuickEdit’s "Edit Content" button has changed from using

to


resulting in the "loads homepage" issue reported on the forum (no FS# yet) (FS #666) if you have a base href.

"#" should be changed to the present page url.

Also, I’m scared that this will screw up the QE links I have fudged on one Ditto site, as the page ID isn’t being passed in the javascript....

Incidentally, I’d like to see a new version number in QuickEdit, presently there isn’t any version number just a date from last year. It will be much easier to release post-095 updates for QuickEdit if people can identify what version they already have!

Quote from: garryn at Nov 09, 2006, 06:51 AM

"#" should be changed to the present page url.

Actually, adding a ’return false;’ to the onclick event of the Edit buttons should fix the issue.

Also, removing the "javascript:" at the beginning of the onClick will help as well. I’ll go through the code and see where else this occurs and fix up what I find.

TinyMCE 2.0.8 ... RC2 Rev1942 , IE6.0 XPSP2

TinyMCE is not working ...

Search highlighting still doesn’t seem to be working in the demo content. If it’s not going to do so, we should remove the plugin from the demo content install.