406 Not Acceptable when adding YouTube video in admin on GoDaddy

[pricediscrimination]

OK, so there is defintely something in that $_POST variable that is triggering the error.

Can you please confirm if the problem goes away (or not) if you remove
'youtube_vids' => zen_db_prepare_input($_POST['youtube_vids'])

Cheers
RodG

Removing this line did not change anything.

Also what would explain these two things:
-iframe works fine in the regular product description field
-other text works fine in the custom field

[RodG]

Removing this line did not change anything.

Oh, that's a worry. Does the 'preview' page display ok? (I'm guessing it does)

Also what would explain these two things:
-iframe works fine in the regular product description field
-other text works fine in the custom field

This is what I'm trying to determine, but you've just thrown me through a bit of a loop because the removal of that line would/should have gotten rid of the error IF that is the $_POST variable that is causing the error.

The fact that the problem still exists implies that I/we are barking up the wrong tree.

Cheers
RodG

[pricediscrimination]

Oh, that's a worry. Does the 'preview' page display ok? (I'm guessing it does)



This is what I'm trying to determine, but you've just thrown me through a bit of a loop because the removal of that line would/should have gotten rid of the error IF that is the $_POST variable that is causing the error.

The fact that the problem still exists implies that I/we are barking up the wrong tree.

Cheers
RodG

With the iframe code, the 406 error kicks in before the preview is even viewable. With anything else but iframe, the preview is normal.

[RodG]

With the iframe code, the 406 error kicks in before the preview is even viewable. With anything else but iframe, the preview is normal.

OK, so this brings us back to a different piece of the code for further investigation, specifically /admin/product.php (assuming it even gets that far).

The program flow goes like this:

collect_info.php reads the data from the DB and displays it for edit. When the 'preview' button is pressed it posts the data to the product.php code, and finally when the update button is pressed it passes the $_POST data to the update_product.php code.

It now looks like the error is being triggered with the POST data to the product.php code......

And that is about as far as I can take you tonight.... The day is just starting in other parts of the world so hopefully someone else will take these current findings further while I'm sleeping :)

G'night.
RodG

[pricediscrimination]

OK, so this brings us back to a different piece of the code for further investigation, specifically /admin/product.php (assuming it even gets that far).

The program flow goes like this:

collect_info.php reads the data from the DB and displays it for edit. When the 'preview' button is pressed it posts the data to the product.php code, and finally when the update button is pressed it passes the $_POST data to the update_product.php code.

It now looks like the error is being triggered with the POST data to the product.php code......

I just downloaded a fresh ZC fileset and replaced my products.php with a new one. Nothing changed.

[RodG]

I just downloaded a fresh ZC fileset and replaced my products.php with a new one. Nothing changed.

Sorry, but I think I misled you here. I didn't think that the problem would be with this file. I was suggesting that this is the file where we should be looking to see what the $_POST data from the collect_info.php page/file contains.

This means finding a suitable place in the file to add the line:
print_r($_POST['youtube_vids']) ; die ;

The intention being to inspect the variable for anything (other than 'iframe') that could/would possible trigger the mod_security rule.

I'm still working on the assumption that it isn't the iframe itself causing the problem, and this assumption is based on the fact that "iframe works fine in the regular product description field"

If it turns out that there isn't anything amiss with the $_POST data contents, the next thing to do would be to populate the input field with the exact same data/code that you are currently using but *without* the 'iframe' part. (In fact doing this may even be a quicker/easier test/check).

Again, the point of this exercise isn't so much to *fix* the problem, but to identify the *exact* cause. (Is it the iframe, or is it something else).

If it *does* turn out to be the iframe itself we can then look into why it is causing a problem with this particular input, but not in the product description field.

Hopefully you can see where I'm coming from?

Cheers
RodG

[pricediscrimination]

If it turns out that there isn't anything amiss with the $_POST data contents, the next thing to do would be to populate the input field with the exact same data/code that you are currently using but *without* the 'iframe' part. (In fact doing this may even be a quicker/easier test/check).

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.

If it *does* turn out to be the iframe itself we can then look into why it is causing a problem with this particular input, but not in the product description field.

Hopefully you can see where I'm coming from?

Yes, I see where you are coming from, this is the odd part. The product description field can write the iframe code to the database but not the custom input field.

[lhungil]

... Yes, I see where you are coming from, this is the odd part. The product description field can write the iframe code to the database but not the custom input field.

Very ODD. Question is: what is the exact mod_security rule being triggered? Can you get this from your hosting provider?

The fix might be as single as changing a name / id or input type... But without knowing what rule is being triggered we are just guessing wildly.

[pricediscrimination]

Very ODD. Question is: what is the exact mod_security rule being triggered? Can you get this from your hosting provider?

The fix might be as single as changing a name / id or input type... But without knowing what rule is being triggered we are just guessing wildly.

It's GoDaddy, a basic question like that is asking too much from them. This is the kind of reply you'd get:

"Most likely the trigger is that you are trying to submit a URL via GET or POST. However that being said we cannot replicate the issue without the steps to duplicate and the other information we previously requested. Please provide this information so we can review further."

The information they wanted was IP address and admin password so they could get in there and try to post something lol.

[lhungil]

LOL. So the hosting provider is no help... Perhaps you could store something other than the full iframe HTML snippet.

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)?