MODx 0.9.7 alpha (rev 2218)

Upgraded sottwell.com, ran the installer and got this:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ’WHERE `setting_value` NOT IN (’MODx’, ’MODxLight’, ’MODxGreen’)’ at line 2 during the execution of SQL statement REPLACE INTO `modx_system_settings` (setting_name, setting_value) VALUES (’manager_theme’,’MODxLight’) WHERE `setting_value` NOT IN (’MODx’, ’MODxLight’, ’MODxGreen’).

PHP 4.4.4
MySQL 5.0.26-standard
Apache/2.0.55 (Red Hat)

Still have this problem. Uncached snippets end up being displayed like this:

[!eFormCSS? &formid=`ContactForm` &tpl=`ContactForm` &report=`ContactReport` &subject=`sottwell.com Contact`&replyto=`email`&debug=`1`&eFormCSS=`assets/snippets/eform/contact.css`]]

http://www.sottwell.com/contact.html

Strange, the beginning is cached [! and the end of your snippet call is uncached ]]

???

I noticed

The original parser changes all [! and !] to [[ and ]] at one point in the processing, then processes as normal. It looks like the new parser is not changing the opening [! correctly. But I haven’t spent enough time in the new parser code to be able to know where the problem is.

Is it related to this?

[[snippet]]
[[!nonCacheableSnippet]]
[[$chunk]]
[[*tvsAndResourceMeta]]
[[!*nonCacheableTV]]
[[!#*nonCacheableTVwithQE]]
[[+placeholder]]
[[++configSettings]]
[[~links]]

maybe a typo or something?

-sD-

Well, here’s an interesting thing. Take for example the left column on the Articles page on my site. It has an uncached AjaxSearch form (which doesn’t work, but that’s another issue), followed by an uncached Ditto call. If I change the AjaxSearch call to the new format ( [[!AjaxSearch]] ) the search block isn’t displayed at all, and the Ditto call gets the same display error already mentioned. So there’s more at work here than meets the eye.

If I use the new [[!...]] format for all the snippet calls, they all work. If I use the new call on the main Ditto call in the page content, it works.

If I use the old format for the AjaxSearch call and the new format for the Ditto call in the left column, all is well.

If I use the new format for the AjaxSearch and the old format for the Ditto call in the left column they both break as mentioned above.

Good research Susan. I had been experiencing some similar issues during testing last week. It all comes back to a single dilemma, which is the fact that in the current parser, noncacheable snippets are always parsed at the end, and in order to emulate that while recursive parsing is going on, and tag translation is always occuring from old style to new style, I get false matches between old and new style uncacheable tags. Consider the match on the opening tag of snippet calls like [[!newstyle]] and the closing tag of old style calls like [!oldstyle!]. The above sentence would get translated to:

Consider the match on the opening tag of snippet calls like [[[!newstyle]] and the closing tag of old style calls like [!oldstyle]]

before being parsed again, which is confusing the parser completely, making it render finally:

Consider the match on the opening tag of snippet calls like and the closing tag of old style calls like [!oldstyle]]

I’ll work on some ways around this problem. Ideas and additional observations welcome...

Maybe a really ugly regular expression to deal with [! but not [[!

Quote from: sottwell at Jan 04, 2007, 07:28 PM

Maybe a really ugly regular expression to deal with [! but not [[!

My philosophy on the new core is, if the answer is a regular expression, I am asking the wrong question. Advise, courtesy of Victor Brilon. I’ve reinvented the entire parser without them so far, and would rather not revert back to them if possible, but, alas, it may be that the only solution is to do so when supporting the old tag format. I’ll explore a couple of non-regular expression related ideas I have, and if they don’t work, I’ll call Victor for regular expression help.

Wait, maybe he gave me that advise in order to keep from asking for regular expression help

But seriously, I do believe it can be handled without them...I just need to adjust the way I implemented the tag translation. I think I figured out if I don’t translate the old tags when skipping noncachable snippets that the issue doesn’t occur, but I need to do some more testing to be sure it doesn’t create other issues.

Looks like regClientStartupScript doesn’t quite work (that’s why the AjaxSearch isn’t working on sottwell.com).

It’s including the filenames for external javascript files (scriptaculous.js and prototyp.js) but not a bit of dynamically generated javascript code that gets inserted into the document head.