Show machine name in "Manage form display" and "Manage display" table row

Works fine to me!

applied the patch and it works as expected, find this very useful

@christyanpaim, Welcome to Drupal! There are many steps needs to be done before a change can be RTBC. A place to start is the Contributor tasks, there is one for the Review a patch or merge request process.

I am restoring the remainder of the standard issue template so we can keep track of the work to be done on this issue. Tagging for an update though for the sections to be completed.

This is making changes to the UI so it needs to pass the Usability core gate, adding tag. Tests are needed, adding tag. Once there is direction supplied from the good folks in #ux and a working patch, this will need before and after screenshots in the Issue Summary.

To keep consistency between all Field UI tabs, I suggest we add the Machine name column to Manage form and Manage display tables.

I have not found any existing tests related to table headers or table rows' columns thus I have not added new tests. I guess it is not even necessary to check if this column exists 🤷. If so, please feel free to remove the "Need tests" tag from this issue. If not and we want tests, please help find where I should add such a test.

See attached MR !7612

Capture of the Manage form display with the new Machine name column:

Was previously tagged for issue summary update which will need to happen.

As for the tests ManageDisplayTest.php seems like a perfect spot to me. Don't see a test case that perfectly matches so probably could just start a new one.

Removing "Need tests" tag as relevant test was added to ManageDisplayTest.php.

Pending code review, issue summary update and usability review

Issue summary updated.

Marking as NR for Usability and Core reviews.

It's a good idea!

+1 for me.

It's an interesting idea and would save some time as one starts theming an entity.
Does it need to be there all the time? Maybe not, but it would be great to have it as a development option or have the ability to unhide it from somewhere on that table. Kind of hidden in plain site per se.

Love this. Added a note about test efficiency to the MR. I don't think we need a whole new test (and therefore, complete install of Drupal) for 2 assertions. 😅 Let's move these into an existing test to save time / CO2 / DA $.

Otherwise, seems like a win to me, and probably very close to RTBC.

Thanks!
-Derek

Looking at the rest of core/modules/field_ui/tests/src/Functional/ManageDisplayTest.php makes me cringe. Wow that's a lot of separate (tiny) test methods. 😢 Obviously out of scope to refactor all of this, but probably worth a follow-up.

That said, I'm not sure what I'd suggest for this issue, so maybe adding a new test method is fine. Restoring NR, but it smells a little fishy to me. 😅

Hiding the patches

Left some comments. Would agree that this could be a follow up for refactoring but think a good task would be to repurpose testSingleViewMode() into testManagerDisplaysInterface or something. Take the comment of the test now "Tests hiding the view modes fieldset when there's only one available." and make it a comment in the test. And obviously update the existing test description.

Thank you for your reviews. I've updated the tests/assertions. Hoping it is acceptable now.

Marking this issue as NR.

Applied a small name change to the test.

Rest seems fine to me so +1 but will still need usability.

What if Instead of having it's own column it displays as an html subscript <sub>?

Idk if it needs it's own column since it could be attached under the label for the field.</sub>

Like the idea as we know the machine name will be limited length. May want to wait for UX though. Posted in #ux in slack if anyone frees up

Having a separate column makes it easier to visually scan labels and machine names. I suppose there are pros and cons to both ways.

Usability review

We discussed this issue at #3441951: Drupal Usability Meeting 2024-04-26. That issue will have a link to a recording of the meeting.

For the record, the attendees at the usability meeting were @benjifisher, @BlackBamboo, @rkoller, @skaught, and @worldlinemine.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

In general there was a clear consensus that it is convenient to have the machine name right in place. We've considered the point raised in a corresponding discussion in the #frontend channel on the Drupal slack that the Manage fields page is already providing the machine names. But on the other hand on the Manage form display page as well as the Manage display page you not only have the machine names for fields but also those for base fields. The machine names for base fields are harder to obtain, requiring turning on the debugging and using some sort of dump() function according to @mariohernandez. With the MR in place the machine names for base fields are available as well. So you don't have to switch in-between tabs/pages or open a second browser window anymore.

We've also considered the suggestion raised by @bernardm28 in #28 moving the machine name from a dedicated column to the label column and display it as an html subscript (plus some aria as he added on the corresponding thread on Slack). That might save one column and horizontal screen real estate but on the other hand moving the machine name as a subscript underneath the label might entail other problems. The subscript would have to be labeled (not only by aria for screenreader users but also for sighted users) and just moving vertically through a column would announce the label and the machine name in a row for each cell. If a screenreader user just wants to get the machine names announced that would be difficult, since the label would always be prepended. So having a dedicated column for machine names requires a bit more horizontal screen real estate, but it is clearer, easier scan-able and less error-prone in particular for screen reader users. Each column is holding specific information and the user is able to navigate by keyboard deliberately retrieving the desired information.

We've also taken a look on mobile view ports in combination with extra long labels and machine names. The machine names are getting wrapped same as labels.

So overall we have no concerns with the MR and it looks good to go from our perspective. I'll remove the needs usability review tag again. The only thing I am unsure about is which status should be set. Since the code review task is not crossed of yet i'll leave the status at needs review.

Thanks @rkoller and usability team.

All the feedback on the MR has been addressed and is functioning. Test coverage is also there. Believe this is good to go.

Crediting usability meeting participants.

Saving other credits as well.

There is a comment that should be changes to be correct. Setting to needs work.

The issue summary has an open item for needing a code review. This was pointed out in #28 as well. Has there been a code review?

Tests are failing.

As a usability fix and UI change this is too late for 10.3.0 now we are in RC, but it is still eligible for the beta phase of 11.0 and also for 10.4.

I don't think failures are related to this code.

All errors seem to be related to something broken in Umami.

Example of a current failure: https://git.drupalcode.org/issue/drupal-3306820/-/jobs/1721378

It's a shame to miss a minor version 10.3 because of an unrelated broken part 😓.

How should I proceed to move this issue along?

Recommend rebasing

Sorry I'm not sure.

Rebasing `issue/drupal-3306820:3306820-show-machine-name` over `11.x` ?

This gives a 2k files conflict.

Need to rebase with origin/11.x

Current MR is 300+ commits behind which may address the failures

Rebased seemed to address the unrelated failures.

Test name appears to be updated.

Code changes make sense for the task being updated.

As a usability fix and UI change this is too late for 10.3.0 now we are in RC, but it is still eligible for the beta phase of 11.0 and also for 10.4.

Actually, it's a UI change, so not beta-eligible for 11.0. Also, UI changes aren't eligible for maintenance minors, which 10.4 is. So I think this is an 11.1 change.

I manually tested this and noticed something that I think needs work:

When you compress the screen to a smaller size, before it hits the breakpoint where the new column would be hidden, the machine names start to wrap, which is something machine names shouldn't do.... but what's worse, it automatically hyphenates the machine names, which is definitely way confusing, because it makes you think the hyphens are a part of the machine name.

So, I think we need to change the word-break or word-wrap behavior for the column, and ensure the column is hidden when some reasonable length of machine name does not fit, and that exceptionally long machine names are elided somehow (which I vaguely remember seeing elsewhere in other issues). To suggest a solution, I went to the Manage fields page... and discovered it has the same problem. So, I filed #3455155: Fix word-wrapping behavior of machine names in UI tables.

Did not mean to NW since I filed the followup myself.

Committed to 11.x. Thanks!

@xjm, thanks for making the followup. It saves me chasing up 'needs followup' for fixed issues.

I like this change. Thanks everybody!

Just some notes:

• The columns gets even more tight when I click "Show row weights".
  I like to do this to manually set row weights to reduce noise in a git commit.
  But it is worth it imo.
• This needs work in field_group and possibly other contrib modules. Currently it looks broken with field_group enabled.
  Again, that's ok with me.
  But it deserves a note in the "API changes".

From a usability perspective:
In all the projects I ever worked on, the site builder who manages displays with field_ui is the same person who will then run "drush config:export" and commit the changes in git.
There is no point in hiding machine names from this person.

It could also be nice to have some kind of feature detection possibility, so that a module like field_group can support different versions.
Currently it could check if any field row has a cell key 'machine_name', but this is not 100% reliable if there are no fields for some reason.

Amending attribution.