Change in EE controller (ee.php) in 2.2.1 will probably break some addons using json (incorrectly?)

Clive,

I want to straighten up a few points for you:

you did _not_ explain this to me, nor did anyone, over the now nine months of continuous refusal to clearly deal with the problems this behaviour has caused _many_ very competent and otherwise well-intentioned developers. Let me quote you:

This is still defaulted to true if only because that’s the way it’s always been. Changing it would affect all legacy sites that relied on that behavior whereas the ability to change it is new.

This _explains_ nothing. It just comes across as the kind of blunt, unhearing insistence that is at the root of considerable displeasure towards EllisLab, which was present on Twitter once again as recently as just yesterday.

In the above quote, I thought I had explained why it wasn’t changing for the moment: because legacy sites depended on that behavior. I apologize if my explanation wasn’t clear enough.

Legacy sites depending on this debug behaviour to do an invisible if statement is an abuse of facility, isn’t it?

No, it’s demonstrated within the Agile Record templates, so it’s certainly not abusing the system in any way.

Causing _new_ and _upgrade_ sites and their developers great invisible difficulty is hardly something you should be wishing to do, even if it’s some ‘high-flying’ legacy customer you’re protecting. It seems very clear that the right thing is to _assure_ that upgraders in particular are not brought to a dead halt with a mystery Javascript killer.

I agree with you here and I’m not sure why it happened. To me, the code that looks like an embed tag within the minified jQuery should have always been a problem. When was the last time you could load the minified version of jQuery without a problem? I just tested 2.1.3 and had the same problem Bjorn detailed above.

I think you still have the ability in EE to make program-driven change to the actual config file. In that case, my recommendation is to force debug 0 to become debug 1 at one clean time, during the upgrade/update/installation on every new release of EE, so it’s sure to take whenever someone upgrades. With this, since you’ve explained the need, still leave the old curly bracketed apparent-var zap code in.

We do have this ability, but I don’t believe we should do this. Some sites depend on debug being set to 0, as much as we might not like it. Changing their debug setting on them could create a slew of errors where before their site looked like it was doing just fine. We want people to improve, but if there weren’t errors before the upgrade, they’ll certainly blame the errors on the upgrade.

This protects all who set debug 0 just as a catch-all, as so many thoughtful developers will have after finishing a clean site. Upgrades will no longer run into invisible sharks eating their Javascript/JSON/etc…

I see your point about cleaning up and hiding errors, but debug 1 still only shows errors to Super Admins. If you don’t want the client admins to see those same errors, you can always clone the Super Admin group and use that for your client’s admin accounts.

Then you tell what you have done quite publicly, as I early suggested, and if you know as you seem to who some of these false-if sites are, you tell them directly. You allow them to set debug 0 in the hidden config again after the upgrade, to return the legacy behaviour as often as they want to.

These changes aren’t impossible, but like you point out, need to be done publicly and with a good amount of notice. That means we need at least two releases before we can make a change that will affect behavior that much and we need to do it gradually so Super Admins can see notices about deprecated behavior. So, while this is possible and might happen, it might not happen for a while. This is something I’ve mentioned before: while we aren’t doing it right away, it doesn’t mean we won’t be doing it.

All of that being said, this is my last response about this since I’ve said the same thing several times. We’re planning on making changes that should fix some of the Javascript issues including: - Disabling the removal of unparsed tags that look like ExpressionEngine template code - The option to disable template parsing on all templates - General cleanup of the template parser as time allows

Also, I want to apologize to Bjorn since this has weaved it’s way off topic. Clive, if you still have issues, please open up a new thread. Wes

if(is_https)
{
    google.load('search', '1', {"language" : "en"});
}

to this:

if(!is_https)
{
    var langObj = new Object();
    langObj.language = 'en';
    google.load('search', '1', langObj);
}

.. because EE was eating the {"language":"en"} .. that might have been the other issue though - but anyway this was something that seemed to change from the previous version as it worked before the upgrade.

I just tried this out in 2.1.3, 2.2.2, and the development version, and it didn’t seem to eat the language object ({"language" : "en"}), was this a problem with a different version? Is it still a problem for you?

Bjørn, just to let you know as Wes does, that I’ve transferred the larger problem discussion to others in Ellis.

As far as them issue Wes is mentioning with you now, that does look like exactly the long-term debug 0-generated problem. The contents of bracket-enclosed statements would disappear, in the way you noted at the top of this forum stream.

Between the two of you, maybe you can work out whether config was actually setting debug to zero for the current experience.

If it is, and depending on the version you are on, you may be able to use the workaround remove_unparsed_vars variable Wes is noting here, setting it to false in the usual way of the config file: https://support.ellislab.com/bugs/detail/16114/#12281.

Or, if you’re on an earlier version without this feature, you might consider just patching the EE source on the one line involved, which accomplishes the same thing, from January per http://ellislab.com/forums/viewreply/866751/.

Good fortune, both you guys, and I hope your situation is stable soon, Bjørn. I know and you’ve evidenced again here that you’re one of the best people to work with on an EE issue; should help the team.

Regards, Clive

Wes, something stuck in my unconscious where you seem to be saying that the Agile demo is using fields that might not be present depending on channel source, coming back up as I was going to sleep last night.

After some testing this morning on 2.2.1, I am wondering what you mean by that statement.

Are you saying that the Agile demo depends on being run with debug 0, so that the Javacript-zapping code needs to be enabled?

This I have at least not observed. Interested in what you actually were saying.

Regards, Clive

I guess the ultimate solution would be for the EE template parser not to parse non-EE tags. The {embed} in this specific case almost looks like an EE tag, true - but it’s missing the = and also contain other chars which would not be found in a valid embed tag. So it shouldn’t be a “hit” for the regexp performing this specific task.

I’ll see what I can do here, as this does make the most sense.

Bjorn, taking a fresh look at this reminded me, that embed variables look like this:

{embed:title}

Which still need to exist and would match this bit of code in jQuery’s minified version:

{embed:!0,object:"clsid:D27CDB6E-AE6D-11cf-96B8-444553540000",applet:!0}

So, I’m not sure how much we can do in that case, the best option might be to have static javascript templates.

Wes

Bjørn, Wes is right on the embed variables, but I think they can be parsed more intelligently so as to not trip up jQuery’s syntax in that specific case. Can you confirm for me that your only issues that you are having are when either of the two following are at play?

• Using jQuery minified in a template
• Debug is set to 0

Bjørn, please check the email associated with your ExpressionEngine account; I’ve sent you a potential fix.

Hi Derek, replied to your email. Again sorry for the late reply.

Anywyay, I did a test with the minified jquery and indeed your fixes does fix that one. I’m still concerned there might be other affected JS though (didn’t look at your fix but it is specifically for {embed} right?) - so wish I could do a more thorough test but my better half has put me on a strict diet when it comes to time in front of my laptop until monday.

There are primarily two changes made in the files I sent:

• protected against removing jQuery’s embed: code when the template parser removes unparsed embed variables
• reversed the logic of $remove_unparsed_vars so that you have to enable this rather than disable it. Particularly with the increased use of both jQuery and JSON, far more are impacted negatively by the original default behavior than are benefitting.

Thanks, and I hope it thoroughly solves your issues, I’ll work with other users for some final tweaks.

* reversed the logic of $remove_unparsed_vars so that you have to enable this rather than disable it. Particularly with the increased use of both jQuery and JSON, far more are impacted negatively by the original default behavior than are benefitting.

Great, I think this is the best solution. Most likely this will fix the issues I’ve had with JavaScript code being stripped.