[wp-trac] [WordPress Trac] #63279: Improve `media_library_months_with_files` inside `wp_enqueue_media()`

[WordPress Trac]

#63279: Improve `media_library_months_with_files` inside `wp_enqueue_media()`
-------------------------+------------------------------
 Reporter:  apermo       |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Media        |     Version:  4.7.4
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:
-------------------------+------------------------------

Comment (by apermo):

 I know that WordPress does not refactor for the sake of refactoring.

 As I tried to point out, this is already a benefit.

 **Current status quo:**

 You can use `media_library_months_with_files` to short circuit the query,
 but you will either need to come up with some function (for example a loop
 that just guesses the results) or copy code from core.

 **With my suggested change:**

 The dev can use the new `get_media_library_months_with_files()` to use the
 same query the core uses.

 ---

 I have that very use case, and I did both, and I don't like that I had to
 copy code from core, and while the loop from a start date to the current
 month works fine for one project, the editors post content in the far
 future before scheduling it correctly, so that project has uploads in the
 year 2222.

 I do see your point that the caching API looks beneficial, but in this
 case I disagree that this would be the correct approach.

 Without the use of an object cache, `wp_cache_set()` will not be
 persistent, I can for sure say that this query is fired at maximum once
 per page load, so without object cache doing this will have no advantage.
 And for me, who want's to do a more persistent cache, it's also no
 advantage.

 I do agree though with your suggestion to clear/repopulate the cached
 result when a new file was updated.


 For small to medium bloggers, this change would change nothing, and they
 will not install an object cache, so they wouldn't see a difference if we
 added `wp_cache_set()`

 For maintainers of large installations (such as myself) having
 `get_media_library_months_with_files()` would be a trivial way to add some
 more permanent cache to `media_library_months_with_files` without the need
 to copy and paste core code.

 Don't see it as refactoring `wp_enqueue_media()`, see it as introducing
 `get_media_library_months_with_files()` which is then used by core, to not
 repeat oneself.

 As you pointed out, WordPress does not refactor just to refactor, but
 there is the other mantra, that core should only come with features that
 are for the bigger majority, so adding some caching that does nothing for
 the majority, and will likely not cut it for high end blogs, is also
 contradicting that mantra.

 After rethinking your suggestion, I think I'd still store the result for
 my project in a transient, maybe with multiple days life time, and redo
 the transient everytime media has been uploaded.

 Using a transient though would benefit every user, with or without object
 cache. And with object cache the transient is stored in the object cache
 instead of the database. So from my point I'd still either keep it like it
 is, or add the transient with a clear and maybe fill after upload and a
 filter for the lifetime of the transient.

 I'm be happy to hear your thought and maybe a third opinion.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63279#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform