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.
Idea summary
What is the problem to solve?
Make core more maintainable by removing old and unmaintained modules that aren't commonly used.
Who is this for?
Core contributors and new Drupal users who don't understand why we shipped a module with core that looks like a couple of Views.
Result: what will be the outcome?
Tracker module is unloved and installed on less than 3% of sites according to #3158669: By default deprecate non-experimental modules that are used by less 5% of sites before the next major version
There has been no listed maintainer since #1854480: Remove inactive maintainers from MAINTAINERS.txt (committed in 2017)
How can we know the desired result is achieved?
The module is moved to contrib
Comment | File | Size | Author |
---|---|---|---|
removetracker.patch | 38.75 KB | RobLoach |
Comments
Comment #1
timmillwoodCan everything in tracker be done by views?
If so, remove it.
Comment #2
Damien Tournoud CreditAttribution: Damien Tournoud commentedTracker is a nice feature out of the box, and a nice candidate for denormalization. It has very few bugs and is not a maintenance burden. Let's keep it.
Comment #3
catchI agree with Damien. The denormalization can't be handled by views yet.
Comment #4
sunComment #5
mitchell CreditAttribution: mitchell commentedCould we postpone this until the #286665: SEE ISSUE #1805996 -- Moving Views into Drupal Core starts to materialize (notice what I did there?)? The tracker feature requests includes an API change in #366511: Decouple Comment module from Tracker and improvements that seem to be best handled by Views and #28480: Create generalized relationship module.
Re: denormalization
@Damien: Would you please update this issue with respect to #1497374: Switch from Field-based storage to Entity-based storage and your London Core Conversation on Document Oriented Storage where you spoke about how MV (see also Materialization Plugin for Views) could be consistently used for denormalization in relational databases?
Comment #6
mitchell CreditAttribution: mitchell commentedAccidental tag change. Sorry, sun :)
Comment #7
mitchell CreditAttribution: mitchell commentedReopening now that #1805996: [META] Views in Drupal Core is committed and #1801726: EntityFieldQuery v2 includes optimizations for table joins.
Perhaps a combination of #1803064: Horizontal extensibility of Fields: introduce the concept of behavior plugins and entity storage backends through #1497374: Switch from Field-based storage to Entity-based storage would offer potential for denormalization.
Also, I'm not sure how #1801304: Add Entity reference field may be related, but linking for good measure.
Edit: also meant to link to #1740492: Implement a default entity views data handler.
Comment #8
NaheemSays CreditAttribution: NaheemSays commentedInstead of remobing tracker maybe either changing it or replacing it with a glorified flag module?
then the tracker view can be a ... view of a specific type of flag (which can be added by default as an action...).
Comment #9
RobLoachWhat would be required in order to replace Tracker with Views? Replace the individual queries that Tracker performs with Views pages?
Comment #10
catchTracker also provides two tables for denormalization and views integration for them. To replace that with views would mean the materialized views views (sic) integration being fixed up and added to core.
Comment #11
xjmYeah, I'd prefer to do #1941830: Convert tracker listings to a view for D8, and then we could consider removing Tracker and ilk in D9 in favor of an "MV in core" solution. (I swear we have a core issue for that somewhere, but I can't find it atm.)
Comment #12
catchComment #13
yoroy CreditAttribution: yoroy at Roy Scholten commentedMaybe this issue needs a different title? Discussion tends towards how to reproduce Tracker with Views.
Comment #14
NaheemSays CreditAttribution: NaheemSays commentedThe alternative may be to take the module in the opposite direction.
Tracker is a special flag. Making it more generic so that it can be used for other flagging needs (or replacing with flag module) may introduce useful functionality in core.
Comment #15
yoroy CreditAttribution: yoroy at Roy Scholten commentedSome rough usage data: #2867597: Top Drupal 7 and Drupal 8 core sub-modules
Adding the "idea template" to the issue summary. Short answers to the 4 questions will help us compare and weigh ideas for their relative impact. Thank you!
Comment #16
joachim CreditAttribution: joachim as a volunteer commentedThere is a replacement module in contrib already: https://www.drupal.org/project/trackerlite
Comment #17
andypostMaybe instead of conversion tracker to views we can add this views to comment module?
@catch pointed that tracker makes no sense without comment & history modules in #366511-94: Decouple Comment module from Tracker
Comment #18
larowlanComment #19
larowlanComment #20
andypostI bet it was a typo
Comment #21
catchRevisiting #1261120-3: Deprecate Tracker module in D10 and move to contrib in D11. We added denormalisation to tracker in #105639: Tracker performance improvements, but have got no closer to making that generic. The closest is https://www.drupal.org/project/mv which is abandoned. Generic denormalisation for views and entity queries would still be nice to have, but tracker isn't helping us get there at all.
Meanwhile there are issues like #2875033: Optimize joins and table selection in SQL entity query implementation which would improve performance of our existing queries.
#1941830: Convert tracker listings to a view has been open for eight years, tracker is still defining routes manually and building tables in controllers - it's a very bad example of how to build an entity listing.
For people that need a similar feature, you can build exactly the same feature in views (without the denormalization) using only core, or they could install the contrib project, or build slightly different listings of user content/comments.
Comment #22
catchComment #23
Gábor HojtsyBased on all the discussion above and in #3158669: By default deprecate non-experimental modules that are used by less 5% of sites before the next major version, I agree tracker would be good to move to contrib. It is among the modules that provide a one-off feature that does not have an ecosystem (stuff built on top of it) in contrib and does not serve as a base service that contribs could share an implementation of.
Comment #24
andypostWhat is the next step to deprecate tracker?
Comment #25
catch@andypost we'd need someone to create a contrib project for it, and tag a release.
Should also have a patch that removes it to check if there's any test coverage that depends on it being installed.
Comment #26
naveenvalechaI have created an issue #3261452: [11.x] Remove tracker module from core to deprecate and try to remove the module
Comment #27
naveenvalechaI have created a new contributed project for the tracker module https://www.drupal.org/project/tracker and pushed the codebase into 1.0.x branch
@andypost I have added you as a maintainer of it
Comment #28
jibranWe should set up a date to move tracker bugs from core to the tracker module queue.
Comment #29
catchSince this has been approved and there's a contrib maintainer and project (thanks naveenvalecha and andypost!), I think this is.. RTBC?
Comment #30
dwwThis all sounds good to me. +1 for removing and +1 for RTBC to this task.
Comment #31
dwwMaybe I missed it, but if this is just the "Idea" that's now RTBC, I only see #3261452: [11.x] Remove tracker module from core for the D10 removal issue. Should we convert this issue into the D9-mark-deprecated issue, or spin off a child issue for that?
Comment #32
naveenvalechaWe have a separate issue for d9 deprecation https://www.drupal.org/project/drupal/issues/3261679
Comment #33
xjmWe'll have to update the scope of this to be for D10 deprecation and D11 removal, but we can mark the Idea issue fixed. :)
Comment #34
xjm