Add a report with copy/paste debugging information.

[stpaultim]

Description of the need

We frequently ask folks who are having difficulties with Backdrop to share a list of module they are using. I was asked for this today.

In fact, this is not an easy thing to do and really it should be. Yes, it's easy to see all enabled modules on the admin/modules/list page. But, it's not easy to share that list in a forum post or Github issue. Not nearly as easy as it should be.

I would like a text only or bulleted list of my enabled modules that I can easily export or share in a forum post. I would assume this is pretty easy to provide..

I looked for an existing feature request but could not find one. I was a bit surprised. Maybe it already exists and I haven't found it. Or maybe there is an easy way to do this already that I'm not aware of.

Proposed solution

I'm going to suggest a report under the admin/reports menu that provides a list of all modules that can be filtered in any of the following ways:

1) All modules 2) All enabled modules 3) All enabled contrib modules 4) All enabled core modules

I think this should be available in the CORE UI because often the folks who need to share this information with someone do NOT have command line access to drush or Bee and may not be able to add a contributed module themselves.

Alternatives that have been considered

For Drupal 7 there is a Drush command for this, I'm not sure if it works on Backdrop. But, even if it does, many of the users that need this feature are not going have access to a Drush or Bee based solution. I think this should be possible in the UI.

Is there a Drupal or Backdrop contributed module that accomplishes this?

It looks like this Drupal 7 module might do the trick, but I have not tested it. https://www.drupal.org/project/enabled_modules

Based upon discussion in this issue, I've released a recipe that generates a view for this: https://backdropcms.org/project/enabled_modules_report_recipe

Additional information

Related idea - list of "unused" modules - https://github.com/backdrop/backdrop-issues/issues/5020 Contrib proof of concept: https://github.com/backdrop-contrib/unused

Draft of feature description for Press Release (1 paragraph at most)

Backdrop CMS now includes a copy and paste debug report that can be used when reporting errors or seeking support in forums or chat. The new debug report includes server info, database version, jQuery info, a list of enabled modules and themes, and more. We expect that this report will make it much easier for site owners to get answers to technical questions, by making it easier for them to share the specifics of their site installation.

[argiepiano]

This is actually very easy to accomplish with Views. Views has field handlers to display modules and themes.

Pasting an export of a simple views that shows enabled modules as bulleted list. the easiest solution is to include such a View in a standard install

Click to see code

```json { "_config_name": "views.view.list_modules", "name": "list_modules", "description": "", "tag": "default", "disabled": false, "base_table": "system", "human_name": "List of modules", "core": "1.23.0", "display": { "default": { "display_title": "Master", "display_plugin": "default", "display_options": { "query": { "type": "views_query", "options": [] }, "access": { "type": "none" }, "cache": { "type": "none" }, "exposed_form": { "type": "basic" }, "pager": { "type": "none", "options": { "items_per_page": "" } }, "style_plugin": "list", "row_plugin": "fields", "fields": { "name": { "id": "name", "table": "system", "field": "name", "relationship": "none", "group_type": "group", "ui_name": "", "label": "Module", "exclude": 0, "alter": { "alter_text": 0, "text": "", "make_link": 0, "path": "", "absolute": 0, "external": 0, "replace_spaces": 0, "path_case": "none", "trim_whitespace": 0, "alt": "", "rel": "", "link_class": "", "prefix": "", "suffix": "", "target": "", "nl2br": 0, "max_length": "", "word_boundary": 1, "ellipsis": 1, "more_link": 0, "more_link_text": "", "more_link_path": "", "strip_tags": 0, "trim": 0, "preserve_tags": "", "html": 0 }, "element_type": "", "element_class": "", "element_label_type": "", "element_label_class": "", "element_label_colon": 1, "element_wrapper_type": "", "element_wrapper_class": "", "element_default_classes": 1, "empty": "", "hide_empty": 0, "empty_zero": 0, "hide_alter_empty": 1 } }, "filters": { "status": { "id": "status", "table": "system", "field": "status", "relationship": "none", "group_type": "group", "ui_name": "", "operator": "=", "value": "1", "group": "1", "exposed": false, "expose": { "operator_id": false, "label": "", "description": "", "use_operator": false, "operator": "", "identifier": "", "required": false, "remember": false, "multiple": false, "remember_roles": { "authenticated": "authenticated" } }, "is_grouped": false, "group_info": { "label": "", "description": "", "identifier": "", "optional": true, "widget": "select", "multiple": false, "remember": 0, "default_group": "All", "default_group_multiple": [], "group_items": [] } }, "type": { "id": "type", "table": "system", "field": "type", "relationship": "none", "group_type": "group", "ui_name": "", "operator": "in", "value": { "module": "module" }, "group": "1", "exposed": false, "expose": { "operator_id": false, "label": "", "description": "", "use_operator": false, "operator": "", "identifier": "", "required": false, "remember": false, "multiple": false, "remember_roles": { "authenticated": "authenticated" }, "reduce": false }, "is_grouped": false, "group_info": { "label": "", "description": "", "identifier": "", "optional": true, "widget": "select", "multiple": false, "remember": 0, "default_group": "All", "default_group_multiple": [], "group_items": [] } } }, "sorts": [], "title": "List of enabled modules", "style_options": { "grouping": [], "row_class": "", "default_row_class": 1, "row_class_special": 1, "type": "ul", "wrapper_class": "item-list", "class": "" } } }, "page": { "display_title": "Page", "display_plugin": "page", "display_options": { "query": { "type": "views_query", "options": [] }, "path": "list-of-modules" } } } } ```

[stpaultim]

Thanks @argiepiano! I'll give that a try and possibly create a PR.

[olafgrabienski]

Pasting an export of a simple views that shows enabled modules as bulleted list.

Brilliant! I've tested the view, and the basics work fine. I didn't find an option (a system field) to also display the version of a module, though.

[olafgrabienski]

@stpaultim There is an easy way to get a list of enabled (contrib) modules: admin/reports/updates

It's clearly a workaround though, as it's not likely to find this page when you're looking for a module list. Also, the page isn't optimized for copy & paste actions.

[indigoxela]

Great idea! Two suggestions for improvement:

1. Limit to admins (permissions!), otherwise it exposes info to the public
2. Adapt the path to something like admin/reports/module_list

We could link that view from the status page - or is there a better place?

[argiepiano]

To clarify, the view I pasted was a quick and dirty example - not supposed to be used in production, of course. But a good starting point. Limiting to admin AND including filters would be ideal

[indigoxela]

To clarify, the view I pasted was a quick and dirty example

Yes, sure, that goes without saying. :wink:

[indigoxela]

A PR is available for testing and review.

It's based on @argiepiano's suggestion - a view. Currently it's simply linked in the admin bar under Reports -> Enabled modules.

@olafgrabienski you asked to also provide the module version, but that info isn't exposed to Views, so not available.

@stpaultim you suggested to also provide filtering for core/contrib..., but for the same reason a view can't provide that info.

[argiepiano]

@indigoxela thank you for providing the PR 🙏🏽

Please notice that system_update_1086() is already in use by #5818, which is RTBC. Best to use the next update number.

I'll add a comment to the PR as well, on a different aspect.

you asked to also provide the module version, but that info isn't exposed to Views, so not available.

Would it be a good idea to create a handler to provide that info? (most likely as as separate issue)

[indigoxela]

Please notice that system_update_1086() is already in use

I'm aware of that - one will go in and the other one needs a merge conflict fix. No problem, doesn't happen for the first time. :wink:

[indigoxela]

Views ... Would it be a good idea to create a handler to provide that info? (most likely as as separate issue)...

Yes, also that (handler, separate issue), but the base problem is: this information isn't anywhere in the database and Views is just an additional abstraction layer for data in the database.

[docwilmot]

Here's a new bike shed I just thought up: In most occasions when a list of enabled modules is requested, its because we're debugging things. How about then a proper full "site report" page generated for this purpose?

• enabled modules
• disabled modules
• theme(s)
• server
• PHP version
• JS enabled
• number of nodes/types
• number of users
• JS/CSS compression on/off
• blah blah

Perhaps tickboxes to deselect items above where security/privacy is a caution. Too much? Different issue? (Though would moot this one)

[indigoxela]

Here's a new bike shed I just thought up

Sure, let's also discuss alternatives. :bike:

@docwilmot your suggestions seem reasonable, but go beyond the initial request here (and require coding - aren't feasible with views).

Fun fact, I came back to this issue today, after updating a Matomo install - and they have exactly that: A textarea that contains all that info as text with a "copy to clipboard" button. They also wrap it in a <details> tag and structure with markdown - obviously to copy/paste into an issue tracker.

[docwilmot]

aren't feasible with views

Thats what triggered the thought; Views is limiting this issue, unless we end up with custom handlers

[bugfolder]

Views ... Would it be a good idea to create a handler to provide that info [version, core/contrib, etc.]? (most likely as as separate issue)...

Yes, also that (handler, separate issue), but the base problem is: this information isn't anywhere in the database and Views is just an additional abstraction layer for data in the database.

core is detectable in the system table, but not contrib vs custom. But core vs other would be possible with the addition of another handler. (As with preceding comments, yes, this is outside the scope of this issue/PR.)

[argiepiano]

Yes, also that (handler, separate issue), but the base problem is: this information isn't anywhere in the database and Views is just an additional abstraction layer for data in the database.

core is detectable in the system table, but not contrib vs custom. But core vs other would be possible with the addition of another handler. (As with preceding comments, yes, this is outside the scope of this issue/PR.)

Version is (indeed) available in the system table, in the info column as a serialized string, so it should be possible to query with a bit of hackery (in a new handler). Tricky, but possible...

[docwilmot]

The OP is "Provide a list of "Enabled Modules" somewhere to help with debugging", nowhere is Views mentioned. We should pick the best way todo this, not stick to Views for what in this case is little benefit.

[argiepiano]

I have created an issue and PR that provides a Views field handler that allows the display of several settings from the info column, including:

• name
• description
• package
• configure (path to configuration as text)
• tags
• version
• backdrop (backdrop version)
• dependencies

If we choose to go the route of providing this as a View, this new handler will allow for useful additional information to be displayed.

5820

[indigoxela]

The OP is "Provide a list of "Enabled Modules" somewhere to help with debugging", nowhere is Views mentioned. We should pick the best way todo this, not stick to Views for what in this case is little benefit.

Sure, we'll pick the best option.

@docwilmot Views is a useful option, just providing a simple list to paste is already better than what we have now (nothing or people use screenshots of the module page, which is even worse). And it seems like you spoke too soon - with the new handler the list can contain versions.

We have time until January to decide, which way to go - that should be enough time to bike-shed and derail as much as we want. :laughing:

[klonos]

This is actually very easy to accomplish with Views. Views has field handlers to display modules and themes.

When did this happen?! ...was it introduced by a crossport of Views 7.x? ...I vaguely recall requesting that we integrated https://www.drupal.org/project/views_system into core, but that was not well received. I can't find that issue now.

[klonos]

Views is a useful option ... We have time until January to decide, which way to go - that should be enough time to bike-shed and derail as much as we want. 😆

Jokes aside, I also find this being implemented as a view very useful. It will trigger improvements to what can be done by system views (like #5820), which will benefit site builders in the long run.

[klonos]

I can't find that issue now.

Aha!: #1466

[docwilmot]

Here's an example of a full report in WP https://wordpress.org/plugins/website-information-report/. I have no problem with creating a View of enabled modules, by the way, and kudos to the efforts to make this possible.

I still do think a more comprehensive report like the WP plugin above provides is more useful for debugging. Could we do a POC as a contrib, or open another issue? Or do we think that a report like that could be completely done in Views?

[olafgrabienski]

or open another issue?

Another issue makes sense, in my opinion, primarily to discuss which info is helpful in a comprehensive report. The WordPress plugin lists e.g. the number of posts, comments, and of users. Not sure if that is (often enough) helpful, but to discuss it here would derail this issue thread, I guess.

[stpaultim]

I can see now that my vision for this issue might have been unnecessarily limited. I like the idea of a complete report that is easily to copy and paste into a forum/github ticket. I'd be happy to change this ticket into that or to work with the new ticket.

I have not had time to test the PR, but hope to get to that soon. I am since convinced of the value of providing more info than just modules, but am also happy to implement this in stages.

[indigoxela]

I'd be happy to change this ticket into that or to work with the new ticket.

IMO we already have that issue - it's #5821, so no need for yet another issue.

Personally, I don't think this issue here could be a stage for the other one. This PR here is a solution for this issue, but probably no answer for what @docwilmot asks for.

[jenlampton]

Rather than adding a whole additional report into core for this, what about adding two new items onto the status report?

• All enabled contrib modules
• All enabled core modules

Even just had a comma separated list of machine names would help the forum post scenario, and we could leave additional reporting to contrib.

The report seems like overkill to me because we already have the modules page, and as soon as we add the filters for "enabled", "core", and "contrib" it will essentially be the same feature.

[klonos]

...removed the milestone, since we don't have consensus and no advocate for this.

Also, the current PR needs rebase and conflict resolution.

[indigoxela]

Honestly, it might make sense to close this issue here and proceed with one of the others?

My PR just provides a view - sort of a PoC. Which doesn't seem to meet all requests, anyway.

[stpaultim]

I understand that there is no consensus and the the PR needed work. But, I wanted to see what it does in action, so I created a new PR with a working sandblox. Thanks to the work of @argiepiano and @indigoxela.

https://github.com/backdrop/backdrop/pull/4298

I will probably create a contrib recipe for this. I don't plan to work on this PR unless we have a clearer consensus on how this should work.

[stpaultim]

Thanks @indigoxela and @argiepiano - I create a recipe based upon the ideas/code you provide. This recipe does pretty much exactly what the PR for this issue does or did.

https://backdropcms.org/project/enabled_modules_report_recipe

It creates the following link: /admin/reports/enabled-modules

Thanks has the following view/report:

[argiepiano]

Thanks! One useful feature you may consider is to add a filter for core and non-core modules. This can be done with the filter "filename" and "contains" or "does not contain" - "core".

[klonos]

I don't plan to work on this PR unless we have a clearer consensus on how this should work.

I plan to though 😅 ...I have some ideas, and I find that having a PR sandbox to play with allows for better feedback by others for both the code as well as the UI/UX implementation. Multiple approaches and PR sandboxes also help compare and decide 😉

[stpaultim]

@argiepiano - Great idea. DONE! (Change made to contrib module, not this PR)

[klonos]

A couple of screenshots from a PoC on my local:

Initial set of options, which load the debug info output in the text area via AJAX (could be expanded further, could add a hook so that contrib can add things here, could make this a series of checkboxes instead of a select):

I should have a rough PR ready by the end of the day (my day).

[ghost]

I'm not convinced something like this needs to go into core. I think a contrib module would be suitable for this (and then it can be expanded, if necessary, to include other debugging info as described above). If it becomes popular, we can consider adding it to core later as an optional module.

[klonos]

I should have a rough PR ready by the end of the day...

Well, that was a very long day 😅 ...anyway, here's a PR of what I had on my local, along with a sandbox for people to play with: https://github.com/backdrop/backdrop/pull/4446

By default generates the following information, but people can quickly select what to include:

• System info (core/PHP/web/db server versions etc.)
• Theme info (admin and default themes, their versions and info about their base themes if any)
• Enabled core modules
• Enabled contrib/custom modules

Currently the "copy to clipboard" and "download txt" links don't do anything.

I did my best to have decent output in both LTR/RTL:

[klonos]

...sample output with all options selected:

Backdrop CMS:                 1.26.x-dev
Installation profile:         standard
PHP version:                  7.2.34
Database server:              5.5.5-10.8.3-MariaDB-1:10.8.3+maria~jammy
Web server:                   Apache/2.4.38 (Debian)

Default theme:                Shasetsu (shasetsu) 1.x-1.1.0
 ⮑ base theme:                ⮑ Basis (basis) [core]
Admin theme:                  Seven* (seven) [core]
*used when editing or creating content 

admin_bar                     [core]
antibot                       1.x-1.2.1
backup_migrate                1.x-1.0.22
block                         [core]
captcha                       1.x-1.7.2
ckeditor                      [core]
color                         [core]
...

[klonos]

After feedback from @jenlampton during the dev meeting, I've now moved this page to be a menu item directly under "Reports", and I have simplified everything down to this (output still the same - just no checkboxes/options):

[docwilmot]

I like it. I think we can lose the download and copy links. Click > copy > paste is good enough I think.

@BWPanda said: I'm not convinced something like this needs to go into core. I think a contrib module would be suitable for this (and then it can be expanded, if necessary, to include other debugging info as described above). If it becomes popular, we can consider adding it to core later as an optional module.

I would almost agree, but I think it probably wont be best in contrib because if a new user wants help, then to ask them to download a module just for this seems counterintuitive to me. And debug info is such a common request in the forums.

[klonos]

Thanks for the feedback. Really glad you like it @docwilmot 🙏🏼

I think we can lose the download and copy links.

I agree ...I think 🤔 ...these links do not do anything at the moment anyway - I only have them there because I was curious to see:

• how much JS is needed to get them to work
• whether core and contrib could reuse those

Click > copy > paste is good enough I think.

Again, yes, I agree 👍🏼 ...however, it's more like: click > drag-select > may need to scroll depending on screen real estate > copy > paste ...or: right-click > select all (assuming that a) the browser supports it, and b) the person is using a pointing device that would allow them to right-click) > copy > paste ...or good-old CTRL+A > CTRL+C > CTRL+P ...but all that assumes certain tech knowledge/affinity. As a person that is all about UX, and less clicks, less scrolling, less fiddling, having links to copy to clipboard or to download as .txt in a single click seem very appealing.

But yes, I can certainly remove them and file a follow-up to discuss/decide.

[bugfolder]

having links to copy to clipboard or to download as .txt in a single click seem very appealing.

I liked the the copy-to-clipboard (for the reasons @klonos outlined), and note that this could even be an icon (so doesn't take up much space); I've seen a lot of sites using versions of the same icon for that functionality, e.g., https://www.flaticon.com/free-icons/copy-clipboard.

[klonos]

I've seen a lot of sites using versions of the same icon for that functionality

No need to go very far actually. It's also here on GitHub for code snippets in comments:

[docwilmot]

Perhaps a separate issue to add a "Click to copy" library to core? Can be used in other places (like CMI exports for example).

[klonos]

I've created #6135 and #6136 as follow-up ideas.

[klonos]

Quickly noting this so that it doesn't get lost in time: This issue was mentioned during the weekly dev meeting, and @quicksketch suggested to consider the idea of providing a link from the debug info page to the core issue queue in GitHub, where this information is pre-populated. Perhaps that can be a follow-up once the main feature's in?

[klonos]

I would like to get this in for the next 1.27.0 minor release, so I'll rebase and finalize this soon.

Wanted to quickly point out that in our bug report issue template in GitHub we are asking for the following info:

- Backdrop CMS version:
- Web server and its version:
- PHP version: 
- Database sever (MySQL or MariaDB?) and its version:
- Operating System and its version:
- Browser(s) and their versions:

So far in this PR I have been covering most of that, besides OS and browser. Should I be looking to add those as well, or nah?

[klonos]

...consider the idea of providing a link from the debug info page to the core issue queue in GitHub, where this information is pre-populated.

That is an interesting idea, but it makes the assumption that the issue is to be filed in the core queue. Otherwise, selecting the appropriate contrib queue could complicate things (logic as well as the UI). Leaving that for a follow-up as well.

[klonos]

I've rebased and updated the PR to remove the "copy to clipboard" and "download as text file" links (since we now have follow-up issues for those). The only things failing now are CSpell words (not added by this PR), which will be addressed separately in #6302.

I am obviously advocating for this, so can I please get someone to remove the milestone candidate - minor label and add the actual milestone if you'd like to see this in the next minor release? ...also reviews/testing/feedback to change and improve are welcome.

[klonos]

@stpaultim do you still want to continue on the PR with the views-provided report, or should it be closed in favor of the plain-text solution? If the former, then do you have capacity to please resolve conflicts and rebase, so that we can get a PR sandbox going?