Provide an update path for the updated media image upload plugin ID

Thank you @tstoeckler!

The code looks good to me, and I have manually tested that an existing browser is correctly migrated to use the new ID, so say a field widget using the old EB will start using the new one.

I was under the impression that we should implement hook_update_dependencies() to ensure this update hook runs after the media_entity ones, but in fact the code here doesn't interact with the new API in any way. Actually while testing, I had them run in this order:

The following updates are pending:

entity_browser module : 
  8201 -   Updates entity browsers to use the new media image upload widget plugin. 

media_entity module : 
  8200 -   Clears the module handler's hook implementation cache. 
  8201 -   Replace Media Entity with Media. 

Do you wish to run all pending updates? (y/n): y
Performing media_entity_update_8200                                             [ok]
Performing entity_browser_update_8201                                           [ok]
Performing media_entity_update_8201                                             [ok]
Cache rebuild complete.                                                         [ok]
Finished performing updates.                                                    [ok]

and everything worked just fine.

Looks good to me!

+++ b/entity_browser.install
@@ -91,3 +91,26 @@ function entity_browser_update_8002() {
+      if ($widget['id'] === 'media_entity_image_upload') {
+        $widget['id'] = 'media_image_upload';
+        $widget['settings']['media_type'] = $widget['settings']['media_bundle'];
+        unset($widget['settings']['media_bundle']);
+        $changed = TRUE;

Should we be checking if the core media module is enabled before switching people over?

In theory the 2.x branch shouldn't be used with ME 1.x :

function entity_browser_requirements($phase) {
  $requirements = [];

  // This branch of Entity Browser shouldn't be used with core < 8.4.x or with
  // media_entity 1.x enabled.
  $incompatible = FALSE;
  $drupal_version = explode('.', \Drupal::VERSION);
  if ($drupal_version[1] < 4) {
    $incompatible = TRUE;
  }
  elseif (\Drupal::moduleHandler()->moduleExists('media_entity')) {
    $info = system_get_info('module', 'media_entity');
    if (version_compare($info['version'], '8.x-2') < 0) {
      $incompatible = TRUE;
    }
  }

  if ($incompatible) {
    $requirements['entity_browser_media'] = [
      'title' => t('Entity Browser'),
      'value' => t('This branch of Entity Browser is not compatible with the version of Media Entity installed.'),
      'description' => t('This branch of Entity Browser is not compatible with the version of Media Entity installed.'),
      'severity' => REQUIREMENT_ERROR,
    ];
  }

  return $requirements;
}

So the only scenario I can think of that being possible, is:
1) Site upgrades to media in core (keeping EB 1.x)
2) Site disables media
3) Site upgrades EB to 2.x

Not sure if we should bother with that though?

@marcoscano So hook_requirements only gets run on install, right? So if I was on media_entity and Entity Browser 1.x, then upgraded to Entity Browser 2.x, that hook would never be run, but the update hook would run which would break all of my existing widgets.

So if I was on media_entity and Entity Browser 1.x, then upgraded to Entity Browser 2.x, that hook would never be run

I don't think so, if I'm not mistaken hook_requirements() will always run before any hook_update_N(), passing 'update' as the $phase param.

Once in our implementation we are disregarding $phase, it means our requirement is checked always: on install, on DB updates, and when a user visits the status report page. So the scenario of a M.E. 1.x with E.B 2.x would only exist if a user upgraded the codebase and did not run the DB updates, which is a state the user cannot expect everything to work properly :)

Edit: We are using this same mechanism in M.E. 2.x to prevent upgrade if certain conditions are not met, and it successfully aborts the DB updates if the requirements are not OK.

Thanks for the clarifications. Fixed!