Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
In order to remove backbone form contextual we need to deprecate and mark the public API of contextual links as internal.
Steps to reproduce
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
The JavaScript API for Contextual module has been marked internal, and various parts of this will be refactored and/or removed in Drupal 10. Contributed modules should interact with contextual module only via the PHP API.
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | 3277311-12-d10.patch | 8.53 KB | lauriii |
| |||
Issue fork drupal-3277311
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:
- 3277311-deprecate-and-mark
changes, plain diff MR !2170
1 hidden branch
Comments
Comment #3
nod_Comment #4
Wim LeersI can't find a single detail wrong with this: neither with the MR nor with the draft change record.
I had to look up the docs for
Drupal.deprecatedProperty, because there is only one use of it in HEAD so far (user.es6.js).Having read the change record that introduced it (https://www.drupal.org/node/3082634), this is AFAICT correct 👍
Comment #5
lauriiiIs there a particular reason we are not triggering warnings for the deprecated properties in
Drupal.contextualToolbar?From release management perspective, should we say that the API will be private/internal from 10.0.x instead of saying that it will be removed? This would also make it clear what is needed when these comments are being removed.
Comment #6
nod_My thinking that since we say
Drupal.contextualToolbaris internal and we couldn't find any code in contrib that extends 'model' (and all the backbone stuff for contextual), it'd be fine like this.Comment #7
nod_about removal, I don't mind either way. starting with 10.x nobody should rely on it. Saying we remove them would allow us to clean up everything at once instead of doing it over 10.x and 11.x
The fact that we couldn't find any contrib module extending any of this I'm thinking we can make our lives simpler.
Comment #8
Wim LeersI agree with #6.
The intent for 100% of the Backbone-based JS functionality was always to make it possible for contrib/custom code to listen to model changes — that was the only API.
Comment #9
larowlanSimilar thoughts, the api was the event, so not fussed either way
Comment #10
catchI think #6 is reasonable too, always a bit borderline for things that should have been internal from the beginning that we also want to remove without any replacement. Going to move back to RTBC since I think @lauriii's feedback has been answered OK.
Comment #11
catchTrying to add a release note.
Comment #12
lauriiiHere are the changes from MR rerolled for D10.
Comment #17
lauriiiCommitted 68f22f8 and pushed to 10.0.x. Also committed the MR to 9.5.x and cherry-picked to 9.4.x. Thanks!
Comment #20
Wim LeersPublished the change record.
Comment #21
xjmThe CR here is a little thin -- maybe we could provide a list of the deprecations in it?
Comment #22
nod_added the list of deprecated JS objects to the change notice
Comment #23
longwaveChange record looks OK to me now.