Problem/Motivation

The machine names generated by views would benefit from being easier to remember their purpose.

block_1
block_2

vs

block_active_forum_topics
block_new_forum_topics

Proposed resolution

Generate the new display's machine name from the display_title prefixed by the display type, then suffixed by an incremental number if necessary.

This patterns is used for fields and blocks and likely a few other things, it would be nice to apply it to views displays as well.

Remaining tasks

User interface changes

n/a

API changes

Follow-up from #2020387-64: Convert "Active forum topics" block to a View.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

sun’s picture

+1 — Especially because these IDs sometimes need to be referenced in other code and also appear in the UI.

tim.plunkett’s picture

Status: Needs review » Active

As someone who always changes these machine names before saving anyway, this might save me some time, and sure won't hurt, so +1

There's no patch yet.

dawehner’s picture

What about enforcing that the ID gets prefixed with the display plugin name?

sun’s picture

If that means "block_" for block displays, "page_" for page(?) displays, and "feed_" for feed displays, +1

dawehner’s picture

The current UI does not really use the same pattern as other machine names, because the adding UI is totally different from the EDIT UI, so we have to ensure that we don't accidentally change the ID..

joelpittet’s picture

Assigned: Unassigned » joelpittet

Cool glad to see you guys are in favour of the idea. I'm sure you are busy with tons of other issues so I'll assign this to myself, and stab at this for a few and see if I get anywhere. If I'm nowhere in a couple hours I'll unassign and run away:)

joelpittet’s picture

Assigned: joelpittet » Unassigned
Status: Active » Needs review
FileSize
5.74 KB

Well I made some headway but ran into a few snags and just learning my way around some form api/views.

I moved a #type=>machine_name field to the views admin title ui and added exists() method to DisplayPluginBase.

Maybe someone can point me in the right direction or take a stab at it themselves?

Status: Needs review » Needs work

The last submitted patch, 7: 2269711-views-display-auto-nice-machine-names-7.patch, failed testing.

dawehner’s picture

--- a/core/modules/views/lib/Drupal/views/Plugin/views/display/DisplayPluginBase.php
+++ b/core/modules/views/lib/Drupal/views/Plugin/views/display/DisplayPluginBase.php

You certainly forgot to adapt submitOptionsForm

joelpittet’s picture

Thanks at @dawehner, that was quite obvious when I look in the right spot, I appreciate the pointer!

So now a questions:

  • Is there a way to tell if a View has just been created ($view->isNew()?) but not saved so that I can let the display name freely generate a machine name from the admin title?
  • Would it be ok if I moved the machine name with the display title permanently instead of being in the "other/advanced" pile in the UI?
  • Do I need some trick to get the machine_name JS for mirroring the label text to fire?
  • Can the default be 'page' and 'block', instead of 'page_1' and 'block_1'?

Sorry, I'm much better at fixing twig templates, preprocess and attributes...

dawehner’s picture

I don't have time for a review now, but -1 to not use the page_1 by default.

Status: Needs review » Needs work

The last submitted patch, 10: 2269711-views-display-auto-nice-machine-names-10.patch, failed testing.

tim.plunkett’s picture

+++ b/core/modules/views/lib/Drupal/views/Plugin/views/display/DisplayPluginBase.php
@@ -1407,6 +1408,23 @@ public function buildOptionsForm(&$form, &$form_state) {
+            'source' => array('display_title'),

This should be array('options', 'display_title')

That's not clear from looking at this class, but in actuality the whole method is originally called in \Drupal\views_ui\Form\Ajax\Display::buildForm like this: $executable->display_handler->buildOptionsForm($form['options'], $form_state);

This will eventually be improved by #2065485: Document that PluginFormInterface should use #process to solve nesting issues

Also, +1 for starting with page_1.

dawehner’s picture

Also, +1 for starting with page_1.

High five!

joelpittet’s picture

Version: 8.0.x-dev » 8.1.x-dev
dawehner’s picture

Even one year later, Ideally I would still love to be able to remove the machine name feature from the UI at least.
Its just not clear how much you can destroy when you rename a display ID, just think about CSS but also references to that display in code etc.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

joelpittet’s picture

@dawehner I kind of see your point for removing it form edit, though you may have made a typo shortly after creating it, in which case you may want to fix the typo (seems to happen lots to me and my colleagues). From UX I'd put a warning though instead,

"When renaming make sure references in CSS, blocks or in other parts of code are updated accordingly, generally recommended to avoid renaming after creating this display"

I think creating semantic names on creation should be encouraged.

joelpittet’s picture

Status: Needs work » Needs review
FileSize
2.35 KB

Ok, removed the UI changes to the DisplayPluginBase because I don't want it to look easier to change the display_id and leave it in the admin to @dawehner's point.

This change is only in the wizard. There looks like there is a bug in machine-name.js that this introduces but it still works. Just initializes as [Object object], yet still replaces as you type which is likely because I tried default the display titles.

Status: Needs review » Needs work

The last submitted patch, 21: 2269711-21.patch, failed testing.

joelpittet’s picture

Status: Needs work » Needs review
FileSize
2.31 KB

Reroll

Status: Needs review » Needs work

The last submitted patch, 23: 2269711-21-reroll.patch, failed testing.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.