MODX Staff
There’s the problem. QuickEdit is an add-on that is included in the default distribution. It is not built-in to the core of MODx. This is one of the reasons why 0.9.7 will be distributed as a core package, and add-ons either separately, or in a custom distribution that includes the core along with a set of components meant to work together without conflicts to implement a specific style or type of site.
Sure, I understand this. What would be interesting to know is the minimum "mootools build" required by "built-in" MODx parts like Quickedit and some manager javascrpt features. Or are you saying they aren’t using any mootools anymore?
Granted quickedit could and should be considered an add-on but to return to the issue of the original post: the MODx manager throws the same error, just less frequently. Just today i experienced it twice when i clicked edit document from the context menu of a document in the tree. Besides even if the error does not show up there is a tremendous slowdown.
Quote from: MrDutchy at Sep 01, 2007, 06:04 AMThere’s the problem. QuickEdit is an add-on that is included in the default distribution. It is not built-in to the core of MODx. [...]
Sure, I understand this. What would be interesting to know is the minimum "mootools build" required by "built-in" MODx parts like Quickedit and some manager javascrpt features. Or are you saying they aren’t using any mootools anymore?
Granted quickedit could and should be considered an add-on but to return to the issue of the original post: the MODx manager throws the same error, just less frequently. Just today i experienced it twice when i clicked edit document from the context menu of a document in the tree. Besides even if the error does not show up there is a tremendous slowdown.
I am kind of hoping someone from the coding team (ff2 + winxp users?) starts to experience the same issue since I am starting to wonder if something else is going on on my system and that of the original poster. Something specific to a certain firefox addon configuration or something maybe?
I believe this assessment is correct. It is unfortunate though if this isn’t considered a high priority because of these reasons. Is there even a bug tracker / ticket for this? The past few days I’ve been working on three different websites, simultaneously, for my employer that were built in MODx. At any given time I could have a whole lot of junk running on my computer. I was under the impression MODx is supposed to be built with developers in mind and those are just the people that would be most impacted by this issue. What self respecting developer does the majority of their work in IE?
I’ve only ever noticed this "the script has stopped responding" error when I have a lot of browser windows open and am visiting a bunch of web sites that use too much javascript all at the same time. Or god forbid, if I have a Java applet running in a browser; Fx likes to choke on those. Or if I just have too many applications open and Windows is drowning in it’s own excrement, but perhaps I’m being too graphic. But otherwise, the latest manager in 0.9.6 is the leanest and meanest of the MODx manager interfaces yet, and performs so much faster than it used to.
The Manager is being completely rewritten for 0.9.7. It wouldn’t make any sense to redo the 0.9.6 Manager to use less CPU at this point, especially given that a workaround should resolve it.