Problem/Motivation

This was discovered while working on #3341682: New config schema data type: `required_label`.

Views have strange behavior for labels: if the entity itself has no label, the view's ID is used as the label. That's not great, because the ID might not be as useful or descriptive as a label. And more to the point, it's inconsistent with the UI -- when you create a view as a site builder, you have to enter a label.

Proposed resolution

  1. Rip out \Drupal\views\Entity\View::label() and rely on the parent method. Deprecate the logic in View::label() and trigger a deprecation error whenever the fallback logic is executed
  2. Update all test views to ensure they have labels (this is ridiculously tedious -- there's over 100 of them).
  3. Add an update path to add labels to all views which don't have one. For this case, we'll reuse the ID as the label.
  4. Change the config schema for view entities (views.view.*) so that the label property uses the new required_label data type, added in #3341682: New config schema data type: `required_label`.

Remaining tasks

  1. ✅ Deprecate the logic in View::label() and trigger a deprecation error whenever the fallback logic is executed
  2. ✅ Update all test views to ensure they have labels (this is ridiculously tedious -- there's over 100 of them).
  3. ✅ Add an update path to add labels to all views which don't have one. For this case, we'll reuse the ID as the label.
  4. ✅ Change the config schema for view entities (views.view.*) so that the label property uses the new required_label data type, added in #3341682: New config schema data type: `required_label`.

User interface changes

None.

API changes

Sort of? The View::label() method will no longer fall back to returning the view's ID. Not sure if that counts as an API change.
The View::label() method may trigger deprecation notices in Drupal >=10.2, and will remove its fallback behavior in Drupal 11.

Data model changes

Yes: views will require labels.

Release notes snippet

TBD

Issue fork drupal-3380480

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

phenaproxima created an issue. See original summary.

phenaproxima’s picture

Title: Views should require a label at the data layer » [PP-1] Views should require a label at the data layer
Status: Active » Postponed
Wim Leers’s picture

Title: [PP-1] Views should require a label at the data layer » [PP-1] Views should require a label, rather than falling back to an unhelpful ID
Category: Feature request » Task
Issue summary: View changes
Issue tags: +Configuration schema, +validation, +Needs change record

Per @lauriii's review at https://git.drupalcode.org/project/drupal/-/merge_requests/3690#note_200528, I reverted making views.view.*:label required from that merge request.

I think @lauriii is right that it'd be better to combine:

  1. making the label required
  2. deprecate the fallback logic in View::label() (+ trigger a deprecation error: )
  3. updating the default views + tests

… all in a single issue: THIS issue. That'd definitely make it a more coherent change.

Wim Leers’s picture

Updating the issue summary to make it clear which parts this MR already does vs does not yet do. Also linking issues.

lauriii’s picture

Title: [PP-1] Views should require a label, rather than falling back to an unhelpful ID » Views should require a label, rather than falling back to an unhelpful ID
Status: Postponed » Needs work

The blocked has been committed.

phenaproxima’s picture

Issue summary: View changes
phenaproxima’s picture

Assigned: Unassigned » Wim Leers
Status: Needs work » Needs review
Issue tags: -Needs change record
Wim Leers’s picture

Assigned: Wim Leers » phenaproxima
Status: Needs review » Needs work
Issue tags: +Needs subsystem maintainer review

Looking awesome!

Just 41 failures left, and only one real remark on the MR: the update path test coverage.

Once this is green, I think this only needs subsystem maintainer approval.

phenaproxima’s picture

Assigned: phenaproxima » Wim Leers
Status: Needs work » Needs review
Wim Leers’s picture

Assigned: Wim Leers » Unassigned

👍

No more remarks!

Only remaining blocker: subsystem maintainer review 😊

dww’s picture

I'm not formally a subsystem maintainer for Views, but I used to co-maintain D7 (and earlier) Views, and am unofficially a quasi co-maintainer for core... 😅

Overall, +1 to this change. The MR looks really good. Nice to see upgrade path so folks don't have to worry about this, and upgrade path tests so we know it works. Opened one perfect-is-enemy-of-the-good style review thread about the post_update implementation. Feel free to ignore it if y'all think it's too edge-casey to worry about.

Other than that, I think this is RTBC.

Thanks!
-Derek

tim.plunkett’s picture

This is fine from a Views perspective. Sorry for the 100s of test views, seeing all those brings back memories :D

dww’s picture

Status: Needs review » Reviewed & tested by the community

Good point on the behavior of \Drupal\views\Entity\View::label(). In that case, withdrawing my concern and moving to RTBC.

Thanks again,
-Derek

Wim Leers’s picture

Sorry for the 100s of test views, seeing all those brings back memories :D

Sorry? 😅😁

lauriii’s picture

Status: Reviewed & tested by the community » Needs work

Looks mostly good. Posted one comment regarding the upgrade path 😇

phenaproxima’s picture

Status: Needs work » Needs review
Wim Leers’s picture

Status: Needs review » Reviewed & tested by the community

I was confused by the last commit, which didn't actually move the logic to hook_ENTITY_TYPE_presave().

Then I learned views_view_presave() calls ViewsConfigUpdater since #2989745: views_update_8500() inlines configuration changes instead of this being done on config save for bc, then it made sense 😄👍

quietone made their first commit to this issue’s fork.

quietone’s picture

Status: Reviewed & tested by the community » Needs review

I'm triaging RTBC issues. I read the IS and the comments. I didn't find any unanswered questions.

I read the MR (not a review). Two things jumped out at me. One, the trigger error messages do not meet coding standards and 2) the new labels in the yml files are inconsistent some have single quotes and some don't. The first is a being fixed in #3048495: Fix Drupal.Semantics.FunctionTriggerError coding standard which is at RTBC and I would like to stop rerolling that. And the second also has an issue #2994928: Quote consistency in .info.yml files for Core modules that still requires work, but mostly because quotes aren't needed in yaml. I have rebased the MR and made changes for these two items.

Setting to NR so those changes can be reviewed.

borisson_’s picture

Status: Needs review » Reviewed & tested by the community

Both changes make sense and look good,back to rtbc.

effulgentsia’s picture

Saving issue credits.

  • effulgentsia committed 9a3156da on 11.x
    Issue #3380480 by phenaproxima, quietone, Wim Leers, lauriii, dww, tim....
effulgentsia’s picture

Status: Reviewed & tested by the community » Fixed

This issue makes a lot of sense and the MR looks great. Pushed it to 11.x and published the CR.

The only thing that looked a little off to me was:

   public function label() {
     if (!$label = $this->get('label')) {
+      @trigger_error('Saving a view without an explicit label is deprecated in drupal:10.2.0 and will raise an error in drupal:11.0.0. See https://www.drupal.org/node/3381669', E_USER_DEPRECATED);

I feel like either that message should be moved to happen when the view is saved or the message text should be word-smithed to make a bit more sense in the context of it getting triggered here rather than during the save operation. Could someone open a followup for discussing that? Thanks!

effulgentsia’s picture

Issue tags: +10.2.0 release notes

This seems like something worth mentioning in the release notes as well.

phenaproxima’s picture

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.