Quote from: rthrash at Sep 03, 2006, 04:04 PM
Another bug with the caching system is that it dies with snippets or plugins that include lines that begin with things like "// <?php" or "// ?>".
It’s not impossible to do a sanity check on snippet saves that could remove these comments; there’s already new stuff to do with <?php in the snippet editor.
However, there may be snippets out there that take advantage of the fact that you can flip *out* of php and into straight HTML and then flip back in again before the end, and this issue is symptomatic of a wider problem with collating partial PHP scripts.
Quote from: xwisdom at Aug 28, 2006, 05:10 PMI have a long term long solution but that will not be ready in time for the release of 0.9.5.
So, xwisdom, what is your long-term solution, and what is the timescale on it, given that 0.9.5 can’t be released unless there’s some sort of solution!
@yama: is that a new 0.9.5 issue, or is the same issue present in 0.9.2.1. Also, is it all themes or just one?
--
@the powers that be:
Could we please add 0.9.5 Beta to the bug tracker as a Reported Version?
Probably overkill to have each build in, but "0.9.5 Betas" (plural) would be useful; we could add these issues and it would be clearer what was a new bug, and also encourage us to add some of the bugs in this thread that might get forgotten about.
Quote from: yama at Sep 03, 2006, 09:22 PM
The display has collapsed by IE. (Japanese)
It’s an issue with the contextmenu in manager/frames/3.php.
The original IE contextmenu has been romoved, now we have only the Mozilla menu that seems too much tightened for IE.
we need to change width of contextmenu in the code at the bottom of 3.php file.
IE works better width: 200 instead width: 170
</script>
<div id="contextMenu" style="position: absolute; right: 20px; top: 20px; z-index:10000; width: 170; height: auto;visibility: hidden;">
<iframe name="oPopup" style="width:170px;height:100%" frameborder="0" src="index.php?a=1&f=3c"></iframe>
</div>
-
MODX Staff
- 10,725 Posts
As far as I can tell, the trunk is un-unusable at this point; and some other incompatibilities and issues beyond the new caching system are plaguing my tests with it, for instance the aliasListing variable is no longer available on the document parser class which breaks several plugins and core API methods. This makes it very hard to make additional progress on other features and bug fixes.
So until Raymond can finish work on the new parser to address the problems that have been identified, I suggest that we revert trunk to the last commit prior to Raymond’s merge and get back to testing and fixing other critical bugs. If Raymond can address the critical caching issues and ensure compatibility of the document parser class before we are ready to release, we can at that point work with it from Raymond’s branch until it is in an acceptable condition to re-merge into trunk for release.
Any other thoughts?
On the positive side, merging the new parser into the trunk has at least given it the wider exposure to reveal a series of issues that can be worked on. But it is holding up testing of 0.9.5 - without the new parser, the MODx trunk is solid enough for real-world usage on a non-critical application, and it is actual usage that will best test it.
So given that "add a fancy new recursive parser" is not actually on the roadmap for 0.9.5, I think the priority has to be getting a new release out of the door with the bug fixes and new snippets etc.
The new parser is clearly going to have to go through heavy testing, and I think you have to be prepared to hold it back for another 0.9.x release - even though there currently is not one planned.
The question then comes of what the "no-recursive-parser-yet" and "with-recursive-parser" versions are numbered.
Frankly, I think a 0.9.4 release would be welcomed by many at this stage, but it does clearly indicate that we’ve not achieved 0.9.5. Or, if there’s a chance that the parser won’t be ready before 1.0, allocate it to a cancellable 0.9.6. (0.9.6 would appear to be easier to add from the perspective of Flyspray).
I know the constant refrain is "it will be released when it is ready", but that should also mean "there is a release when one is ready".
-
☆ A M B ☆
- 24,524 Posts
Yes, I would really like to see a release now. The recursive parser will still need a lot of work before it’s ready, I believe, especially with the caching issue. I think we’ve fallen victim to "feature creep" here; we could have had a nice bugfix and update release weeks ago. Whatever happened to "release often, release early"?
If you’re starving, but Mom burned dinner and had to start over, do you want to wait another couple of hours, or would a sandwich to hold you over be a better idea? My mother always did the first when disaster struck, I remembered that and always did the second.
I like the sandwich analogy; sandwich can also mean "to insert or squeeze tightly between two people or objects", so Sandwich Edition would be a doubly apt internal name for a new release if it is not to be the final 0.9.x release.
And just because I didn’t explicity say it: +1 on the "reverse out new parser from trunk" idea. I can’t really see there being any opposition to OpenGeek’s suggestion.
Yeah, I’m in agreement with reverting to the previous parser system. This current version is still in beta 2 and should not delay the release of 0.9.5.
@OpenGeek: Can you check to see if aliasListing is present inside your siteCache.idx.php. From what I can remember that variable should have been present inside your site cache file.
☆ A M B ☆
