Snippet executes twice - Seems to be Revo bug

Is this happening in Flexibility?

If so, it's this line in your head.



You've got a couple of options here, either remove the and replace with something like [[++introtext]] or another placeholder of your choosing or you can spoof it by entering anything (even a space) in the introtext field.

Bob, you once presented a snippet that may be able to fix this but I've since lost it in the millions of posts. What happens is the


attempts to capture the page content, but if there's no "text only" in the content but rather a snippet within the first 200 characters, MODX processes the snippet (or chunk, TV, etc.) in the head AND in the content.

Quote from: BobRay at Dec 29, 2012, 08:24 PM

$_SESSION variables will persist across multiple requests as long as you don't mess with the MODX session.

$_SESSION persists state across multiple requests for a given user. I'm talking about state that is initialized/unset on each new initialization of the ModX life cycle. So with $_SESSION['foo']=x, we return the page back to the user, and when they come back we can retrieve x. I'm wondering if there is a state bag just for the current request. We wouldn't want to just re-use something like $_REQUEST as a global statebag because that can be hacked. This is why I suggested using $modx or something else that we know is clean and always available throughout the application.

Thanks for digging into the Mobile Detection plugin. Your issue is more interesting now, but I can't think of anything that would cause it unless there is another plugin involved. You could selectively disable other plugins (if there are any) and see if that has any effect.

Sure, I can play the disabling game - that's SOP. But I can't imagine a scenario where an unhandled exception should be allowed to determine whether something gets executed once or twice. That makes no sense. I'm still inclined to believe this is a bug in the core, hardly unheard of.

Thanks for your ongoing feedback!!

The

is found in the MODX Boilerplate as well (Flexibility was initially built with the MODX Boilerplate). I'd love to find a solution for this as I'm really not so good at making sure the introtext field is filled in with relevant text.

@Frogabog: I'm not using Flexibility.

EDIT: Oh dear, this is getting way beyond my current understanding of the platform, and I'm not longer spending any time actually building my site. :^O

Well darn... Sorry I couldn't help. The only time I've ever seen a snippet execute twice is when that line is in the head. Saw it again last night before I remembered to alter it.

Quote from: captainstarbuck at Dec 29, 2012, 08:51 PM

$_SESSION persists state across multiple requests for a given user. I'm talking about state that is initialized/unset on each new initialization of the ModX life cycle. So with $_SESSION['foo']=x, we return the page back to the user, and when they come back we can retrieve x. I'm wondering if there is a state bag just for the current request. We wouldn't want to just re-use something like $_REQUEST as a global statebag because that can be hacked. This is why I suggested using $modx or something else that we know is clean and always available throughout the application.

Maybe you could use modRegistry for that kind of things? http://rtfm.modx.com/display/revolution20/modRegistry

about the double snippet execution I cannot help either =/, sorry!

I'm getting it again and I nailed this down by finding another bug.

I have the a chunk with the following:
The using_accordion TV is a radio with one value 'yes' and the other is 'no'. If the page needs to do an accordion for content then it includes the jQuery UI script for it, otherwise not. Simple enough.

The above chunk causes the page to load twice. My snippet loads twice (and other stuff probably does too) and I get those Cannot redeclare function-name() errors. I tried surrounding my functions and my entire snippet in if(!function_exists(FUNCTION_NAME)){//code} but I either got that error or nothing at all.

OK, so if I remove that one line above which checks the TV, the errors go away. Replace the line and the errors return.

Here's the weird part. If I replace the line as a comment and even bust it up, it still returns an error:
I even got malicious with it and I still got errors:
Note: It shouldn't even be processing that line.

If I just put a space before :then, it stops parsing what's in the comment - or at least it stops throwing errors.

And the Fix: If I add an else clause, all of the problems go away!

The documentation shows an example without the else clause. This is clearly a bug somewhere in the parsing - and it's amazing that it would continue to parse that malicious code.

I believe others can stumble on this as I did. I'd like to get this in the issue list. The good news (as far as I can see now) is that there is now a documented solution.

NOW... To the original problem. I reported that some exception was causing my code to execute twice. This is yet another example of that. When the parser finds a :then without a :else (in this case) it must be throwing an error. That is uncaught, causing my snippet to execute twice, causing the Cannot redeclare function-name() error. That's another issue that I'd like to get into the tracker, now that I've found a couple ways to reproduce it.

HTH

Quote from: captainstarbuck at Jan 01, 2013, 08:30 AM

I have the a chunk with the following:

<script type="text/javascript" src="http://code.jquery.com/jquery-latest.min.js"></script>
[[*using_accordion:is=`yes`:then=`[[$accordion_script]]`]]
...

Why are you including the script tag in the above chunk at all? Is it not in the $accordion_script chunk as well? Maybe I'm missing something, but if the script tag is in the chunk, what is the point in listing it prior to that chunk call? If you ask me and my tiny brain... if it's being executed twice, it's because it's listed twice.

(it's possible I don't know what I'm talking about, btw)

OK, so if I remove that one line above which checks the TV, the errors go away. Replace the line and the errors return.

And the Fix: If I add an else clause, all of the problems go away!

[[*using_accordion:is=`yes`:then=`[[$accordion_script]]`:else=``]]

using the :else=`` is a good idea universally, regardless. If you don't tell it what to do if there's no true result in the call, it wants to know what else to do.

If you want to use if statements, look at the If extra/package, but be careful of using them multiple times, apparently multiple ifs can slow the page rendering. (but I can't verify that)

you should allways add :else together with conditional output-filters.

If the condition doesn't match and there is no else the tag will stay unparsed and modx will try to parse it again in the next parsing-loop.
This can slow your parsing, if you have a lot of them, and can produce issues like yours.

There is another way to get what you want without using conditionals:
Name your chunk: accordion_script_yes

and try it this way:





[ed. note: Bruno17 last edited this post 11 years, 4 months ago.]

Thanks for the feedback.

About then/else, while I generally agree with the sentiment, none of us follow this in practice. Consider this in PHP:



We don't need an else and few people feel compelled to add one. It's like that in all languages. The documentation for output filters shows a :then being used without a :else. It's documented as being valid syntax so it should work. If the parser actually does go off and try to resolve for a non-existent else, that's a bug that needs to be squashed. If :else is indeed required to avoid this bug, then this needs to be documented. Either way a change "somewhere" is required. The radical parsing of :then without proper syntax around it is yet another issue that I believe should be addressed.

@frogabog - in the above case I always load the jQuery script but I only want to load the jQueryUI script when required. Your astute inquiry on that point is warranted, but in this case it logic is correct.

I guess all I'm looking for here is a confirmation from someone familiar with the core that these things deserve a log in the tracker, and if it's determined later that no changes are required, so be it. Being the noob that I am, I'm not familiar with the general policies here about posting notes against the core.