Joe McGill

Hi @eragonsoftware. My understanding is that PDO_SQLITE is used in the plugin in order to use SQLite as a drop-in replacement for a MySQL compatible database that WordPress expects using the consistent PDO interface.

If you are aware of ways to do this without the PDO extension, please feel free to share a suggestion in the GitHub repo where this plugin is developed.

Glad that fixed your problem! This is a new bug due to an optimization that was shipped in WP 6.3, which is why there isn’t much written about it. Setting that development mode bypasses some internal caching of the path to those style files. Since you were changing directories, the cached path to those files also changed, which is why they weren’t loading.

This sounds like the issue described in https://core.trac.www.ads-software.com/ticket/59111 to me. Try adding define( 'WP_DEVELOPMENT_MODE', 'core' ); to your wp-config.php file as a temporary workaround while you’re working on the site.

We’ve seen a few reports of this and are investigating. If anyone is running into this problem and can provide more details about their setup, please reply on this ticket: https://core.trac.www.ads-software.com/ticket/59057

Hi @bst7,

As @joyously correctly suggested above, WordPress adds the srcset attribute to images in your posts when the page is created. It does not save those values in the content in the database to avoid exactly the situation you’re describing, so it’s a unexpected that you would see a page with a srcset that includes images that are no longer available on your server after regenerating.

I expect that one of two things are happening. Either a) you have a caching plugin installed that saved the old markup from before the time when the images are regenerated, or b) your database still includes the deleted files in the attachment metadata for those attachments. To check the latter, can you find the attachment id for one of the images that isn’t working and use either wp_get_attachment_metadata() in your site or look up the value in the post_meta table of your database where the meta key is _wp_attachment_metadata and the ID matches the attachment ID?

Hi all,

If you’re not seeing any JS errors in your browser’s console it’s not likely that your experiencing the same issue described in 42574. Could you take a look at your network panel and see if you have any server errors when you try to load the medial library? Also, does the same issue happen in the media library on list and grid view, or only the grid view?

Thanks Ian, not sure if I can submit a patch for a plugin on the SVN repo to which I don’t have access. If you have advice there, I can look into helping. Would be nice to have this working well for WordCamp US if it’s going to be used.

Hi KennyLL,

As you’ve discovered, WordPress doesn’t affect images in widgets by default, but you can turn that functionality on for widgets with the following line of code in your functions.php file.

add_filter( 'widget_text', 'wp_make_content_images_responsive' );

The only other requirements are:

• There should be a class name with the attachment post id in it. Example: wp-image-4 means attachment id 4.
• That id should be of an image attachment post (not page, not revision, etc.).
• There should be image meta for that attachment post containing information about the sub-sizes that were generated when the image was uploaded.

Hi rschoultz2,

It looks like your theme is customizing the markup of featured images on your posts, which may not be compatible with the responsive images markup in WordPress. However, images within posts seem to be working as expected. You may need to reach out to the author of your theme to see why they aren’t supporting responsive images.

Joe

Hi @blizeh

This sounds a lot like the same issue being discussed in this thread.

Could you try adding the following line to the .htaccess file in the main WordPress directory on your server and see if that resolves your issue?

SetEnv MAGICK_THREAD_LIMIT 1

Thanks,
Joe

Thanks @stylenoir,

Both symptoms—the missing library, and the upload failures—are likely related, but it’s also possible that they are two separate issues. When you go directly to the media library, wp-admin/upload.php, are you seeing issues with both the grid and list view, or only the grid view?

Hi all, to anyone having this issue, can you test if the original size of the image affects the issue? For example, if you try to upload a very small image, like this one. Does the error persist?

What is the original file size (both in pixels *and* KB/MB) of the images that are failing to upload?

Hi all,

Just an FYI, this issue has been fixed in WordPress 4.5. You can test the release candidate to see if it resolves things for you.

See: https://core.trac.www.ads-software.com/ticket/34945

Joe

Thanks for the suggestion.

It looks like there is an open ticket for this in WordPress (https://core.trac.www.ads-software.com/ticket/35726). I’m not sure if it’s something that would be added until there is broader browser support, but it would probably make sense in a plugin.

Joe

Thanks for the report. Could you share some info about what version of Imagick you have installed on your servers? You should be able to get this from phpinfo().

Also, I’ll second Mika’s advice that it’s risky to run betas on live servers unless your ok with debugging issues like this, but we’re happy too have the extra test cases!

If you need a quick workaround to fix a broken site, try adding this code to a plugin or theme functions.php file:

add_filter( 'image_strip_meta', function() {
 return false;
});