Files upload but not in media library

Things to check:
– Write permissions on upload directories and/or TMP directory
– Disk quota OK?
– Any weird JS errors in Web console?
– Does Tools → Site Health indicate anything strange?

Thanks. I appreciate the advice. I will check them out.

Disk quota is ok.
I addressed a number of site health issues, including PHP update. There are a few “recommended” improvements that I could pursue. The only critical ones are a few plugins and themes to be updated… and I was able to isolate those as reasons earlier.

As an aside last night I updated WordPress only on another multisite instance running 5.5.3 going to 5.6.1 and had the same issue. I was able to restore the old version though due having my network admin make a clone of the box first. Since my 5.5.3 instance works fine it feels like it something with my overall box setup (Apache?) and 5.6.1

Thanks again!

Check for Javascript errors when you do an upload. Perhaps something is calling deprecated stuff in jQuery. Both with 5.5 and 5.6 some moves were made towards catching up the included version of jQuery and gradually removing support for deprecated jQuery calls. Easiest way to verify this might be to use https://www.ads-software.com/plugins/enable-jquery-migrate-helper/ with the relevant settings for fallback, etc. enabled.

There are no errors in the console. I installed the enable jquery migrate helper plugin and I am logging right now. So far there is nothing in the logs. I do get 5 “warnings encountered” that appear to be WordPress related on pages (in v5.6.1)

/wp-admin/js/common.min.js: jQuery.fn.delegate() is deprecated
/wp-admin/js/common.min.js: jQuery.fn.click() event shorthand is deprecated
/wp-admin/js/common.min.js: jQuery.fn.bind() is deprecated
etc.
All related to common.min.js in wp-admin folder. I had more but removed the plugins as they weren’t really needed at this point.

I was finally able to migrate successfully back to 5.5.3 on this instance, so I have bought myself a little time. The warnings are not there in 5.5.3 and the upload functionality is restored after the downgrade.

I have a few other things to try (file permissions) and will look for other options as well. The permissions seem less likely as the files are actually getting uploaded into the folder, they just aren’t showing up in my media library, etc.

Thank you! I really appreciate the help on this. If I get the solution figured out this weekend, I will be sure to post it on here for others but I’m not feeling terribly confident that will happen right now.

Just a quick update, still no luck. Here are a few of the things I tried this weekend:

– Using the jQuery Migration tool I reverted back to an older version of jQuery and it did not fix the issue.
– I updated OpenSSL, which needed to be done but this had no effect either… not that I expected it would.

I have reverted back to WP v 5.5.3 for the time being to keep things working. I’m running short on ideas.

If I take out most of my plugins the error is “Cannot convert blob:https://siteName/5e32b981-6e33-48cc-87b1-512abd653912 to Blob. Resource might not exist or is inaccessible.”

Are you using the classic editor plugin, or anything other than the normal block editor?

Have you tried uploading from the media library instead of from the post editor?

Also, look in your PHP’s error log file, right after you have the upload fail. There may be a more useful error message there.

Thanks. Yes, I am using the classic editor plugin. If I deactivate it and try uploading an image a few things happen:
1. The image is uploaded into the correct folder (year –> month)
2. The image shows up in my block faintly with a spinning circle like it’s thinking.
3. If I click on Preview in new tab while it’s still trying to process, the preview shows up.
4. If I click on Publish while it is still trying to process, it appears to be in there.
5. The item is still not in my media library AND still get an error.
6. Ultimately, it fails and I get a warning “<p>There has been a critical error on this website.</p><p>Learn more about debugging in WordPress.</p>”
7. At this point, if I reload the page, the image is no longer there (from step 4).

So I get different errors if the plugin is enabled or not, but the end result is the same.

If I use the media library uploader,
1. The progress bar goes to 100% but never converts to a thumbnail.
2. In the console I get an error:
async-upload.php:1 Failed to load resource: the server responded with a status of 500 ()
3. The file does show up in the correct folder but does not show up in my media library.

So either method (page or media library) is uploading the file to the folder. It just seems like it’s not finishing up the processing, which I assume means it is not inserting it into the DB tables. I’m not sure what else it does during that upload process.

You’re probably going to need to look at the PHP error logs then, to find the exact error. A 500 response comes from the server process, which means that the error should be logged there. Find the error, find the solution.

Interesting. I am not getting any errors but I am getting this warning:
“PHP Warning: mysqli_num_fields() expects parameter 1 to be mysqli_result, bool given in \apache2\htdocs\wp-includes\wp-db.php on line 3380” This is happening quite a bit and also happens when I upload files.

If I let it run until the error message, I get this: “PHP Fatal error: Maximum execution time of 300 seconds exceeded in \apache2\htdocs\staffsites\wp-includes\functions.php on line 7736” This appears to be tied to file uploads as it is only seen after an attempted upload.

One notice that I fixed was that the tmp file was ultimately missing. This happened during the PHP update, I guess. I fixed that and the notice stopped. This did not impact the functionality at all.

There are a few notices as well but this is the only thing of note in the PHP log.

PHP Fatal error: Maximum execution time of 300 seconds exceeded in \apache2\htdocs\staffsites\wp-includes\functions.php on line 7736

Well, that is more info than we had before.

New to 5.6 is the directory cache. This is largely only used on multi-site setups.

Some background info and a ticket: https://core.trac.www.ads-software.com/ticket/19879

The short version of this is that multisite has settings where you can implement quotas like maximum sizes for site to have files and such. In order to implement those, it has to add up the sizes of all the files. However, that’s slow, so it caches this information in transients, so it doesn’t have to do it all the time.

The function at around the line you’re specifying is the clean_dirsize_cache() function, which cleans up this cache.

If this is a multisite, and you did an upgrade, did you also do the step where you run the update process over each site? The one located at /wp-admin/network/upgrade.php ?

One of the processes done in that update step is the simple line delete_transient( 'dirsize_cache' );, which you can find around line 2379 in the wp-admin/includes/upgrade.php file. This would be in the upgrade_560() function. This will essentially clean out any old transient data.

If you have not actually done the network update step yet, do that. See if it fixes the problem. This would be why it’s critical in multisite instances to actually do the network update, so that things like this don’t happen.

Yes, I have upgraded the network each time. I have downgraded and upgraded WordPress multiple times now. I downgrade to 5.5.3 so folks can do their work then update WP when I want to test things (usually in the evening). I actually run the network update when I downgrade WP as well. I just upgraded and updated the network again. No luck.

I will read what I can about the directory cache and see if it gives me any more ideas or clues.

I went back and double-checked things that I had tried earlier, like removing plugins and themes, and did not have any success.

I even upgraded to 5.6.0 one time instead of 5.6.1 and the problem was still there.

Downgrading and then upgrading again will not cause that update process to run again. The database version number is changed and that is checked to see what steps to run.

Manually look at your database on one of the sites with the problem, look for the dirsize_cache transient, see what’s there.

Ok. I went into the database and found “_transient_dirsize_cache”. It appears to largely be a list of paths that look like this:

i:0;s:92:”<PATH TO BLOG>/files/2021/02″;

It looks like it is mostly each year/month folder in the site’s files folder, starting from years ago to this month.

I may not be looking in the correct place but this is the only field that I can see in the database with that name.

I’m making some big assumptions here but is this where I’m headed..
– I’m assuming if I don’t have the correct wp_current_db_version then the delete_transient(‘dirsize_cache’); won’t run. Correct?
– Since there is data in the _transient_dirsize_cache field, that function didn’t run.
– Therefore, my wp_current_db_version is not current/didn’t get updated.

If that is the case then I need to figure out how to find the current wp_current_db_version and see about updating it?

We are outside of my area of expertise here so I’m sorry if I’m off track.

Also, the sites are currently on 5.6.2 and I have upgraded the network. I am still having the same issue but have a little different error when it times out: “Cannot read property ‘get’ of undefined”

I also misread the code. Since I have data in that _transient_dirsize_cache field my wp_current_db_version should be ok since the newer version uses that for multisite purposes. So, if that is the case, then I’m not sure of my next steps. Sorry for the confusion.