Bjoern

Too bad – the error 500 is a general error and without any further info debugging is quite impossible. Could be WPPP causing an error, could be a buggy mo-file, basically it could be anything. But if you can activate the gettext option the error could be caused by an corrupt mo-file from another plugin. WPPP tests the gettext part using a special translation file and only if that test translation is successful, the option gets selectable.

Which plugins and theme are you using? Maybe I can reconstruct the issue.

Was WPPP gettext enabled, when you generated that output? I kown it quite tedious, but please enable gettext check if there are any error messages more detailed that the 500 error. The 500 error could be anything so with that only I don’t have anywhere to start looking for the cause.

Could you try enabling WordPress debugging and PHP error output?

It’s the edit media screen (post.php?action=edit) for editing a single attachment (the “Edit more details” link if you are using the grid view). As soon as I click on Update in the save box the meta values appear in the data base. Update returns to the edit screen.

Ok, I just tested with another installation, and it happens there too. And it does happen with any image, not only those without parent, as soon as I edit an attachment and click update.

get_post_meta($post->ID, '_kgflashmediaplayer-externalurl', true) returns an empty string if that meta value hasn’t been set. And '' == false evaluates to true. Isn’t PHP nice…

I’ll test if I can reproduce the error with another setup.

No, those fields only appear for videos. I also tried to figure out where those meta values get written but couldn’t find out yet where all of it happens. But it happens.

I think it’s because the uploaded images don’t have a parent post.

I could fix most meta value entries by changing the following (line 4073):

function kgvid_image_attachment_fields_to_edit($form_fields, $post) {
   $options = kgvid_get_options();
   if ( substr($post->post_mime_type, 0, 5) == 'video'	&& (empty($post->post_parent)
       || (strpos(get_post_mime_type( $post->post_parent ), 'video') === false && get_post_meta($post->ID, '_kgflashmediaplayer-externalurl', true) == false))

Tha last part of the if Statement evaluates to true using only ==. Using === seems to fix it, except for one meta value: “_kgflashmediaplayer-forcefirst”. I guess this is because of a similiar bug.

Do you mean PHP 5.5? MySQL version shouldn’t affekt that error.

No need to use the quick fix. New version is online.

You use another prefix than “wp_” for your WordPress installation. I have to admit I hardcoded the table name as “wp_posts” (didn’t think of differing table prefixes).

As quick fix: Just execute the SQL command manually replacing “wp_posts” by the post table name you use.

I’ll fix the issue as soon as possible and release a new version without hardcoded table names.

Thanks for the hint.

I definitely have to recheck the PHP version test. Activation should stop with an error message that PHP 5.3 or newer is required.

All that refactoring I’ve done lately must have messed that up.

Here’s a more indepth explanation: The (old) “dynamic image links” feature replaced all image links with the placeholder “{{wpppdynamic}}” in posts. That placeholder should be dynamically replaced by either your content path URL or your CDN URL when the post get’s displayed. The replacement was done to improve performance as it allows a much faster string replace instead of a slower preg replace to change image URLs.

If something goes wrong and the replacement didn’t work, your browser interprets the URL as a relative URL, displaying it as something like “https://yoursite.com/%7B%7Bwpppdynamic%7D%7D/image.jpg”. “/%7B%7Bwpppdynamic%7D%7D/” being the URL encoded placeholder.

The restore static URLs feature does a string replace on your database to restore all URLs back to your upload dir. How to do this manually is also explained in the FAQ.

So much for the explanation. Version 1.9 introduces a changed behaviour: It doesn’t use the substitution by default (when WPPP is newly installed), so just deactivating dynamic links restores normal behaviour of the site and nothing gets broken. To improve performance of this feature the substitution can be re-enabled optionally.

If you use any page caching plugin, the slower preg replace wouldn’t matter anyway.

I’m pretty sure it’s caused by your PHP version. Nonetheless I changed the code in version 1.9.

Version 1.9 introduces the new behaviour. Maybe you can give it a try.

It doesn’t affect SEO.