oh, hmm. This may be something I didn’t realize needs to be updated.
A point of confusion is that WordPress (and Imsanity) look at the images files to get the size, width, height, etc. But actually that information is only looked at once when you upload the file and then saved in the wp_meta table. From that point on all file size information you see is from the data in that table – not from the actual file sizes. So there is always a possibility of that data getting out of sync with the actual file in which case WordPress metadata says a file is 5Mb but the file itself is actually only 2Mb. Generally this is just informational anyway and doesn’t affect anything, but in the case of a site with quota limitations it might make the total size incorrect.
When Imsanity does it’s bulk resize, it has to also update the wp_meta table to match with whatever the new width and height is. As it turns out, I’m not 100% sure during the bulk resize that I am also updating the metadata indicating the disk size of the file. I will have to take a look at the code to refresh my memory.
Also it would make sense that the total quota percentage may be something that is calculated separately, because it would be expensive to calculate that every time you look at the dashboard.
One thing you might try – just upload a new image and see if the total quota updates. If it’s something that WordPress calculates only when a new image is added or deleted then that might be enough to correct it.
Thanks for the report, I’ll have to do some research on this one…
I just looked into it and actually WordPress does not save the file’s disk size with the metadata so I was mistaken about that. It uses a function in wp-includes/ms-functions.php called get_space_used() which actually just looks at the filesystem.
This function gets a value which is then cached in the wp_options table with the option name of “_transient_dirsize_cache”
I believe you should be able to delete this row altogether to clear the cache and then WordPress will re-calculate it on the next view. Alternatively I suspect that if you upload or delete an image from the Media library, it will trigger the re-calculation as well.
If you have any luck with that I’d be glad to hear about it. After the bulk resize I may have Imsanity clear this cache value if that does do the trick.
Thanks for the quick follow up.
I as able to delete the following row from the database table for the blog that needs to have the storage space updated: _transient_dirsize_cache… Unfortunately this did not resolve the issue. I did see another database row _transient_timeout_dirsize_cache and I deleted this as well but this did not resolve the issue either.
I attempted to upload new media however this blog is at max upload size so I am unable to add new media in order to see if that would resolve the matter.
I did however remove a file from the media library hoping that this would have the same affect but it did not.
You would think that updating this value would be a bit easier.
Ok, so I have tried a few more things out…
For the blog in question I have increased the amount of storage space available from 1024 to 2048. This changed the amount of storage space available to 50%. I was hoping that it would have changed to ~35%. But it did not.
Next I uploaded an image to the media library, however it that did not trigger a recalculation either, so still at 50% available.
Let me know if there is something else I can test out.
Thanks,
JL
This is pretty baffling to me because as far as I can see WordPress just looks right at the wp-content folder for the blog and runs filesize() on every file in there. Then it caches that value in that transient value.
Is there any chance it’s a multi-site and you’re looking at the wrong options table and/or contents folder? Maybe try running du -hs inside the content folder and see what the operating system is reporting..?
For what it’s worth, clearing the two transients works for me, and it would be great if these were added to the plugin.
Workflow:
1) Upload insanely large image
2) Look at quota usage on dashboard
3) Activate imsanity, use it to resize existing images
4) See that the dashboard is reporting the old, larger, value
5) delete _transient_dirsize_cache & _transient_timeout_dirsize_cache
6) See updated, smaller, quota usage on dashboard
Thanks Jason – I think I’ll just delete those two transients after a bulk resize. From what I can see – the dir_size cache times out after one hour anyway, so shouldn’t be something that lasts for very long but it would probably be nice to reset them after the bulk operation.
@jason – How/Who is hosting your WordPress install. In this case I am using WPEngine – I am wondering if there infrastructure is causing the issue here?
Hey Joe, that’s a definite possibility because there isn’t any reason why the WordPress size should be different from what the filesystem reports.
I use pair.com for hosting which is BSD, but I also have installations running on OSX and Ubuntu and it seems to be consistent on all of them.
Thanks for jumping in and providing good info. I will have to take this up with WPEngine from here and see what’s up.
We’re doing our own hosting.
I think the problem could very likely be WP Engine related then – I know they have a pretty custom environment with all sorts of crazy custom caching stuff.
@jason – if you’re going to add these two delete_option calls, please take a moment to consider this request: http://wordpress.org/support/topic/feature-requests-filters-on-settings-screen And just let me know if you want any help with testing anything.
Cheers
Hello Joe, just for the record, yes, WPEngine has a very hard internal cache that you cannot simply force to update. Sometimes it’s like if the Dashboard settings were a ghost and delayed copy of the production site. Changes made in backend sometimes require some minutes to be applied to the website. I’m dealing with a website having 3k photos and it’s a PITA.
Anyway, I came here to make a question to Jason in a separated thread..
Just logged into the blog site in question and it appears to have finally been updated. The storage space now reads 50%. Must have something to due with WPEngine’s infrastructure.
Interesting. I bet that WPEngine uses some type of cache that is behind the scenes where you can’t see it as an end user.
I’m guessing if I put in some code to wipe the transient and go through the proper API call to do it then it would clear the cache right away.
