Not sure whether this is a Youtube or iWiccle issue -

All Youtube embedded videos on my site no longer display - instead the error message:

The embed code does not appear valid. Please try again.

Embedded from Youtube  ⋅ 

It's a little strange really, just added a test video and it works OK. However, sometime during the past week I seem to have lost all previous embedded videos (pre as well as post 1.21.1). Makes me think this might be a Youtube issue.

Youtube have recently been shuffling their embed codes around with some new features rolled in, and if they way height and width are indicated have changed, or are changed in some variants of embed codes, this could cause the problem.

Can you hook me up so I can investigate this on-site? Also if you can post or PM me a list of Youtube URLs for which the embed code doesn't work, I'll test and debug them locally.

Thanks for reporting, as always.

Thanks Markus,

I've PM'd you site access details.

Thanks — I have now looked at your site and the latest post in Videos where the embed tag was shown as broken. I looked up a video of the same name in Youtube and posted it in, and as you can see it worked fine both in the form and on the page.

I notice however that things aren't all smooth when you go and try to edit a post and then click "Validate" again, or save it. I have also tested this with a new post and edit there, and the same pattern appears. However, this doesn't happen on my local server or on the online demo, so it's something server specific.

The error I get is "The following fields failed to validate: Height, Width, Embedded URL" — which suggests something goes wrong wholesale.

I suspect it has something to do with the way the server treats incoming POST data. Could you please add a phpinfo file to your site and PM me the link, and I'll check your configuration against mine, and try to replicate the bug locally. Something gets converted and corrupted, and let's find out what.

Markus, the phpinfo file links appears broken so I've sent you a PM with server access details.

Oops — fixed it, needed an underscore.

All the same thanks for the details, they are much better than a phpinfo file, and I will be logging in sometime tomorrow to take a better look at what the difference between our server is, and what triggers the exception that makes it fail.

This issue seems to be caused by magic_quotes_gpc PHP directive being on. Magic Quotes adds extra quotes for incoming data. It has been deprecated as of PHP 5.3.0. Many older (or poorly written) scripts unfortunately depend on it for their security, rather than doing proper incoming data sanitization, so we can't require people to turn it off at this time.

I am now running some tests to make sure the indended fix works across configurations, and you will have a patch in place once I return from dinner. Please don't go change the directive just yet to fix this! =)

Actually a false alert with the magic_quotes_gpc issue. This was a bit more mind-boggling, got to the bottom of it after debugging this from several vectors of trial and error.

Here's what happens:

When you "Add video", the regular embed tag from Youtube is validated, and the height, width and URL fields are parsed into separate values into the database. Then, these values are placed into the standard Youtube embed tag listed in skin_video_ow.php. The difference between the two is the wmode=transparent parameter you remember from the "Flash overlays everything" problem.

Now, why does one work, and the other not? After all, the video embed tag parser doesn't check for wmode field or any of that, and as I was also unable to replicate this issue locally no matter what I did. Here's the answer (tested several times):

Your server truncates GET requests with a single variable value longer than 512 characters. (While generally the lenght is limited by browser capacity alone.) Therefore, whenever the embed tag total length exceeds 512 characters, the whole "tag" variable is stripped out from the request before it ever reaches PHP. I have never come across this behavior before.

I have prepared a demo case of this for your web host to look at (as it's some sort of a server hiccup or limitation), and will PM you the details momentarily.

To fix this, I will change the query type from GET to POST and see if that works around this on your server. In the meantime, you can avoid this simply by not for example using colored frames for videos (as all that adds to the length of the URL, and thereby the tag).

I have now sent you a PM with a demo script where you can test the 512 character limit, and see how the field is omitted when the variable length exceeds 512. It doesn't happen on any of our servers (test case).

This is something you will want to forward to your hosting provider, as it's a quirk caused by an extension in the server software that makes it unable to relay URL variables over 512 characters in length.

Most likely this problem is caused by the Suhosin Zend extension, as reported in comments to PHP bug #50449. I notice your phpinfo output reads:

"This program makes use of the Zend Scripting Language Engine: ... with Suhosin v0.9.29, Copyright (c) 2007, by SektionEins GmbH"

The symptoms definitely match. Recommend turning Suhosin off from Zend extensions unless it's necessary for something in particular. Not much help for this at Suhosin headquarters, as half the site seems to be either work-in-progress or in transit (including troubleshooting and forums).

As noted in the comments to the bug report above, PHP language developers don't support Suhosin or other extensions that may break intended functionality. There is no upper limit defined in the RFC for URLs or URL variable length, though the practical upper limit starts with Internet Explorer's 2083 character capacity.

Here's an additional educative bit of info on Suhosin from a Wordpress script (by Peter Westwood and Denis de Bernardy, here) that checks for diverse PHP configuration issues:

Your Webserver is using the Suhosin patch with over-zealous security settings. Suhosin is an extreme source of grief for large PHP applications, and ought to be a primary suspect if you experience very weird WordPress issues. The symptoms include messages with cryptic resource limits, partially loaded pages, and partially saved data.

It does sound like switching Suhosin off for the time being might be a good idea, given that it exhibits unexpected behavior that interferes with regular operations, and moreover as their operations in general seem to be a bit in transit at the moment.

Thanks for figuring this one out Markus.

I've emailed the details to my hosting provider with a request to disable Suhosin. I'll wait for that to happen and try testing it out myself. I'll provide an update after that happens.

Thanks again.

I will still change the embed tag form request from get to post as soon as I get around to it, not too complicated an operation. To the best of my knowledge no other variables over 512 characters are passed over get protocol, so this should be an isolated issue.

In the Suhosin configuration details, there's a parameter called suhosin.get.max_totalname_length that is by default set to 512 characters. If you bump this up to double (1024), for example, it should be well enough to keep the video validation feature from breaking.

So far I haven't heard of any other problems caused by the Suhosin plugin with our software (although problem reports with other scripts many), so if you want to keep it on for some added PHP security, you can do that as long as this parameter is changed.

----

Update: I added suhosin.get.max_totalname_length = 1024 to a php.ini file I created in your webroot, and since your server permits this php.ini override and as Suhosin settings work on this level, the issue has now been fixed on your server, as you can see if you test with your videos or the test script I linked you with. Please report any problems. For now, over and out. =)

Yes, that fixed it!

Many thanks, I'll cancel my support request to my hosting provider.

It just occurred to me that my hosting provider wouldn't be unique in using the Suhosin extension, and that other users might strike the same problem along the way.

A simple way for a user to check if they're likely to face the possibility of losing some (or all) of their embedded videos is:

1. Select a YouTube 'embed' with all of the embed options selected (border, privacy mode, etc) - 'validate' then publish within Wiccle/iWiccle ('embed' code with all options selected is around 519 characters).

2. Select 'Edit' after successfully publishing the embedded video. Without changing any of the 'embed' code, click on 'Validate'. If you get an invalid code message, you may have a Suhosin problem.

3. To ensure it's not a genuine 'embed' problem, select the same video embed with all options unchecked (borders, privacy mode, etc) - the embed code is now around 421 characters. Validate and Publish the video with the new embed code. After successfully publishing, select to 'Edit' the post. Without changing anything, click 'Validate' - if you get an invalid code message it's a genuine problem with the embed code. If the code successfully validates, it's most likely the Suhosin (512 character limit) problem.

Hopefully this little test will help others in the future.

Thanks for the useful test and debug notes!

Opinions seem a bit divided on Suhosin — some dig it for a bit of extra security, and some don't because it's so easy to have configured in ways that break especially larger applications.

You can believe this solution eluded me for a good moment there — tried to debug from every possible location to see where the data gets corrupted, only to realize it never reaches PHP after a certain length to begin with. Maybe next time you'll discover a situation where space aliens intercept and consume certain binary sequences for food...

Hi Markus,

I seem to have lost all my embedded videos again. Invalid code message on all.

After my images being deleted, I replaced the uploads file with a backup copy - could this have been the cause? I haven't tried to correct anything yet, pending your instruction.

Please feel free to access the site and server as you see fit.

Thanks.

Addition to the above:  is the 'Embed Code' for each video stored in the sql database? I've been searching everywhere but can't find where each embed code is stored.

Actually the original embed codes aren't saved; only the width, the height, and the URL in the tag. (These are also what's being validated in a tag.) They are saved as a serialized array in the database under the post_cache field. They are then placed into the tags you find in skin_video_ow.php. This removes the possibility of someone feeding in fishy tags that might otherwise validate.

Can you find any way to replicate this behavior, or think of anything that triggers it?

I can't think of anything that might have triggered it but I'll try various scenarios to see if I can recreate it.