Merge with Site Doc

SiteDoc is great to document a site's minute details for a development team, to document ongoing efforts, to transition a project to new contributors, or myriad other tasks that allow developers to communicate with developers.

What configdoc does is to generate a simple configuration report that any user posting a bug here can quickly generate, download, and attach to a bug report on Drupal.org to help maintainers and contributors quickly locate configuration details and known conflicts. A sample report is attached.

The audience being different, a lot of the information that can be useful to pass on between users of a given site is not shown to the general public visiting drupal.org. We want this tool to be used by the non-informed, non-committed bug reporter. For example, your database table names and cardinality are not shown: sitedoc offers more than enough details to be able to figure out which site is involved (the URL itself is included !), and how popular it is, something that commercial sites will never want to show (you could gauge their relative popularity and extrapolate revenues, for example). Openly sharing the privileges associated with a given db user would create quite a few risks. The username and hints to password complexity are even given in plain text for all to see. There is a lot of extraneous detail that a diagnostic tool does not investigate nor report on that are absolutely necessary for a documentation tool.

On the other hand, a lot of information that is useful to a maintainer involved in diagnostic inquiries would be random noise to a site developer involved in documentary observation; those are exactly the kind of data points that a support tool (rather than a development tool) like Configuration Documentation focuses on:

1. are the users' module up-to-date ? Asking the question almost begs users to update their modules before gettingtoo far involved in documenting bugs in earlier versions.

2. has the user installed -dev level modules, and if so which ? Is a sub-module version mismatched ?

3. has the user disabled all extraneous modules as they were reporting the bug ?

4. is there a mismatch between the PHP version they are operating on and the versions required by their modules ?

5. is cron functioning properly and regularly ?

etc.

One can further tell the tools apart by describing how each is destined to grow.

Sitedoc is destined to go into ever more details to satisfy the needs of developers.

ConfigDoc is destined to make diagnostic conclusions on its own to help the user report only bugs that are not the result of configuration mismatches, and be used as a datasource for statistical issue analysis for issues listed on drupal.org (with which sitedoc need not truly concern itself).

Two modules, two very different destinies.

Goodness, where to start? There are so many comments to this thread.

I agree that a debugger report would be a handy extension, not just to Sitedoc, but perhaps (D8) in core. As a developer, such a report would really help on many issues.

@63reasons: you mention "noise" - to me, such things as repeating minimum PHP level for modules that use core's minimum is more than "noise" - it hides an extremely pertinent detail. I would highly recommend suppressing that. I would also recommend (as a developer) moving the basic release info (PHP, database, Apache, Drupal) to the very top of the report; these are amongst the first things I want to see.

Like Dan, I run Update on very few sites. Most of my customers believe "If it ain't broke, don't fix it." Further, as I have discussed with Derek on more than one occasion, it becomes alarmist at times.

I do like the way you group modules and sub-modules together - probably better than the way Sitedoc checks it.

Finally, and I have no idea how to go about it, but the system module (status report) apparently knows, is to indicate whether there are any updates that are needed yet. This, I think, would be, according to your stated intentions, a crowning addition.

Yes, I would love to have another maintainer (or two, Dan) on Sitedoc as my life has changed a lot since I wrote it; time to maintain all my modules is at a premium now. A fresh pair of eyes on it would also likely result in a better module. And reducing duplication, in the eyes of potential adopters, is a good thing.

*EDIT* I will open an issue to patch some of the changes I mentioned.

I should also like to support the merging of these two. Yes they are different, but they clearly overlap and some sort of selector to indicate which parts to generate would be useful. Sitedoc already has some configuration. ConfigDoc's plain text dump report is a good idea. For uploading to issue queues it is not necessary to include all the explanatory text that SiteDoc has and ConfigDoc correctly omits.

The matter of what needs to be reported for a given issue is not so clear cut as ConfigDoc suggests. The overall readability of posts would not be improved if every contributor posted ConfigDoc output without selection - it is simply too long.

There are also some things that ConfigDoc does not report that are sometimes useful, and uncritical use might lead to missing information. Whilst ConfigDoc does very well for software versions it contains little on content or module configuration. For instance when reporting errors with OG and notification some information about numbers of Groups, type of notification etc is needed.

NancyDru: I wouldn't mind merging the two projects at all if it makes more sense; let's wait a bit first to see how users use both modules to see if the difference in purpose is reflected in actual useage, and if it gets used interchangeably rather than distinctively we'll merge !

AFowle: The typical (expected) use case is for an attachment with bug reports; you do raise, however, a valid point on selecting for length and details for reports that are simply cut & pasted.

Updating title, priority, status. I don't consider this a high priority (and neither does 63reasons). Having now used this modules a few times, I'm not entirely sure that it completely makes sense, even though I see the [external] logic in such a suggestion.

I stumbled across this issue while searching for modules that help with documentating a Drupal site's configuration and settings.

What's the status on this issue?

EDIT
Just seen that the real action seems to take place over at #908926: Port SiteDoc to Drupal 7.