Discussion: Expose a path field for media entities

What is not nice enough about these?

 *   links = {
 *     "add-page" = "/media/add",
 *     "add-form" = "/media/add/{media_type}",
 *     "canonical" = "/media/{media}",
 *     "delete-form" = "/media/{media}/delete",
 *     "edit-form" = "/media/{media}/edit",
 *     "admin-form" = "/admin/structure/media/manage/{media_type}"
 *   }

Or do you propose we DO NOT have a canonical path at all?

Oh wait, you mean integrate with path module if it exists? Should path integrate with media or media integrate with path? I found this in path module, but it does not make it clear how is the underlying form built.

/**
 * Implements hook_form_BASE_FORM_ID_alter() for \Drupal\node\NodeForm.
 */
function path_form_node_form_alter(&$form, FormStateInterface $form_state) {
  $node = $form_state->getFormObject()->getEntity();
  $form['path_settings'] = array(
    '#type' => 'details',
    '#title' => t('URL path settings'),
    '#open' => !empty($form['path']['widget'][0]['alias']['#value']),
    '#group' => 'advanced',
    '#access' => !empty($form['path']['#access']) && $node->hasField('path') && $node->get('path')->access('edit'),
    '#attributes' => array(
      'class' => array('path-form'),
    ),
    '#attached' => array(
      'library' => array('path/drupal.path'),
    ),
    '#weight' => 30,
  );
  $form['path']['#group'] = 'path_settings';
}

Looked around a bit. My initial reaction was "but media is more attached data than data on its own" at least in terms of public usage. Like if your media is a slideshow of things, it will be displayed on a page with other things. If your media is an embedded video or images, it will be embedded with ckeditor or as fields, etc. In ways similar to taxonomy terms. So I looked at the taxonomy term form and boom, that has a URL path field also. Haha.

Tagging usability sprint also, that may help with some feedback.

I think terms are much more public than media items, so it totally makes sense to have a path field there, not sure about media.

Also, pathauto actualy has generic integration for any entity type with a canonical link template to automatically expose a path field and provide patterns. So people who use pathauto (which is many I guess) get it anyway.

I think it generally makes sense to expose this? At the end its an item, like any other - that can be reached.

@dawehner, @Bojhan: ok, so this would be something like the attached then? It exposes the URL alias field, so it would show up like in the taxonomy term form. Should we fold this in #2831274: Bring Media entity module to core as Media module or maintain it here for a followup?

The result of the patch is:

Yhea, although the description should be more localised to this data.

@Bojhan: I had the same observation when looking at the existing taxonomy term form in core:

Turns out that element description is hardcoded in the PathWidget class, and is not even a widget setting for path widgets:

    $element['alias'] = array(
      '#type' => 'textfield',
      '#title' => $element['#title'],
      '#default_value' => $path['alias'],
      '#required' => $element['#required'],
      '#maxlength' => 255,
      '#description' => $this->t('Specify an alternative path by which this data can be accessed. For example, type "/about" when writing an about page.'),
    );

So seems like that could only be made to work with feature development on the path widget itself. Question is if we want to block this issue on that or not.

I see there is definitely a use case to expose media items on specific paths, but when a user creates a media item from the library or the field widget, they just want to embed and might not care about the page for that item.

Exposing the path field there could be confusing for the user. This is something to think about (although this could be a followup). Most users will probably use media items like they use files.

@seanB: I think we can use form modes for this, a mode for the standalone media editing screen and one for the media library and then people can adjust field which fields they want to see exposed in each form.

IMHO we should not block it

Agree. Thank you! Here's the patch on follow-up #2842047-2: Don't hardcode the description in PathWidget
// Naveen

So making the URL alias field description specific to the kind of entity is blocked on #2842047: Don't hardcode the description in PathWidget. Otherwise, the usability feedback needed was given.

Please proceed with adding the URL alias field, with its hardcoded description for now :)

I'll work on bringing this back to the #2831274: Bring Media entity module to core as Media module patch then once there are no multiple competing directions where changes like this could fall between the cracks.

Just folded this into the media patch at #2831274-288: Bring Media entity module to core as Media module.