Any time I paste iframe embed code from Vimeo into an item field, the fullscreen part of the code is stripped out - even before saving the changes to the item record.
I check the ‘Use HTML’ box, click HTML in the input field’s toolbar, and paste the iframe embed code. After I click the ‘Update’ button, I can open it immediately to view the embed code, and all the ‘fullscreen’ code (webkitallowfullscreen mozallowfullscreen allowfullscreen) is gone. In the public view of the saved item, the video displays normally, but the fullscreen icon just isn’t there.
I have tried editing the HTML Filtering section of the security settings to include the elements and attributes while using the filtering, and have also tried unchecking the filtering altogether, but neither of those makes any difference.
I have successfully embedded iframe code from another 3rd party, and this allows a fullscreen capability, but that isn’t part of the embed code, so is not the best comparison.
I can paste the same Vimeo embed code into a WordPress site, and the fullscreen option is available.
Thanks in advance for any assistance!
This sounds like it’s probably a shortcoming with the WYSIWYG editor we’re using (since the HTML Filtering settings didn’t have an effect).
Here’s something you could try: for each of those fullscreen attributes, add an ="true" on the end (so, webkitallowfullscreen="true" and so on). Obviously you don’t want to have to edit every embed code you use, but seeing if that helps will give us some information, and give you at least a workaround if it works.
Well, that didn’t work. Below is the embed code for one of the videos, after adding =“true” .
NOTE: The < /iframe> doesn’t really have that space, but I can’t remember how to format it here to post the code correctly.
<iframe
src="https://player.vimeo.com/video/169728646?byline=0&portrait=0"
width="640" height="360" frameborder="0"
webkitallowfullscreen="true"
mozallowfullscreen="true"
allowfullscreen="true"></iframe>
If you would like to use this embed code for testing, let me know. Right now, we have privacy settings so that it can’t be embedded in domains other than our own, but I would be happy to remove those restrictions for testing purposes.
I wouldn’t mind editing the embed code for each video - we don’t have that many - so if there’s anything else I can try, I’ll be happy to give it a go!
Just FYI - I found that I need to add some character (I use a period) in an input field at the end of the embed code. If I forget, the video doesn’t show up at all. It’s not elegant, but it gets the job done.
I don’t think the example video you gave is authorized for display generally: it just results in a Vimeo error about permissions.
Regardless, this problem seems to lie in our settings for TinyMCE. You can change these in admin/themes/default/javascripts/globals.js (the initParams in the Omeka.wysiwyg function). One option that I’ve confirmed to work is to just turn off TinyMCE’s element filtering entirely, by adding verify_html: false to that list.
I tried adding that line:
*/
Omeka.wysiwyg = function (params) {
// Default parameters
initParams = {
convert_urls: false,
verify_html: false,
mode: "textareas", // All textareas
but nothing changed. Putting that line in a different area of the same section hid the TinyMCE features altogether, as well as the Add Input and Remove buttons.
Is there a specific location for that line?
What you have there looks right.
To make sure we’re just looking at TinyMCE here, do you have the HTML filtering disabled in Settings -> Security? I know you mentioned you’d tried that at some point, but having it disabled now would be helpful in making sure things are narrowed down to just the TinyMCE part.
I was able to make that change myself, so I’m pretty sure it should work.
Yes, the Settings > Security > Enable HTML filtering box is still unchecked.
Maybe you just need to reload or clear your browser cache.
I made the change here again just to confirm it worked, and it works fine.
Okay, to make sure I’m perfectly clear on this, should the edited globals.js file go in the root at admin/themes/default/javascripts/ or should I include that in my theme directory?
I have been testing it in the root, but if I do get it sorted out, I will need to make sure I include it in upgrades.
Thank you!
It should be where it is by default: in admin/themes/default/javascripts.
We’re mulling over making this change in the core itself for a future version, to avoid this kind of problem where the various filtering processes overlap in their coverage.
I’m encountering a very similar issue, except with <pre> tags. I’ve disabled HTML filtering through the security settings, set verify_html to false in initParams in admin/themes/default/javascripts/globals.js, and even disabled the media plugin for tinyMCE, since that’s given me trouble in the past. I’m still getting my <pre> tags filtered out when entering HTML into Item metadata or Exhibit blocks.
Any ideas would be much appreciated.
One obvious thing to make sure of first is that you’re clearing/disabling cache when you change globals.js. As a static file, it (along with most Omeka javascript) can get pretty aggressively cached and complicate the process of figuring things out if you’re not accounting for it.
verify_html to false and disabled filtering in Security should be letting you put anything at all that you want in there.
I’ve been doing a cmd+shift+R to force refresh, but I wanted to make sure that the setting was being applied, so I tried checking in the tinyMCE javascript object. tinyMCE.settings.verify_html was indeed set to false, but I noticed that tinyMCE.settings.validate was set to true, so I flipped it. Setting tinyMCE.settings.validate to false seems to have done the trick, as my <pre> tags are sticking around now. Thanks!
Since I wanted to avoid hacking core for my fix, I made a plugin to change TinyMCE settings: https://github.com/jaguillette/TinyMceMod. It sets verify_html and validate to false, and also removes the media plugin, since that has also removed some tags for me in the past.
1 Like
The curious thing here is that TinyMCE doesn’t document the existence of the “validate” setting at all. I can see that it exists by looking at the source code, but I don’t see it mentioned anywhere in the documentation.
Anecdotally, verify_html was enough for me, but it looks like I’ll have to look a little more closely.
The other odd thing about this is that <pre> should be allowed even with all the default validation settings on. It’s even in the format dropdown list on the editor.
I’m testing some more, and it looks like it’s not just the <pre> tags themselves, but the fact that they’re enclosing <div>s that TinyMCE doesn’t like, which would explain why turning off validation keeps them around. <pre> tags around text are just fine.
Now I just have to make sure that the setting changes in my plugin are being applied to editors that already exist on pageload…
jaguillette, this sounds like a great solution! However, when I tried installing your plugin, I get the “This is not a valid plugin” error. Can you help?
Thank you!
Did you download and unzip from GitHub? Github adds “-master” to the end of the folder name where the plugin is, and that might cause that error. The plugin folder structure should look like this screenshot:
Yes, I did download from GitHub, and renamed the folder to remove “-master”, then uploaded via FTP. Everything was there, but it didn’t install correctly.
I just deleted it and re-uploaded it again, and it installed just fine this time!
I will test it with Vimeo embed code ASAP and let you know how it works. Thanks!