406 Not Acceptable when adding YouTube video in admin on GoDaddy

lhungil:

Maybe just convert the field to hold the youtube video ID (or just the URL without the protocol), and in the template reconstruct the URL / iframe (or use oembed)?

I'd like to do this, just didn't know how or where to start.

pricediscrimination:

I'd like to do this, just didn't know how or where to start.
Fist thing to check: does entering just the URL trigger the mod_security block? If not, one can just store the URL in the database field and in the Zen Cart template (for your product type - probably product_general) add the iframe portion needed for youtube (or use oembed to dynamically generate the video display code - which works with most streaming video services not just youtube).

If mod_security does not allow the URL, you could store just the youtube video IDs (I do this for a non Zen Cart site - for a different reason) and then add the youtube URL portion and call oembed (or just generate the iframe + iframe URL yourself; I seem to recall there being a pattern)...

pricediscrimination:

Hi again, RodG. Just tested the input field with the exact same data/code that I am currently using but without the 'iframe' part. Successfully goes to the preview screen. Tried again with iframe in there and back to the 406.

Can you post copies of the code that you are using. Both the original, and the one with the iframe part removed.

pricediscrimination:

The product description field can write the iframe code to the database but not the custom input field.

As previously stated, this is why I'm not 100% convinced that it is the iframe part that is causing the problem, and I'd like to verify that we are both on the same page in regards to what you have removed from the original.

Also, as an adjunct to lhungil's comments that there are other methods that you can use, it may eventually come to that, but it still depends on exactly it is that is triggering the mod_sec rule. It would be 'silly' to go this route if a solution can be found with a minor tweak of your input data.

HOWEVER as I said in my opening reply, storing iframes and iframe data in the database is quite unusual anyway, but you did give a somewhat valid reason why you have taken this approach which will be somewhat negated with the proposed method (which again, may turn out to be unavoidable anyway).

Theoretically, if the same input/code works with the product description it should work with your custom field.

Cheers
RodG

RodG:

Can you post copies of the code that you are using. Both the original, and the one with the iframe part removed.

For example:

<iframe width="853" height="480" src="//www.youtube.com/embed/qpgTC9MDx1o" frameborder="0" allowfullscreen></iframe>

This is just the regular YouTube embed code.

Anything removed from this code just shows up as text. It's only the "ifram" that is tripping it up. I can do:

<width="853" height="480" src="//www.youtube.com/embed/qpgTC9MDx1o" frameborder="0" allowfullscreen></>

or any other combination and the text will appear where the iframe video should show up.

RodG:

As previously stated, this is why I'm not 100% convinced that it is the iframe part that is causing the problem, and I'd like to verify that we are both on the same page in regards to what you have removed from the original.

Also, as an adjunct to lhungil's comments that there are other methods that you can use, it may eventually come to that, but it still depends on exactly it is that is triggering the mod_sec rule. It would be 'silly' to go this route if a solution can be found with a minor tweak of your input data.

HOWEVER as I said in my opening reply, storing iframes and iframe data in the database is quite unusual anyway, but you did give a somewhat valid reason why you have taken this approach which will be somewhat negated with the proposed method (which again, may turn out to be unavoidable anyway).

Theoretically, if the same input/code works with the product description it should work with your custom field.

Cheers
RodG

The proposed method is quite nice actually, it allows for far more customization via CSS etc. This is how oembed works on Wordpress themes. You just the URL to the video and it displays it. However, as you said this wouldn't solve the problem as to why the iframe is allowed in the product description field and not in the custom field.

pricediscrimination:

For example:

Just for clarification, when I asked you to provide the exact code, that is what I meant. I don't know if your example is the same as the exact code or not.

Anyway.......

<iframe width="853" height="480" src="//www.youtube.com/embed/qpgTC9MDx1o" frameborder="0" allowfullscreen></iframe>

I have two more tests that I'd like you to make.

The first is to try this code:

<abcdef width="853" height="480" src="//www.youtube.com/embed/qpgTC9MDx1o" frameborder="0" allowfullscreen></abcdef>

IOW, change the two 'iframe's to 'abcdef', and let me know if the mod_security us still triggered. (note: this code won't actually function. All I/we are testing for is the triggering of the mod security rule)

pricediscrimination:

Anything removed from this code just shows up as text. It's only the "iframe" that is tripping it up. I can do:

<width="853" height="480" src="//www.youtube.com/embed/qpgTC9MDx1o" frameborder="0" allowfullscreen></>

It is *still* not possible to come to this conclusion with 100% certainty, because not only have you removed the possible iframe trigger, but you have *also* made the length of the input data 12 characters shorter (which is why I'm asking you to replace the iframe text with an equal number of other characters). 

> **pricediscrimination:**
>
> The proposed method is quite nice actually, 

It is also the way this kind of thing is generally done (which I why I was questioning your method from the very outset).  

> **pricediscrimination:**
>
> However, as you said this wouldn't solve the problem as to why the iframe is allowed in the product description field and not in the custom field.

Correct.  Furthermore I/we are now 'this close' (holding finger and thumb together) to determining with 100% certainty whether it really is the 'iframe' causing the error or not.  

If the replacement of 'iframe' with 'abcdef' *doesn't* trigger the error, I think I've identified the cause of the problem (and the fix will be quite easy).  
   
If the replacement of 'iframe' with 'abcdef' *does* trigger the error, the cause will have also been identified, but the fix is going to take a little more work. 

Cheer
RodG

RodG:

Just for clarification, when I asked you to provide the exact code, that is what I meant. I don't know if your example is the same as the exact code or not.

Anyway.......

<iframe width="853" height="480" src="//www.youtube.com/embed/qpgTC9MDx1o" frameborder="0" allowfullscreen></iframe> ``` > > I have two more tests that I'd like you to make. > > The first is to try this code: > ``` <abcdef width="853" height="480" src="//www.youtube.com/embed/qpgTC9MDx1o" frameborder="0" allowfullscreen></abcdef> ``` > > IOW, change the two 'iframe's to 'abcdef', and let me know if the mod_security us still triggered. (note: this code won't actually function. All I/we are testing for is the triggering of the mod security rule) > > > > > It is *still* not possible to come to this conclusion with 100% certainty, because not only have you removed the possible iframe trigger, but you have *also* made the length of the input data 12 characters shorter (which is why I'm asking you to replace the iframe text with an equal number of other characters). > > > > It is also the way this kind of thing is generally done (which I why I was questioning your method from the very outset). > > > > Correct. Furthermore I/we are now 'this close' (holding finger and thumb together) to determining with 100% certainty whether it really is the 'iframe' causing the error or not. > > If the replacement of 'iframe' with 'abcdef' *doesn't* trigger the error, I think I've identified the cause of the problem (and the fix will be quite easy). > > If the replacement of 'iframe' with 'abcdef' *does* trigger the error, the cause will have also been identified, but the fix is going to take a little more work. > > Cheer > RodG

Hi RodG! Yes that is the exact code from YouTube. Can be found on any YouTube and is used by the millions everyday by YouTubers.

Tried the abcdef and proceeds to preview and saves the product listing as it should. This is also evident when using YouTube's "old" embed code which used to be an object based code. They have since began supporting iframe, which apparently is the culprit with this custom field.

pricediscrimination:

Hi RodG! Yes that is the exact code from YouTube. Can be found on any YouTube and is used by the millions everyday by YouTubers.

Shame on them. Thier code is technically incorrect.

src="//www.youtube.com/embed/whatever" is missing the protocol specifier. The correct syntax here would be:
src="http://www.youtube.com/embed/whatever"

pricediscrimination:

Tried the abcdef and proceeds to preview and saves the product listing as it should.

Tadaaa! We have now definitively shown that it is the iframe that is triggering the mod_security rule.

We can now move forward......

pricediscrimination:

This is also evident when using YouTube's "old" embed code which used to be an object based code. They have since began supporting iframe

Shame on them. While the rest of the world has been slowly moving away from iframes towards the more modern embed and/or object methods they are moving towards it. :(

pricediscrimination:

, which apparently is the culprit with this custom field.

This is no longer an 'apparently' situation. It is a fact that we have just proven.

Oh well.... all is not lost yet.

Please try entering:

<object width="853" height="480" data="http://www.youtube.com/v/qpgTC9MDx1o"> </object>

And/or

<embed width="853" height="480" src="http://www.youtube.com/v/qpgTC9MDx1o">

Cheers
RodG

RodG:

Please try entering:

<object width="853" height="480" data="http://www.youtube.com/v/qpgTC9MDx1o"> </object>

> 
> And/or 
> 
> ```
<embed width="853" height="480" src="http://www.youtube.com/v/qpgTC9MDx1o">

Cheers
RodG

The object code works as it should.
The embed code works too.

BTW, here is the youtube screenshot for laughs

Tried the iframe with the "http:" for more laughs but no go.

pricediscrimination:

The object code works as it should.
The embed code works too.

Sweet. So problem solved eh? It appears that GoDaddy are only stopping the iframes.

I'm still at bit a loss why it would work in the product descriptions though - Perhaps its because it is embedded deep within another $_POST variable rather than being a variable unto itself. It's about the only thing that would be different (and would certainly explain things)

pricediscrimination:

BTW, here is the youtube screenshot for laughs

What can I say, other than the simple fact that the larger the business the more likely they are to ignore industry standards and do things their way. I'm kinda piffed at Google these days for this kind of practice.

pricediscrimination:

Tried the iframe with the "http:" for more laughs but no go.

I didn't think that this would take care of your problem, but I'll wager that there are some browsers that will have a hard time and/or produce an error when they encounter a URL without the "http:" specifier. Such browsers would be quite rare these days as most will check for this and automatically add it if it isn't found.

It's very poor practice though to have to rely on the browsers to make it correct though. I can't help but wonder if youtube have gotten rid of their experienced developers and replaced them with newbies that don't understand the history of why iframes and incorrectly specified URL's pose a security risk. <huge sigh>

This doesn't bode well for the future. Developers for large corporations are making the same mistakes that us 'oldies' identified and warned people about decades ago.

Anyway, unless you have any more questions I think I'm done here. However you may still want to consider lhungil's suggestion
"you could store just the youtube video IDs and then add the youtube URL portion and call oembed (or just generate the iframe + iframe URL yourself". I have several reasons for saying this:

1. It is basically the 'right' way to do it
   2) It'll give you more control over the display/output (Can be controlled with .CSS)
   3) It takes a bit of 'trickery' to insert/retrieve the quotes and apostrophes from a database
2. It is more efficient (because the DB trickery isn't needed).
3. It is less susceptible to bad things happening from SQL injections. (IOW, less hackable)
4. Sooner or later GoDaddy may decide to blacklist the embed/object methods as well as iframes

... and those are just off the top of my head.

Cheers
RodG

RodG:

Sweet. So problem solved eh?

I wish but it isn't yet. Before moving to C-PAnel hosting (the onset of this iframe debacle) there were already hundreds of products listed with the iframe code. Now those are not editable unless the videos are removed and code readded to the database manually (or using the old object code).

Also, I'd like to keep it all the same ie: hundreds with iframe, keep it all iframe especially since that seems to be what youtube is supporting most moving forward.

I could try the idea of just adding the URL as a variable and making the code use that variable within a set iframe code but frankly I don't even know where to start. I was able to get the custom field working with posts from here, but I don't know how to make the input of that field into a variable used by a code to display the videos. Also this would mean going back and redoing all of the existing iframes...

pricediscrimination:

I wish but it isn't yet. Before moving to C-PAnel hosting (the onset of this iframe debacle) there were already hundreds of products listed with the iframe code. Now those are not editable unless the videos are removed and code readded to the database manually (or using the old object code).

Are you familiar with phpmyadmin at all? It wouldn't be difficult to do a SQL search/replace to update all the iframes to objects or embeds.

pricediscrimination:

Also, I'd like to keep it all the same ie: hundreds with iframe,

The thing is, since GoDaddy are disallowing the iframe in the custom $_POST variable you really don't have much choice in the matter. It has nothing to do with cPanel. It is something that Godaddy has explicitly disallowed, and to be perfectly honest I don't dissaprove of this particular restriction. It is possibly one of the few good things they've done.

pricediscrimination:

keep it all iframe especially since that seems to be what youtube is supporting most moving forward.

Did you not read all of my previous message?... Youtube aren't moving forward to using iframes, they are taking a step backwards.

There is no need for you to follow their idiocy. If you want to move forward rather than backwards you should ignore their code examples and do things the more modern way.

pricediscrimination:

I could try the idea of just adding the URL as a variable

Or better yet... just the video IDs (as per lhungil's suggestion/method)

pricediscrimination:

and making the code use that variable within a set iframe code

Please don't. You aren't doing yourself any favours at all by using iframes, even if that is what youtube provide for their cut n paste code.

Ask yourself.... Why have godaddy placed a restriction on the iframe, but not the other methods? Who has it 'wrong' GoDaddy or Youtube?

Although not something you'll hear every day, but in this case its Godaddy that are doing it 'right' and youtube that have got it 'wrong'.

pricediscrimination:

but frankly I don't even know where to start.

This is a little tough because you have 3 options available to you.

1. Find another host that isn't as 'protective' as Godaddy so you can carry on as you have been.
2. Using phpmyadmin (or similar SQL tool) and globally replace all of the iframes with the object or embed methods
3. Using phpmyadmin and globally deleting everything except the VideoID's and adding the iframe/object/embed into the relevant places in your template file(s).

pricediscrimination:

I was able to get the custom field working with posts from here, but I don't know how to make the input of that field into a variable used by a code to display the videos. Also this would mean going back and redoing all of the existing iframes...

Other than changing hosts, you have no other option but to redo all of the existing iframes (using options #2 or #3) above.

Although your best solution (IMO) would be option#3 I think your easiest solution (assuming you wish to stay with GD) would be option#2

Cheers
RodG

PS. I've just been doing a little research on the differences between the iframe/embed/object methods and it appears that my knowledge is a little outdated and the standardised HTML5 iframe method no longer has many of the shortcomings of the earlier implementations.

Alas, this doesn't help with your problem though because you still can't use them due to GD's mod_security rules.

Cheers
RodG

Hi - There is a plugin http://www.zen-cart.com/downloads.php?do=file&id=1340 'YouTube Video on Product Info Page' which does exactly what you want and wouldn't fall foul of GoDaddy's restrictions.
In a nutshell what the plugin does is store the YouTube identifier (the bit in red https://www.youtube.com/embed/qpgTC9MDx1o) in a custom field in the products table, and then uses code in the product_info template to add the iframe.
I've just this week added it to one of the shops I look after and it works well. One downside though is that because it is stored in the products table the same video gets displayed for every language (this may or may not be a problem, in my case it wasn't)
Might be worth a look.

Regards

RodG and David Allen thank you very much for the replies!

I will try the plugin, but still this doesn't resolve or explain why they main product field can accept and save iframe code perfectly fine while the custom field cannot. Surely there is a way to recode that custom field to handle the iframe input as flawlessly as the product description field.

pricediscrimination:

RodG and David Allen thank you very much for the replies!

I will try the plugin, but still this doesn't resolve or explain why they main product field can accept and save iframe code perfectly fine while the custom field cannot. Surely there is a way to recode that custom field to handle the iframe input as flawlessly as the product description field.

From my reply in post#29

"I'm still at bit a loss why it would work in the product descriptions though - Perhaps its because it is embedded deep within another $_POST variable rather than being a variable unto itself. It's about the only thing that would be different (and would certainly explain things)"

Cheers
RodG

RodG:

From my reply in post#29

"I'm still at bit a loss why it would work in the product descriptions though - Perhaps its because it is embedded deep within another $_POST variable rather than being a variable unto itself. It's about the only thing that would be different (and would certainly explain things)"

Cheers
RodG

I got that part, but how can I apply the same thing to the custom field? Seems that if it works for product description there must be a way to make it work for another field. Also there is more than one language installed so technically two instances of the product field (essentially same code I know) saves the iframe in the database without being blocked by godaddy's mod_security.

Just tried to put the iframe in the products url field and it even works there. Of course it doesn't display on the front end, but it saves the iframe code to the database and lets me proceed to the preview.

Have you tried saving the iframe in the custom field wrapped in a div - eg

<div><iframe width="853" height="480" src="//www.youtube.com/embed/qpgTC9MDx1o" frameborder="0" allowfullscreen></iframe></div>

These mod security rules can be very pernickety. I once had a situation where I found (after much effort) that they rejected any field that started with a four letter word ending in h - bizarre. For that I was able to get the hosting company to change the rules (lucky I wasn't with GoDaddy).

Even if this does work I would still look at the plugin's method of storing the data (ie just the qpgTC9MDx1o) and using the product_info template to provide the <iframe... bit
Regards

David Allen:

Have you tried saving the iframe in the custom field wrapped in a div - eg

<div><iframe width="853" height="480" src="//www.youtube.com/embed/qpgTC9MDx1o" frameborder="0" allowfullscreen></iframe></div> ```

Just tried this, it didn't work.

Hi guys, just wanted to update this thread and say thanks for the help. I installed the youtube plugin and it works great using just the video ID instead of the full iframe code in the admin. This means every old page needed to be updated, but well worth it since all the videos can now be formatted easily from the tpl_product_info_display.

An issue I am now facing is that for a responsive site, the only way to make the videos responsive as well seems to be to put the code within a wrapper (http://css-tricks.com/NetMag/FluidWidthVideo/Article-FluidWidthVideo.php) but the issue is that for product pages without a video, the extra padding-bottom (56.25% to be exact) creates a HUGE empty white space. Wish there was a way to tell the code to only display this div when there is a video ID entered in the input box in the admin.