Make WordPress Core

Opened 9 years ago

Closed 9 years ago

#32307 closed defect (bug) (invalid)

Media library grid layout loading takes a (very) long time

Reported by: jipmoors's profile jipmoors Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.3
Component: Media Keywords: close
Focuses: performance Cc:

Description

Situation
Corporate site with around 300 media items.
CMS user notices me of the slow loading of the library.

Research
Grid layout loads in 13 seconds per wp_prepare_attachment_for_js request which results in 40 items with a request size of 450KB(!).
List layout loads in 0.6 seconds results in 35 items with a request size of 12KB.

Solution
Disabling get_compat_media_markup takes the grid layout ajax requests back to 300-400ms with a size of 7-8kb.

I have not been able to detect any functionality breaks on my environments, but since the name contains 'compat' this was not expected either.

Unsure when/what is breaking when this would be disabled overall.

Conclusion
The grid layout adds a 'compat' variable with a lot of HTML content to each attachment.

Which brings me to this piece of code:

if ( function_exists('get_compat_media_markup') )
		$response['compat'] = get_compat_media_markup( $attachment->ID, array( 'in_modal' => true ) );

(wp-includes/media.php:2849)

It seems that this function exists and is loaded (wp-admin/includes/media.php) so this will always be applied.

There is no if ( ! function_exists('get_compat_media_markup') ) around this function so overriding is not a possibility.

Since there is no documentation surrounding this function I'm unsure how this is used. I'm sure that it is needed in some way or another but I hope it is not needed per item in the listing.

Change History (3)

#1 @nikolov.tmw
9 years ago

From what I can tell by following through the code, the get_compat_media_markup() function is there in order to provide a backwards-compatibility layer between the new media modals and the way the media edit screen was presented before.

This function will look for any taxonomies that are linked to attachments and display the corresponding interface for selecting those. It will also run the filters that allow you to add custom fields to media items and render the interface for them as well.

If you're seeing that much of a slow-down and increase in request size, I assume that somewhere in your code adds either custom fields to attachments(using a filter like attachment_fields_to_edit), registers one or more taxonomies for attachments or both of those.

If that's the case, then I'd suggest you look into ways that will allow you to add any custom fields via the Media Views(although I'm not a 100% sure if that's possible, I would assume it is).

#2 @jipmoors
9 years ago

  • Keywords close added

Sorry for leaving this open for so long.
I found the probleem in one of the plug-ins that was adding meta to all post types including media..

Though the if exists statement does look to be confusing and could use some more commentary this problem is misplaced.

Thanks for your reply!

#3 @wonderboymusic
9 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.