Add text file export of status report

The two cols version.

A screenshot.

Definitely a good addition to the status page!

-I like the unordered list version better - It's cleaner and it's more obvious that this is a list of enabled modules.
-Version numbers are important and should be shown.
-Two (or three) columns of module names would be a good idea.
-It might also be helpful if the list could be divided into core and non-core modules.

What about a separate page or hidden block (to be shown via JS) that is linked from something next to the Drupal version line?

Here's a much simpler patch based on feedback from chx - it still appears to fix things.

Oops - this is not the patch you're looking for. (wrong tab)

Here's an updated patch. Instead of a row for each module, I put them all together in one item, in a neat three-column list (which degrades to 2 column on small sizes).

I also added a nowrap to the status report headers, to make the result cleaner. Looks great:
http://acko.net/dumpx/status-modules.png

IMO, Steven's rendition is the nicest looking version of a very good idea. A nice, relatively easy usability improvement.

The code is simple and clean, the CSS is exactly specific and therefore can't have any hidden side effects, and it looks RTBC to me, but I'll let another reviewer decide that.

Tested on a live site, works as expected.

Copy & pasting works great, confirmed 3-column degrading. Tested with no optional modules and lots of optional modules and both are fine.

Mmm. This patch doesn't get me excited. It makes the status page a lot uglier, and side-tracks functionality of that page. Copy-pasting module list isn't particularly popular right now. To me, this sounds like feature-creep. Therefore, I suggest we postpone this to 6.x so we can think about it some more.

-1 from me (at this point). I'm not really convinced.

The more I think about this, the less I think this is useful. Going to postpone this unless there is a stronger demand for it.

Setting back to RTBC now that DRUPAL-5 is branched.

It would be nice to have this somewhere, as the list of enabled modules is often an important piece of data for support requests and bug reporting.

I'm going to postpone this. Very rarely, people have to copy-paste all modules they have enabled. It smells a bit crufty to me.

subscribing

A list of enabled modules can be created with phpMyAdmin.

Perform a query using the following SELECT statement. This generates a list of all active modules which can be copy and pasted or printed.

SELECT name,status FROM system WHERE type='module' AND status=1;

See http://drupal.org/node/279265

HTH,
Doug

I have to respectfully disagree - a lot of bug reports in my projects are caused by conflicts with other contrib modules. Due to missing DBA-skills, many novice users are forced to compile this list manually to post it in a issue afterwards. This issue is about usability.

However, one could argue that the status report page is unnecessarily cluttered with this information. So I went ahead and created patch that adds a simple table listing all enabled modules along with their version info at admin/build/modules/list/enabled. IMHO, placing the list there is more appropriate and could be completed with a link from the status report page.

We should not mix functionalities. The user needs a simple list she can copy and paste. Anything else, such as checkboxes, might be copied as well (depending on the browser).

Two popular core example issues why we need this:

#304505: displaying admin/build/modules very slow
#311626: admin/build/modules very slow on some configurations

The need for this list is much greater in contrib though.

If I may throw two suggestions out there:

1.) As a contrib developer, when someone reports a possible conflict to me, what I need to know is the system name of the module, not the human-readable name it declares in *.info. That way I can visit drupal.org/project/{name} and don't have to search for it.

2.) The vertical list is more visually appealing, but a comma-separated paragraph would save a lot of space. If it is formatted like that, it might be able to go back on the status report, keeping the information on a single page.

I'd agree with Arancaytar. Denser and better for copy paste is best.

- Merged #13 and #29.
- Removed required modules from enabled module list.
- Using two-column bullet list.
- Tested layout in FF3 for all core themes.

Well, technically speaking module_rebuild_cache() does not sanitize any .info file values. Even $module->name could contain a hazardous value. Unlike $module->name, which would only be output for enabled modules that need to be loaded by Drupal and thus need valid PHP function names, $module->info['version'] is not processed by Drupal at all.

Can someone please review this in a live system, using IE or browsers on Mac/Linux, and run all tests to mark it RTBC, please?

Personally, I'm not really sold on this. It seems to add more clutter than value? I already postponed it in 2007 (see above), and I still think this is not an important patch.

Changing scope.

This patch adds an export link to the status report page, which re-compiles the full status report along with enabled modules, re-shuffles that into plain-text, and sends the whole export with a suggested filename "system-status-report.txt" for lazy attachment to drupal.org issues.

The exported report is made anonymous, i.e. it contains no information about the host or site name, and also no links that would uncover that information. Example attached.

Parts of the help text for admin/reports/status needed to be moved into the the theme function to display the export file link also when Help module is disabled.

Special thanks to chx, who pointed me into the right direction.

#36 is such a good idea.

I applied the patch, and after visiting the modules page to refresh the registry or whatever, it worked great (download the text file, did not prompt me for a filename).

In Notepad, on windows, the lines do not have the proper line endings (they all run together, and wrap).

Where we say "It may be useful to attach this information to support requests and bug reports filed on drupal.org's support forums and project issue queues.", we don't allow users to attach files to forum threads, of course.

Yes, that's a known issue. Windows' built-in notepad.exe does not understand Unix-style line-feeds and requires CRLF (carriage return + line feed). However, this should not hold off this issue, since we point users to attach this file (not open it in notepad). After attaching to an issue, when loaded and displayed in a browser, the line endings should work in all browsers and platforms.

Removed "support forums".

@Dries: To clarify: Enabled modules are no longer output on the status report page with this patch. Instead, they are compiled into the status report export file only.

I would just like to add a vote for this.

I am upgrading my site and one of the steps is to disable all custom and contributed modules before uploading the new files. I am looking for a way to capture the list of currently enabled modules, so I will have a checklist of what to re-enable after I have done the upgrade.

Please add this feature!

Thank you.

EDIT: As a workaround I printed the "/admin/build/modules" page to a PDF file for reference after the upgrade.

-1 on that. Firstly, implementing a .doc generator would go way beyond the scope of this issue. The idea is to get raw version information, for which plain-text is sufficient. (Also .doc is practically a legacy format, since it has bad version compatibility and even MS Office now supports the superior .odt.)

I would also argue that the file should either use \n by default (allowing \r\n as an option if you really need it) or depend on the server's operating system to decide this. All Windows editors except notepad can handle Unix-style separators nowadays.

There is a PATH_SEPARATOR constant in PHP, surely there is something for line separators too.

I just thought of a problem with the server determining linebreaks: A lot of people run Windows at home and Linux on their webserver, since the latter is the favorite of most web-hosts.

Web applications like phpMyAdmin resolve this by adding a checkbox or radio option to let the user determine which they prefer. Something as simple as "Linebreak style: Windows / Unix" would be simple enough.

@webchick: I was actually using the Vista version of Notepad when I tried this out in #37, so it is no less brain-dead than its parents.

Now using CRLF to support Windows users using Notepad. Should not affect *nix/Mac users. Definitely does not affect the output when viewed in a browser.

@41: .doc is definitely wrong. .html would be an option, but that extension is not allowed to be attached on drupal.org (and should not be just because of this feature).

Allowed drupal.org extensions: jpg jpeg gif png txt xls pdf ppt pps odt ods odp gz tgz patch diff zip test info po pot.

@42/43: The file is generated on the server-side. Without a module like Browscap in core, we do not know which browser/OS/platform a user is using locally on the client-side. JavaScript is not an option either.

@44: A checkbox would require a separate form for this, which would be overhead, IMHO.

@43/45: Yes, Notepad sucks. ;)

In general, all Drupal output is generated for Unix-style systems. I can see the special use-case here, if this patch works for *nix as well as Mac users, too.

Browscap?

Why make it complicated, when str_pos('Windows', $_SERVER['USER_AGENT']) works for 99% of all cases?

Now CRLF only for users using a user agent with "Windows" in the name.

Test failure : #335122: Test clean HEAD after every commit

I really don't think we should have a check for Windows users just because of notepad. Notepad++, Wordpad (I think), and many other text editors, not to mention browsers, display line endings properly. Since this is for users with high level admin permissions, they're likely to have access to alternative text editors - we don't mess with INSTALL.txt or CHANGELOG.txt for this reason, so why the report?

Well, re-attaching patch in #38 solely for re-testing purposes.

Re-test.

I like this addition a lot. The help text doesn't need to be moved around. Stuff in hook_help is displayed on the status page if the help module is enabled or not. Reposting with offset fuzz corrected also.

I tested the patch in #54 against HEAD. The patch applied cleanly and the status page had the usual text at the top:

"Here you can find a short overview of your site's parameters as well as any problems detected with your installation. It may be useful to attach this information to support requests and bug reports filed on drupal.org's project issue queues."

The export link was to http://localhost/drupaltest/?q=admin/reports/status/export (obviously, clean URLs is off). However, clicking on this link brings me to a page with just the text/link and no report. Running a WAMP installation, if that makes any difference.

Someone should verify this, as this is my first patch test and it's entirely possible that I did it wrong...

@amc, make sure you run update.php so Drupal can get a chance to update it's menu cache with the new menu item for the report.

@Dave Reid, Thanks for the info. FYI, running update.php simply gives "No pending updates." and doesn't change anything. But after clearing the caches manually from the performance page, it works.

Patch seems to work fine. Clicking on the link downloads the report and seems correct -- it's attached below.

I tested the report in Windows Notepad and, as predicted, it doesn't have line returns. Still, since this would theoretically be used primarily for support (as previously mentioned), its probably not that big of a deal. Also, as a semi-technical Windows user (I know just enough to be dangerous), I see files like this all the time. (This is why I don't use Notepad as my text viewer...) Probably not a big enough issue to hold back the patch.

NOTE: If you look at the report you'll notice that the PHP MEMORY LIMIT section is blank...that's because there's no value for it on my status report. That seems to be an issue (perhaps known, perhaps not) with the status report, however, and doesn't really have any bearing on this patch.

I agree with both Dave Reid's (help) and amc's (Windows carriage returns) arguments. As the testbed seems to be wonky currently, but this patch doesn't really touch existing functionality, I'm setting status to RTBC.

FYI: (for all that still print modules page as PDF :) )

I wrote a docs page:
http://drupal.org/node/348914 - Drush Module Manager

In it you will find how with drush and drush_mm you can easily :
* solve the "disable all - update Drupal core - enable back the same modules as before" problem
* get a color PNG image with all enabled/disabled modules and dependencies ...

There is this enabled_modules module - I will be glad if it borrows some ideas and even code from drush_mm - so users without shell access would have a nice dependeny PNG + the more easy-to-do and essential "space separated list of all currently enabled modules"... Posting that msg to the issue queue of enabled_modules...

Yeah that really does not help this issue at all...

@Dries: As I know that webchick is only reluctant to commit this patch because of your previous statements, could you please check whether the new approach and patch of this issue (#54) covers and solves all of your issues?

Aside from that, I'm planning to extend this report by allowing contrib modules to add further information to the report (which will only serve for debugging purposes and will not be displayed on the regular runtime status report page that is used 1:1 by this patch currently). However, let's get this basic status export in first and deal with further enhancements in separate issues.

Personally, I think this patch adds "cruft" to core. I'd prefer to see us work on improving the current _HTML_ status page. We can simply ask people to use their browser's "Save as text" feature. I'm tempted to mark this "Won't fix".

(I also think that the format of the export is unnecessarily verbose with -- the file could be 5 times smaller and easier to read if we'd choose a more compact format.)

Sorry, but the HTML status page, or a full dump of that page (even converted to text) does not help, neither for the user who has an issue and needs support (because he would need to find and extract the relevant parts) nor for the contributor who tries to solve an issue (because he needs to deal with all kind of different formats, ask again if information is missing, or explain how to provide that information all over again). Also, the regular status report page does not contain information about all installed modules.

The idea of this status report export is to provide and ensure that system information is provided in a consistent way. Many software vendors use an approach similar to this, where the end-user can (or sometimes even is required to) create a "debug info file" that helps the vendor to determine whether there are any external factors that may have caused an issue. Since the file contents are consistent for all users, one can quickly lookup the information of interest. If the software/support provider does not have access to this information, he has to ask the same questions all over again, and moreover, always remember to ask all relevant questions. This is exactly what happens in the issue queues of Drupal core and all contrib modules currently.

For the very same reason, merlinofchaos started to require data structure exports for Views and Panels in bug reports and support requests. To debug issues or provide support for users, plenty of factors need to be accounted for. Admittedly, such exports of specific objects are special to modules like Views and Panels. However, I could provide a very long list of issues for Drupal core and contrib modules that were needlessly open for a long time just because someone needed to ask the requester to provide basic system information. Even worse, in many cases it turns out that the end-user just installed incompatible versions of modules or has some other wrong system setup, which means that an issue that could be resolved in the very first reply is open for days, while adding burden to all parties in involved.

I like the idea (not that my noob opinion matters much). It would be even more wonderful extended to an option in the module page to disable all / reenable all. However, I also don't see how "save as text" produces anything useful -- if you mean from the 'Status report' page, it's not giving you the module list, and from the 'Modules' page, saving as text just lists the modules but doesn't show which modules are enabled or disabled. Plus it's got a bunch of other garbage you wouldn't need to paste in a help forum. At the very least, if this is cruft, you could have the 'Modules' page echo an invisible "x" or something next to each checked checkbox, so that 'save as text' would at least indicate which modules are active.

Some other quick questions/comments.

I haven't tried the correct patching tools, so I just stuck the code into the 'appropriate' files (system.module and system.admin.inc) and it didn't do anything. I played with it a bit, and found that if I put the function system_status_export into system.module, and changed the include_once to include_once './includes/install.inc'; //removed DRUPAL_ROOT then it works. For my personal edification, is this because I'm using Drupal 6 instead of 7? Or...should I start using the correct patching tools? (haha)

When 'porting' this to my install, I changed the output file extension to '.info', since I had previously set that to open in Firefox to get around the Unix/Windows line ending issues. This let me view it easily (after saving it) in the browser in which I was already doing stuff. Then I realized that if you don't set it as an attachment, it'll just open in your browser anyway. It seems to present fine in IE7 too, and even transfers correctly to Notepad -- wouldn't either way solve the line ending decision? If you need this to post in a request, you could just copy it straight from the browser without worrying about opening it in the appropriate program.

@dr.zaus
- Enabling/disabling current modules is out of the scope of this patch. I think there's actually a contrib module out there already that does that.
- If you looked at the example text file export in http://drupal.org/files/issues/system-status-report_0.txt you'd see that the enabled modules are added at the bottom. That's something that is not on the admin/reports/status screen and is one of the most important part of debugging a problem. This is the main reason why this export file is useful. We need all the information from the status report plus all enabled modules (and versions). This is exactly what the export file provides.
- The patch is written to work on Drupal 7, so yes, you'll have to make adjustments to make it work on Drupal 6. Or use the correct patching tools and make sure you are using it on the latest CVS version of Drupal.
- If we just output the result in the browser instead of forcing it as a download, we're removing a step in the process for already frustrated end-users that would be using this. And this reiterates the fact that Windows line endings suck and no one should be using notepad. :)

@Dries: So this is what you want?

1) How does that help maintainers and support providers?

2) You notice that contrib modules add all kind of stuff to a page?

3) I had to rename the file after saving it, because drupal.org takes .html only. Firefox saves .htm by default.

I have no idea how improving the _HTML_ of that page would help the underlying and real issue in any way.

Or is it this?

4) No formatting.

5) Noticed the needless help texts in here?

Oh. And lucky me is using an internal domain. Our poor users will post and expose their real domains to the world.

To run cron from outside the site, go to http://drupal.test/cron.php?cron_key=119b9bd10d5da3510b1fcd2193d15d71

Yeah, this looks like a WTF. The cron URL is not vital information for support, and putting it in a publishable report file defeats the purpose of the key.

I'm pretty sure it shouldn't be in there.

Dries is right. I can simply add a dependency to all of my contrib modules to allow my users to provide me the information I need.

Yes, thanks. That is actually what I always preach: Contrib should influence core development.

And the best thing: Users don't have to wait until D7 to get better support.

Moving and re-opening.

Would a module to do this stuff be appropriate? (see attached)

@dr.zaus: Well, that is what this module and project (http://drupal.org/project/debug) is for now. I have already started to add dependencies to some major contributed modules (currently dev snapshots only as there is no code/release for Debug yet).

ohhhh i get it. guess i won't be getting that cvs account for my module.

i can always hope someone would want to use mine until yours is ready.

<rant>

smk-ka just kindly pointed me to http://drupal.org/project/acquia_connector. So WTF? As long as it's for commercial support, then yeah for sure you need system information to properly resolve issues. But if it's for free voluntary work of all users and maintainers on drupal.org, then it's a won't fix?!

</rant>

How about this module? http://drupal.org/project/enabled_modules