Support

Account

Home Forums Backend Issues (wp-admin) Update to WP 5.9.1 breaks media selection

Solving

Update to WP 5.9.1 breaks media selection

  • Hi there,

    the latest update to WordPress 5.9.1 breaks all media upload prompts connected to ACF fields. Simple file uploader or the option within a wysiwyg editor field tries to open up the media library/upload window but it isn’t displayed correctly.

    Is this a common issue or just within our theme?

    Thanks!

  • Most likely has something to do with: https://core.trac.wordpress.org/changeset/52648

    This fixed some issues regarding the media library window and is maybe related to this?

  • I can confirm the behavior.
    If I disabled ACF, the error no longer occurs.

    wp.media.featuredImage and wp.media.mixin are undefined.

  • I’m having the same issue. It’s across several sites using different versions of php and themes.
    Seems to just be affecting blocks and the gutenberg editor and not flexible fields.

  • Temporary solution here is a rollback to WP 5.9

  • Also just noticed this issue, went looking if it’s indeed by ACF. Hope this gets fixed very soon, as I now can’t continue developing a website.

  • Hi,
    I’m having the same issue … argh!
    Please… somebody got a solution?
    THANK’S VERY MUCH

  • We’re investigating this issue at the moment. We’ll have an update for you shortly.

  • I can confirm that rolling back to 5.9 manually solves this problem.

  • Hello,
    I’m having the same issue.
    I am currently using WordPress 5.9.1 / ACF PRO 5.11.4.
    The media library breaks only when I try to edit a page that already has an ACF Block including image field.

  • This issue seems to be happening because the REST API endpoint preloading is somehow satisfying the enqueues, meaning they don’t happen to the block editor itself.

    As a quick fix, something like this will work:

    [Removed – see updated code further down]

    But this might be a bit of a sledgehammer approach to solving the issue, but I wanted to get something over to you as soon as possible for those who wanted to stick on WP5.9.1

    We’ll keep digging into this though, and give a further update shortly.

  • The quick fix code doesn’t seem to work, I still have the same problem.

  • @lgladdy thanks for the quick fix. Seems to be working for now.
    @hekscd maybe you have to change the $remove_path from posts to pages, if you’re using pages…

  • @thorben Still get the same error when changing:
    $remove_path = '/wp/v2/posts/' . get_the_ID() . '?context=edit';
    to:
    $remove_path = '/wp/v2/pages/' . get_the_ID() . '?context=edit';

  • In my case the above solution didn’t work.
    Still, there were changes.

    A JavaScript error message appeared on the console as soon as the media library was launched.
    After I put the above code in my functions.php file,
    Now I got the exact same error message when clicking a picture that is shown in the media library.
    The error message is “Uncaught TypeError: Cannot read properties of undefined (reading ‘removeAllPlayers’) at n.render (media-views.min.js?ver=5.9.1:2:91463)” .

    And the media library looks just like its style.css file is gone. The layout is completely broken and is located in the corner of the screen. This is the same before and after applying this code.

    I have to release the site to the public tomorrow, but this happened yesterday, so I am in a very difficult situation right now.
    Hope someone can solve this problem.

  • @thorben Still get the same error, too. And I’m having the same issue on both posts, pages.

  • @thorben Nice catch, I forgot about context. I’ll look up the code WordPress uses to add that URL and clone that, custom post types will be different too.

    function acf_filter_rest_api_preload_paths( $preload_paths ) {
    	global $post;
    	$rest_path   = rest_get_route_for_post( $post );
    	$remove_path = add_query_arg( 'context', 'edit', $rest_path );
    
    	return array_filter(
    		$preload_paths,
    		function( $url ) use ( $remove_path ) {
    			return $url !== $remove_path;
    		}
    	);
    }
    add_filter( 'block_editor_rest_api_preload_paths', 'acf_filter_rest_api_preload_paths', 10, 1 );

    That said, if this still isn’t working for you – don’t worry – we’re still actively working on the issue to see if there are cases where this isn’t working.

  • @bpcdpc You can drop back to WordPress 5.9 if need be! That will solve the issue for now – and disable automatic updates.

    We’re working to get this fixed ASAP though.

  • Our current solution is the following:

    
    function acf_filter_rest_api_preload_paths( $preload_paths ) {
      if ( ! get_the_ID() ) {
        return $preload_paths;
      }
      $remove_path = '/wp/v2/' . get_post_type() . 's/' . get_the_ID() . '?context=edit';
      $v1 =  array_filter(
        $preload_paths,
        function( $url ) use ( $remove_path ) {
          return $url !== $remove_path;
        }
      );
      $remove_path = '/wp/v2/' . get_post_type() . 's/' . get_the_ID() . '/autosaves?context=edit';
      return array_filter(
        $v1,
        function( $url ) use ( $remove_path ) {
          return $url !== $remove_path;
        }
      );
    }
    add_filter( 'block_editor_rest_api_preload_paths', 'acf_filter_rest_api_preload_paths', 10, 1 );
    

    but it seems that lgladdy`s version above works as well

  • Is the autosaves required for you @dominik_fuchshofer? I’ve not come across autosaves having any issues in my testing, but we can add it if need be.

    Edit: I think autosaves would actually cause more problems than it would solve as it’s used by the block editor.

  • It works for me now on a couple sites I’ve tried it on.

  • Thanks @dominik_fuchshofer
    this seems to be working for us as well – without the autosaves part.

  • Just an quick update, this issue will work – but as @dominik_fuchshofer suggested, if there is a current autosave it will still be broken.

    We’ll need to do some more internal code changes to handle autosaves – but disabling them as Dominik’s code should solve the issue for now, while we can get the release ready.

    Could you try the following code, and see if you have any issues?

    function acf_filter_rest_api_preload_paths( $preload_paths ) {
    	global $post;
    	$rest_path    = rest_get_route_for_post( $post );
    	$remove_paths = array(
    		add_query_arg( 'context', 'edit', $rest_path ),
    		sprintf( '%s/autosaves?context=edit', $rest_path ),
    	);
    
    	return array_filter(
    		$preload_paths,
    		function( $url ) use ( $remove_paths ) {
    			return ! in_array( $url, $remove_paths, true );
    		}
    	);
    }
    add_filter( 'block_editor_rest_api_preload_paths', 'acf_filter_rest_api_preload_paths', 10, 1 );
  • @lgladdy we had to exclude autosaves on the “post” post-type as well, otherwise we still got errors. Without the autosave portion it only worked on the “page” post-type.

Viewing 25 posts - 1 through 25 (of 38 total)

You must be logged in to reply to this topic.