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
Rip out \Drupal\views\Entity\View::label() and rely on the parent method.Deprecate the logic inView::label()
and trigger a deprecation error whenever the fallback logic is executed- Update all test views to ensure they have labels (this is ridiculously tedious -- there's over 100 of them).
- 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.
- Change the config schema for view entities (
views.view.*
) so that thelabel
property uses the newrequired_label
data type, added in #3341682: New config schema data type: `required_label`.
Remaining tasks
- ✅ Deprecate the logic in
View::label()
and trigger a deprecation error whenever the fallback logic is executed - ✅ Update all test views to ensure they have labels (this is ridiculously tedious -- there's over 100 of them).
- ✅ 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.
- ✅ Change the config schema for view entities (
views.view.*
) so that thelabel
property uses the newrequired_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
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:
Comments
Comment #3
phenaproximaPostponing this on #3341682: New config schema data type: `required_label`.
Comment #4
Wim LeersPer @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:
View::label()
(+ trigger a deprecation error: )… all in a single issue: THIS issue. That'd definitely make it a more coherent change.
Comment #5
Wim LeersUpdating the issue summary to make it clear which parts this MR already does vs does not yet do. Also linking issues.
Comment #6
lauriiiThe blocked has been committed.
Comment #7
phenaproximaComment #8
phenaproximaComment #9
Wim LeersLooking 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.
Comment #10
phenaproximaComment #11
Wim Leers👍
No more remarks!
Only remaining blocker: subsystem maintainer review 😊
Comment #12
dwwI'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
Comment #13
tim.plunkettThis is fine from a Views perspective. Sorry for the 100s of test views, seeing all those brings back memories :D
Comment #14
dwwGood point on the behavior of
\Drupal\views\Entity\View::label()
. In that case, withdrawing my concern and moving to RTBC.Thanks again,
-Derek
Comment #15
Wim LeersSorry? 😅😁
Comment #16
lauriiiLooks mostly good. Posted one comment regarding the upgrade path 😇
Comment #17
phenaproximaComment #18
Wim LeersI was confused by the last commit, which didn't actually move the logic to
hook_ENTITY_TYPE_presave()
.Then I learned
views_view_presave()
callsViewsConfigUpdater
since #2989745: views_update_8500() inlines configuration changes instead of this being done on config save for bc, then it made sense 😄👍Comment #20
quietone CreditAttribution: quietone at PreviousNext commentedI'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.
Comment #21
borisson_Both changes make sense and look good,back to rtbc.
Comment #22
effulgentsia CreditAttribution: effulgentsia at Acquia commentedSaving issue credits.
Comment #24
effulgentsia CreditAttribution: effulgentsia at Acquia commentedThis 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:
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!
Comment #25
effulgentsia CreditAttribution: effulgentsia at Acquia commentedThis seems like something worth mentioning in the release notes as well.
Comment #26
phenaproximaOpened the follow-up: #3390127: Rephrase the deprecation notice that is raised when calling the label() method of a view without an explicit label