Contrib.social

[2.0.x] Roadmap

Open on Drupal.org →
Created on 4 December 2021, about 3 years ago
Updated 16 January 2023, almost 2 years ago

After looking at the current codebase and the remaining issues, I think the module architecture should be reworked to be extendable, more alterable and more OOP.

I propose to rework it around 2 plugin types.

Tracking activation control plugins (regarding comment 11, let's use the core condition plugin system and add the ones not present already):
- Pages
- Roles
- Users
- (See comment 9, should be in a dedicated project)

Tracking activation control plugins could maybe be reused for a Matomo Tag Manager module #2978703-12: Support Matomo Tag Manager → .

Tracking behavior plugins (new):
- Domain
- Page titles hierarchy
- Links and downloads: and also take #2904105: Add option to customize ignore classes for link tracking → into account
- Colorbox
- Messages
- Search
- Search API: #3082148: Cannot track search requests if not using default search module →
- Privacy
- JS before
- JS after
- Custom variables: also rework custom variables to be able to add as many variables as you want and not 5 max.
- 403/404: #3245705: Make tracking of 404/403 pages optional →
- User ID

Each plugin can declare:
- dependency on modules to be seen in the admin UI and active.
- permissions for admin UI access

Make this rework with the following issues in mind to see if possible to do it in the same time:
- #2948060: Implement twig template for tracking code customization → : plugins approach would cover this one too I think
- #3216010: Matomo js script insertion is too opinionated → : I wonder if this is not duplicating #2948060: Implement twig template for tracking code customization →
- #2595855: Make the tracking files (js, php) configurable →
- #3130324: Use "js/" instead of "matomo.js" →
- #3210239: The URL check on admin form validation is too restrictive →
- #3160567: Encourage users to choose a HTTPS only strategy →

TODO:
- implement plugins system
- convert existing code into plugins
- need to split matomo.admin.js for each plugins
- provide a mecanism to control plugins execution order? Like Search API processors
- rewrite matomo.js to have the colorbox part isolated and also maybe implement Drupal JS behaviors
- also maybe fire an event to alter Matomo code before rendering?
- create a new config entity type and convert matomo settings into this config entity so wa can support #3311301: Is it possible to report to multiple IDs? →
- update and add tests
- once everything will be ok, make upgrade path. Force to update on Matomo 8.x-1.x first, so we can drop Piwik update support?

🌱 Plan
Status

Active

Version

2.0

Component

Miscellaneous

Created by

🇫🇷France Grimreaper France 🇫🇷

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Assigned to maboy
  • Comment over 1 year ago →
    🇫🇷France maboy
  • Merge request !45Issue #3252606: [2.0.x] Roadmap → (Open) created by Grimreaper
  • Open on Drupal.org →
    Core: 10.1.x + Environment: PHP 8.1 & MySQL 5.7
    last update over 1 year ago
    Waiting for branch to pass
  • Open on Drupal.org →
    Core: 10.1.x + Environment: PHP 8.1 & MySQL 5.7
    last update over 1 year ago
    Waiting for branch to pass
  • Open on Drupal.org →
    Core: 10.1.x + Environment: PHP 8.1 & MySQL 5.7
    last update over 1 year ago
    Waiting for branch to pass
  • Open on Drupal.org →
    Core: 10.1.x + Environment: PHP 8.1 & MySQL 5.7
    last update over 1 year ago
    Waiting for branch to pass
  • Open on Drupal.org →
    Core: 10.1.x + Environment: PHP 8.1 & MySQL 5.7
    last update over 1 year ago
    Waiting for branch to pass
  • Open on Drupal.org →
    Core: 10.1.x + Environment: PHP 8.1 & MySQL 5.7
    last update over 1 year ago
    Waiting for branch to pass
  • Open on Drupal.org →
    Core: 10.1.x + Environment: PHP 8.1 & MySQL 5.7
    last update over 1 year ago
    Waiting for branch to pass
  • Comment 7 months ago →
    🇺🇸United States shelane

    Given that 9 is EOL, we now need 8.3 for the upcoming Drupal 11 release, we will have to drop support for PHP 7 and Drupal 9 in this version. As stated, users needing that support can continue to use the 1.x version. Also, we are going to need to get at least an alpha version of 2 out the door because it provides fixes for PHP 8.2. I have an active branch to fix some phpcs and phpstan reported issues. If I can get that done, I will do an alpha release based on the fixes that have gone into the 2.0.x branch.

    I do not have the ability to add maintainers either. But, I can review any MRs submitted.

  • Comment 7 months ago →
    🇺🇸United States shelane

    I do apologize that the changes that I am committing will cause some conflicts with code in this MR. However, I need to get this deprecation calls fixed for use in PHP 8.2. There are numerous changes in this MR and I cannot really give proper review to them.

  • Comment 7 months ago →
    🇺🇸United States shelane

    I have rebased this branch on my changes. I did accept any conflicts from this branch rather than the code we're rebased on. Now I need redo a couple of the changes I had made for deprecated code so that they're in this branch.

  • Comment 7 months ago →
    🇺🇸United States shelane

    I fixed many phpcs issues after the rebase, but several more remain. The ones I left are more code issues, so I leave that to the original author as you know your intent.

  • Comment 10 days ago →
    🇩🇰Denmark ressa Copenhagen

    Since 2.x is the target version for new code, perhaps it should be made the default version on Gitlab? Currently, it's 1.x:

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024