Project

General

Profile

Support #12393

size limit for files

Added by Marilyn Weber almost 2 years ago. Updated almost 2 years ago.

Status:
Resolved
Priority name:
High
Assignee:
-
Category name:
WordPress (misc)
Target version:
-
Start date:
2020-02-10
Due date:
% Done:

0%

Estimated time:

Description

From Paul Hebert:

I'm getting a strange notice on on sites that the size limit for files uploaded to the media section is 1kb.

It looks like this happened in the last 24 hours or so because I was earlier able to upload files with no problem.


Related issues

Related to CUNY Academic Commons - Bug #9974: Network options cache is messing things upResolved2018-06-28

History

#1 Updated by scott voth almost 2 years ago

  • Category name set to WordPress (misc)
  • Priority name changed from Normal to High

I am noticing this too. I cannot upload media files.

#2 Updated by Boone Gorges almost 2 years ago

A cache flush seems to have fixed the issue. Can you please confirm?

Ray, I seem to have a recollection of something similar (broken sitewide setting that was fixed by flushing the cache - it was the value of "1" that made me suspect it was a non-integer being cast to a number) but my Redmine searches are turning up nothing. Do you remember something like that?

#3 Updated by scott voth almost 2 years ago

Yes, it is working for me now. Thanks.

#4 Updated by Marilyn Weber almost 2 years ago

I have confirmation this is fine now.

#5 Updated by Boone Gorges almost 2 years ago

  • Status changed from New to Resolved

Great, thanks!

Ray, if you have any thoughts about this, please follow up.

#6 Updated by Raymond Hoh almost 2 years ago

Ray, if you have any thoughts about this, please follow up.

I missed the initial reply to this, Boone. Apologies!

Ray, I seem to have a recollection of something similar (broken sitewide setting that was fixed by flushing the cache - it was the value of "1" that made me suspect it was a non-integer being cast to a number) but my Redmine searches are turning up nothing. Do you remember something like that?

I just did some searching on Redmine and #9974 is the ticket that comes close to what you were mentioning. Hopefully, it isn't a reoccurrence of that issue!

#7 Updated by Raymond Hoh almost 2 years ago

I was re-reading #9974 and it linked to this WordPress core ticket:
https://core.trac.wordpress.org/ticket/31245

In WP 5.3.1, a change was made to the alloptions cache so it is purged more often:
https://core.trac.wordpress.org/ticket/31245#comment:92

This might have had an effect on the alloptions cache, but it sounds like that should have improved the invalidation of the cache though...

I also looked at the latest version of our memcached-hm object-cache plugin and a few changes have been made since our last update:

================================================================================
Lines modified at 175
================================================================================
-     global $wp_object_cache;
+     return true;
================================================================================
Lines deleted at 176
================================================================================
-     if ( method_exists( $wp_object_cache, 'quit' ) ) {
-         $wp_object_cache->quit();
-     }
================================================================================
Lines modified at 287
================================================================================
-     $caller = array_shift( debug_backtrace( DEBUG_BACKTRACE_IGNORE_ARGS, 1 ) );
+     $backtrace = debug_backtrace( DEBUG_BACKTRACE_IGNORE_ARGS, 1 );
-     if ( ! defined( 'WP_CLI' ) || ! WP_CLI ) {
+     $caller    = array_shift( $backtrace );
-         //trigger_error( sprintf( 'wp_cache_flush() is only allowed via WP CLI. Called in %s line %d', $caller['file'], $caller['line'] ), E_USER_WARNING );
+     if ( 'cli' !== php_sapi_name() ) {
-         //return false;
+         trigger_error( sprintf( 'wp_cache_flush() is only allowed via WP CLI. Called in %s line %d', $caller['file'], $caller['line'] ), E_USER_WARNING );
================================================================================
Lines added at 291
================================================================================
+         return false;
================================================================================
Lines modified at 746
================================================================================
-     $wp_object_cache = new WP_Object_Cache( getmypid() );
+     $wp_object_cache = new WP_Object_Cache();
================================================================================
Lines modified at 1319
================================================================================
-             if ( isset( $this->cache[$derived_key] ) ) {
+             if ( isset( $this->cache[$derived_key] ) && ! $force ) {

I think the main change is the last one at line 1319:
https://github.com/humanmade/wordpress-pecl-memcached-object-cache/pull/10

We also customized how wp_cache_flush() works from Human Made's version by continuing to allow its usage outside of WP-CLI:
https://redmine.gc.cuny.edu/issues/9974#note-19

So we'll want to comment out their additions to wp_cache_flush() as well.

Also about our addition on line 746 - getmypid() - I'm not sure if we need this anymore.

#8 Updated by Boone Gorges almost 2 years ago

  • Related to Bug #9974: Network options cache is messing things up added

#9 Updated by Boone Gorges almost 2 years ago

Thanks for the pointer to #9974, Ray. That is the one I was thinking of, and yes, this unfortunately feels like a similar issue.

The upstream changes don't seem significant enough to port over at the moment - as you note, the main functional change is related to force. In any case, it doesn't seem like the handling of alloptions has changed.

I guess I'm OK adopting a wait-and-see position here. If this or a similar problem arises in the near future, we'll have to go back to the debugging techniques used in #9974 to verify that this is indeed a case of cache pollution. And if it is, we'll have to see whether it is related specifically to alloptions. In the meantime, I feel like there's not much more we can do.

Also available in: Atom PDF