Editing toolbar goes blank when use external code
Permalink
Hi all- I cannot seem to find the answer I am looking for in the forum, so please forgive if this is a redundant post.
My editing toolbar goes blank under particular conditions, which seem to have external scripts as a common theme.
CASE ONE:
The first time I noticed this was while embedding weather related cancellations/alerts/etc from the site rainedout.com. As per their directions I should embed the following code:
This works if I embed as HTML content, but not as PHP content (which kind of makes sense, right... why i ask... read on!)
Ok the embed works great, but once I save the page the edit button is gone forever, and only for that one page. The only way I can edit is to revert to a prior version, perform all edits, then re embed these scripts. Annoying but workable. There MUST be a better way, and I'm open to suggestions!
CASE TWO:
I tried using the web toolbar from wibiya.com, and adding directly to the footer.php for my theme. This time the embed looks like:
Looks similar, right? also kills my edit toolbar.
I tried using the script from the end of this page:http://www.concrete5.org/community/forums/customizing_c5/cant-edit-...
However the edit button is gone even when I'm not editing the page, so this still would effectively kill editing. I tried a variation with testing for isLoggedIn, however this still does not work. I've tried both HTML and PHP objects, with no joy.
I should note that the wibya toolbar was being prototyped on an admin only page, so the isloggedin only applies to the rainedout.com issue.
OK, I know this is a little long. I suspect the issue is probably obvious to somebody!
For what it's worth, it would be acceptable to have the offending content be completely suppressed if I have edit rights to the page, as there are only ~4 people with these rights. Some variation which checked if i have edit rights to the current page, and if so, do NOT load the offending external scripts would be an acceptably workaround.
However I have no idea how to do this! Thanks in advance for your assistance!
site: orvfc.org
page:http://orvfc.org/fc/schedules/weather/...
My editing toolbar goes blank under particular conditions, which seem to have external scripts as a common theme.
CASE ONE:
The first time I noticed this was while embedding weather related cancellations/alerts/etc from the site rainedout.com. As per their directions I should embed the following code:
<script type="text/javascript" src="https://www.omnilert.net/smartcode/create_user.php?key=2adab7bba848c78ae2a1e2f7e79208b9&aref=17947695374adfc72c8a262"> </script>
This works if I embed as HTML content, but not as PHP content (which kind of makes sense, right... why i ask... read on!)
Ok the embed works great, but once I save the page the edit button is gone forever, and only for that one page. The only way I can edit is to revert to a prior version, perform all edits, then re embed these scripts. Annoying but workable. There MUST be a better way, and I'm open to suggestions!
CASE TWO:
I tried using the web toolbar from wibiya.com, and adding directly to the footer.php for my theme. This time the embed looks like:
<script src="http://cdn.wibiya.com/Toolbars/dir_0491/Toolbar_491788/Loader_491788.js" type="text/javascript"></script>
Looks similar, right? also kills my edit toolbar.
I tried using the script from the end of this page:http://www.concrete5.org/community/forums/customizing_c5/cant-edit-...
However the edit button is gone even when I'm not editing the page, so this still would effectively kill editing. I tried a variation with testing for isLoggedIn, however this still does not work. I've tried both HTML and PHP objects, with no joy.
I should note that the wibya toolbar was being prototyped on an admin only page, so the isloggedin only applies to the rainedout.com issue.
OK, I know this is a little long. I suspect the issue is probably obvious to somebody!
For what it's worth, it would be acceptable to have the offending content be completely suppressed if I have edit rights to the page, as there are only ~4 people with these rights. Some variation which checked if i have edit rights to the current page, and if so, do NOT load the offending external scripts would be an acceptably workaround.
However I have no idea how to do this! Thanks in advance for your assistance!
site: orvfc.org
page:http://orvfc.org/fc/schedules/weather/...
Hi - thanks for your reply - some good thoughts there.
I just tried single quotes: the script still works properly (good) however the edit button is still missing (bad). Not sure what else to try here.
I'm not sure where the php tags on the second example came from since they're not in the original code. Probably leftover from one of my failed attempts to fix this. unfortunately the behavior is the same regardless - removing the php tags and letting the script reside on its own still kills the edit button.
I would be curious if anyone else is running wibiya toolbars with a C5 site, and if so how it works?
unfortunately there is nothing about C5 on the wibiya website. I suspect given the two issues above that this is technically a C5 issue (either a problem with the CMS, or very likely my lack of knowledge on how to properly embed this type of script).
thanks!
I just tried single quotes: the script still works properly (good) however the edit button is still missing (bad). Not sure what else to try here.
I'm not sure where the php tags on the second example came from since they're not in the original code. Probably leftover from one of my failed attempts to fix this. unfortunately the behavior is the same regardless - removing the php tags and letting the script reside on its own still kills the edit button.
I would be curious if anyone else is running wibiya toolbars with a C5 site, and if so how it works?
unfortunately there is nothing about C5 on the wibiya website. I suspect given the two issues above that this is technically a C5 issue (either a problem with the CMS, or very likely my lack of knowledge on how to properly embed this type of script).
thanks!
Ok, I just signed up with wibiya and installed a toolbar with just one button. Just as you say, the toolbar shows up, but the editing functions are broken on the page. Firefox reported the Javascript error '$ is not a function'.
I can see from Firebug that the error is occurring in line 432 of ccm.dialog.js (which is part of C5). That line is like this:
$(document.body).keypress(function(e) {...};
That line normally executes just fine, so it seems to me that there's something in the wibiya javascript that is breaking it. It will take someone who is better at Javascript than me to figure this one out.
The page edit mode of C5 is a really elegant and intuitive user interface, but a bit sensitive to errors in (or caused by) other Javascripts on the page. I've broken it by simply having a script that referred to a non-existent DOM element.
I can see from Firebug that the error is occurring in line 432 of ccm.dialog.js (which is part of C5). That line is like this:
$(document.body).keypress(function(e) {...};
That line normally executes just fine, so it seems to me that there's something in the wibiya javascript that is breaking it. It will take someone who is better at Javascript than me to figure this one out.
The page edit mode of C5 is a really elegant and intuitive user interface, but a bit sensitive to errors in (or caused by) other Javascripts on the page. I've broken it by simply having a script that referred to a non-existent DOM element.
I went back and looked at the instructions for the wibiya script and it just says it should be in the page before the </body> closing tag, so putting it in an HTML block should be OK.
So the only solution I can see is to figure out why the wibiya javascript is breaking the C5 javascript. You can try stepping through the code in Firebug... Sorry I can't be more help.
So the only solution I can see is to figure out why the wibiya javascript is breaking the C5 javascript. You can try stepping through the code in Firebug... Sorry I can't be more help.
Thanks, I appreciate your efforts!
The Wibiya control panel has a setting intended to remove conflicts with other javascripts on a page - ie "check here if you're having javascript conflicts". Unfortunately this also has no effect at all.
Anyone else have any ideas?!?!?!
thanks!
The Wibiya control panel has a setting intended to remove conflicts with other javascripts on a page - ie "check here if you're having javascript conflicts". Unfortunately this also has no effect at all.
Anyone else have any ideas?!?!?!
thanks!
One last thing I noticed that might help someone figure this out...
If you paste the url from the wibiya <script> tag into your browser to see the actual javascript, you should see an if() block at the end that is loading a second version of jQuery into the header.
That may be part of the problem. Here's a post on the subject that is over my head:
http://stackoverflow.com/questions/1005600/programatically-include-...
If you paste the url from the wibiya <script> tag into your browser to see the actual javascript, you should see an if() block at the end that is loading a second version of jQuery into the header.
That may be part of the problem. Here's a post on the subject that is over my head:
http://stackoverflow.com/questions/1005600/programatically-include-...
Good catch- you're possibly/probably right. Have you tried disabling conflicts using wibiya's "troubleshooting" section in their control panel? I wonder if this disables the second jquery request. Whatever this button does it still does not fix my toolbar...
I know even less than you - thanks for your assistance!
I know even less than you - thanks for your assistance!
I think I've finally got it figured out. I was mis-reading the script earlier when I said that jQuery was getting loaded twice.
It turns out the problem was caused by a call to jQuery.noConflict() (this is definitely worth googling if you don't know what it does -- I didn't)
Basically what that call did was to disable jQuery's use of the $() operator. Well, that might be ok if the wibiya script was the last script to execute, but it's not. All the editor stuff runs after the wibiya code.
So to fix the problem here's all you have to do:
1. Enter the url from the wibya script tag into your browser to get the actual script.
2. Copy/Paste it into a temporary text file.
3. Change the line at the top of the script from var wibiya_nc = "true"
to var wibiya_nc = "false"
4. Copy/Paste the modified script into your HTML block.
... or maybe you can even do this through the wibiya control panel...
Let me know if it works for you, ok?
It turns out the problem was caused by a call to jQuery.noConflict() (this is definitely worth googling if you don't know what it does -- I didn't)
Basically what that call did was to disable jQuery's use of the $() operator. Well, that might be ok if the wibiya script was the last script to execute, but it's not. All the editor stuff runs after the wibiya code.
So to fix the problem here's all you have to do:
1. Enter the url from the wibya script tag into your browser to get the actual script.
2. Copy/Paste it into a temporary text file.
3. Change the line at the top of the script from var wibiya_nc = "true"
to var wibiya_nc = "false"
4. Copy/Paste the modified script into your HTML block.
... or maybe you can even do this through the wibiya control panel...
Let me know if it works for you, ok?
Hmm, I just went to the wibiya troubleshooting page, checked the box for Javascript / Framework Conflict as you suggested, then clicked Save. The resulting script was exactly like my first script except with var wibiya_nc = "false" -- so this did exactly what I just figured out the hard way.
I was able to just paste the script tag from the wibiya install page into my HTML block. Nothing is broken.
I don't understand why that didn't work for you... You did click "Save" after checking the box, right?
I was able to just paste the script tag from the wibiya install page into my HTML block. Nothing is broken.
I don't understand why that didn't work for you... You did click "Save" after checking the box, right?
i did hit save
maybe i had something cached in my browser...
I guess I should try again!
maybe i had something cached in my browser...
I guess I should try again!
hey - wow that works! thanks!
now I have to figure out an equivalent for the rainedout.com integration, which is by a different company. I imagine it is a similar issue, but I'm not sure how to resolve.
Similar logic may not work well depending on how the RO is implemented. The list of groups that a parent can subscribe to changes every ~3-4 months and is controlled for the RO end of things. Using a similar method is fine, so long as I dont have to rework this every single time the list is updated!
Do you think this is ultimately an issue with the programming of the external sites, or something that needs to be changed/updated/configured in C5?
thanks!
now I have to figure out an equivalent for the rainedout.com integration, which is by a different company. I imagine it is a similar issue, but I'm not sure how to resolve.
Similar logic may not work well depending on how the RO is implemented. The list of groups that a parent can subscribe to changes every ~3-4 months and is controlled for the RO end of things. Using a similar method is fine, so long as I dont have to rework this every single time the list is updated!
Do you think this is ultimately an issue with the programming of the external sites, or something that needs to be changed/updated/configured in C5?
thanks!
Good question, I'm not sure, maybe all the C5 Javascript could be re-written to replace the $() alias with jQuery(), or maybe there's some other fix.
I guess at this point I'd just be on the lookout for any jQuery.noConflict() calls in any 3rd party script I install.
As far as the rainedout integration, I'll take a look at that script.
I guess at this point I'd just be on the lookout for any jQuery.noConflict() calls in any 3rd party script I install.
As far as the rainedout integration, I'll take a look at that script.
Ok, the rainedout one is easy! Type that url in your browser then click "view source"
You should see a bunch of HTML wrapped in a document.write() function.
Just copy the HTML, but not the document.write() and paste it into your HTML block.
Let me know...
You should see a bunch of HTML wrapped in a document.write() function.
Just copy the HTML, but not the document.write() and paste it into your HTML block.
Let me know...
oops, spoke too soon... it won't let me commit the revision. This time the javascript error is "$(ccm_SelectedDomID) is null". I'll have to look at the script more closely...
It's adding in the prototype library and some associated effects that are breaking the C5 javascript, but I don't think you really any of that stuff.
Try just deleting the four script tags and pasting in the rest of the html. I think the form should still work...
lmk...
Try just deleting the four script tags and pasting in the rest of the html. I think the form should still work...
lmk...
it looks like im unlikely to get help from the other end:
"Unfortunately, there is no Smartcode that does not use the document.write procedure, as that is one of the core functions in the script. Our best suggestion for a workaround is to pop out to a plain HTML document (outside of your CMS), as that would avoid the conflict altogether.
-RainedOut Support"
any good way to create a html popup? hmmm have not yet tried this with C5
"Unfortunately, there is no Smartcode that does not use the document.write procedure, as that is one of the core functions in the script. Our best suggestion for a workaround is to pop out to a plain HTML document (outside of your CMS), as that would avoid the conflict altogether.
-RainedOut Support"
any good way to create a html popup? hmmm have not yet tried this with C5
I think they mean basically a single page. That does make perfect sense. Since it wouldn't have the standard header_required, there wouldn't be any jQuery for it to conflict with.
Here's all you have to do.
1. Create a new file:
siteroot/single_pages/myform.php
2. Add contents something like this
3. In the dashboard go to pages and themes, then click the Single Pages tab, scroll down to the bottom, type in myform and click Add.
It worked for me... Also, just thought I'd mention their Javascript is broken -- but it won't matter, since you won't be editing the page through the C5 interface anyway.
Here's all you have to do.
1. Create a new file:
siteroot/single_pages/myform.php
2. Add contents something like this
<html> <head> <script> document.write(' ... '); </script> </head> <body> </body> </html>
3. In the dashboard go to pages and themes, then click the Single Pages tab, scroll down to the bottom, type in myform and click Add.
It worked for me... Also, just thought I'd mention their Javascript is broken -- but it won't matter, since you won't be editing the page through the C5 interface anyway.
thanks for following up!
that might work EXCEPT that the list of signups (2010 spring, etc etc) changes every four months or so, and I dont want to have to update this page each time.
This does provide a possible solution - with this info I may be able to get the people at rainedout to provide an alternate link without the offending "document write" code.
I'll let you know how that works. Thanks again!
that might work EXCEPT that the list of signups (2010 spring, etc etc) changes every four months or so, and I dont want to have to update this page each time.
This does provide a possible solution - with this info I may be able to get the people at rainedout to provide an alternate link without the offending "document write" code.
I'll let you know how that works. Thanks again!
I don't think the document.write() is necessarily a big problem -- it could probably be handled by putting their script in a template instead of in a block. The template could have a div or something and you could use a bit of jQuery to stick the form in there...
But I think if you talk to them, you might want to ask if it's possible to get the form without the four Prototype script tags. I can't see where the form is actually using any Javascript at all...
But I think if you talk to them, you might want to ask if it's possible to get the form without the four Prototype script tags. I can't see where the form is actually using any Javascript at all...
I don't really see why the script tag needs to be wrapped in <?php ?> tags. I think you could remove them and just paste the script into an HTML block.
Hope that helps!