Google Custom Search and IPS JS conflicts

[Flitterkill]

Could post as a bug, could post in general peer to peer support, ehhh... This is weird enough.

Google Custom Searches let you embed a Google search field into a webpage. It is more or less a self-contained chunk of Javascript that just sticks in a form field and links it to your custom settings for the search at Google HQ or wherever.

If you embed this custom search in a template, and we'll use global for the hell of it ( stick it in a div and whatever...), it works. It doesn't not work.

It also, when you enter the search form field and when you exit the form field, spams the console with errors. I suspect there is an IPS js controller that grabs onto all text entry fields and fiddles with them. An active/focus thing.

VM56546:1 Uncaught SyntaxError: Unexpected token s in JSON at position 0
n.parseJSON @ root_library.js.98d2a74….js?v=93ea2ed0a7:2
_previewMessage @ root_framework.js.c665e76….js?v=93ea2ed0a7:206
n.event.dispatch @ root_library.js.98d2a74….js?v=93ea2ed0a7:2
r.handle @ root_library.js.98d2a74….js?v=93ea2ed0a7:2

It is probably one of those wants quote wrapped but not getting quote wrapped things. Root library at line 4769 (prettyfied) for the first hit. My brain melted a little looking at the alphabet soup of one letter vars which is another reason why I'm asking here.

It is the same error every time; twice on entry, thrice on exit.

Not a bug as it is an external component... yet if there are any other external components with form fields and the IPS js is latching on to all of them...

On a lark I did wrap the code in the IPS recommended js wrapper and the search still worked, and also still spammed the console. Tried changing some vars around in the code (single letters to non-single letters, other single letters), etc.) and still the same; which is why I think it isn't the Google Custom Search itself but the fact it is what amounts to a foreign form element i.e. the text entry field.

So the dev question/s are:

Should we/I just forget about it as the errors are ultimately meaningless (doubly so for how often a field such as this will be actually utilized).

Am I right that this is IPS js latching onto the text entry form element?

Is there an easy way to escape out of the IPS js for this particular field?

 

[CodingJungle]

I input the code for google custom search in my globalTemplate and a pages page, and I am not seeing any errors. it is working as intended. So it is more than likely not a conflict with IPS javascript code.

[Flitterkill]

Just reconfirmed. Default template. 4.1.12.1 pasted into the footer.

This is with designers mode on. Wonder if I turn it off?

[Flitterkill]

Well that's going to be part of it. The inbound theme parser wants nothing to do with this Google Custom Search code at all.

You can paste it into a theme while in designers mode and it will work and you can obviously edit a theme in the ACP to splash in the code and that will work fine too.

Inserting it into a template while in designers mode AND then turn off designers mode and sync the changes and the parser works for some values of works.

Pasting it in the footer of the default theme and syncing changes back and the code is mysteriously missing. Any other themes with the code in them result in the site tanking on the front end when you try to use them. Also, any themes that get parsed after a theme containing the Google Custom Search also get fried.

Moving all this to a plugin would help on the theme sync end I imagine and if you pasted the code into the template directly from the ACP editors then that solves part of the problem.

EDIT: I'll hit this again in the morning but it seems the theme parser coming out of designers mode is choking on most/all jQuery/etc. calls stuck into the template (global at least). The ones I have are a couple lines and really routine stuff but removing them gets the parser moving again. Will see how deep the rabbit hole goes tomorrow.

[Flitterkill]

Bug report submitted on designers mode parser.

The json errors on the text field are still valid though, at least while in designers mode and am still very curious as to what the cause is.

 

[Colonel_mortis]

The JSON errors are as a result of

 

[Marcher Technologies]

17 hours ago, Flitterkill said:

EDIT: I'll hit this again in the morning but it seems the theme parser coming out of designers mode is choking on most/all jQuery/etc. calls stuck into the template (global at least). The ones I have are a couple lines and really routine stuff but removing them gets the parser moving again. Will see how deep the rabbit hole goes tomorrow.

inline javascript is explicitly disallowed in most templates.... try using includeJs if you are going to slap raw js into a template.

Edit: my bad, IN_DEV only does that. Never mind.

[Flitterkill]

I've wondered about this for some time. There is a stupid level of convenience and time saving just splashing in a couple lines of jQuery on the bottom of the global template. If your work bubbles up to the level of a controller you do have to pretty much stick it elsewhere (plugins actually work really well for this - just dump the JavaScript there with the correct controller syntax and it works spectacularly well, no code hooks or anything else required).

Lord knows in most of the 4.0 sites I've looked at (or done casual support for) most if not all of them have raw js/query plastered in the bottom.  I imagine most of it is homegrown and dropped in post-theme install and is naturally cut/paste after all theme updates as well.

Still, this all blends into the problem of where does a theme end and a plugin/app begin. I'll miss the convenience but I suspect I'll have to dump everything into a separate plugin - for full-on controllers and pasting in simple jQuery into templates. 

Otherwise, take a look at the bug report I made. The parser actually does bring the jQuery over and doesn't "choke" on it. But something gets way messed up/flagged somewhere. Using the re-synced theme crashes Apache of all things. 

And cheers Colonel for the pointer - glad it is a known problem on the json stuff.

[CodingJungle]

41 minutes ago, Flitterkill said:

I've wondered about this for some time. There is a stupid level of convenience and time saving just splashing in a couple lines of jQuery on the bottom of the global template. If your work bubbles up to the level of a controller you do have to pretty much stick it elsewhere (plugins actually work really well for this - just dump the JavaScript there with the correct controller syntax and it works spectacularly well, no code hooks or anything else required).

Lord knows in most of the 4.0 sites I've looked at (or done casual support for) most if not all of them have raw js/query plastered in the bottom.  I imagine most of it is homegrown and dropped in post-theme install and is naturally cut/paste after all theme updates as well.

Still, this all blends into the problem of where does a theme end and a plugin/app begin. I'll miss the convenience but I suspect I'll have to dump everything into a separate plugin - for full-on controllers and pasting in simple jQuery into templates. 

Otherwise, take a look at the bug report I made. The parser actually does bring the jQuery over and doesn't "choke" on it. But something gets way messed up/flagged somewhere. Using the re-synced theme crashes Apache of all things. 

And cheers Colonel for the pointer - glad it is a known problem on the json stuff.

IMHO if you need to add any js, then it should be done via a plugin, same with any HTML edits. Sure might not be easy to do these things, but look at the "registration" bug that plagued the 4.1.8 release, any themes made before 4.1.8.1 that had altered HTML, aren't "upgraded". So the bug that was found in 4.1.8, fixed in 4.1.8.1 that would create "partial" registrations would still remain in that theme (had it happen to two clients), one of them had over 900k "partials" created. All cause their theme had template edits and the templates weren't upgraded by the upgrader (nor were there errors thrown about templates being out of date).

also to touch upon what marcher was saying, afaik, it only throws an exception about inline js if you are in_dev, not in DM. Seems silly to me to throw a fit on developers, but not on skinners who are more likely to abuse the use of inline js. since we are on the subject, or not in the ACP editor either. Why are developers held to that standard?