Survey:

Should we move the module documentation from the README to pages in the Drupal.org handbooks? I had a discussion about this at DrupalCON, and we only want to maintain docs in one place.

Thoughts? Volunteers?

Comments

croryx’s picture

My initial reaction is that I prefer the README files. This is probably just because it's where I'm used to finding this information, but my (very newbish) impression is that this is still the standard location for this information. That said, if the README directed me to the DO handbook pages that would be just as easy, and given the number of frequently asked questions in the queue maybe something different (and more flexible) would be worth a try.

Regardless, I'd be happy to help out with the documentation by either helping with a move over to the Drupal.org handbooks or by contributing patches to the README files for some of the issues that have been tagged for addition to the handbook. I don't understand a number of the more complicated issues, but I should be able to put together decent drafts from the issue queue that can then be cleaned up by the professionals.

agentrickard’s picture

That would be awesome.

I showed the README to one of the docs maintainer (@jhogdon) and she was shocked by its length and thought no one would ever read it.

croryx’s picture

That's good enough for me. I'll take a look at the handbook on contributing documentation and some examples for other contributed modules (if there are any examples that you particularly like let me know) and we can go from there.

agentrickard’s picture

I think we just need to take the section headers in the README and transpose to HTML pages. (That's 8 pages in HEAD). Then INSTALL, too (another 6).

croryx’s picture

I've been going through the files and starting to convert them to individual HTML pages. While doing so I've been thinking about the structure for the book. Here's my initial suggestion, which is basically just combining the installation section of README.txt with the equivalent information in INSTALL.txt and nesting that in a set of second level Installation pages:

Domain Access
--Introduction
--Installation (Section 1 and first part of Section 2 of INSTALL.txt)
----Before installing (Section 2.1 - 2.5 of INSTALL.txt)
----Installing the Module
----Configuring settings.php
----Additional Module Installation
----Uninstalling
--Permissions
--Module Configuration
--Blocks
--Node Access
--Developer Notes
--Drush commands

I'm happy to make any recommended changes.

We also need to figure out where this will fit in the overall documentation hierarchy. I didn't see anything that was a perfect fit. Options include:

Administration Guide -> Managing URLS
Site Building Guide -> [No obvious subsections though]
Installation Guide -> Advanced and multisite installation

agentrickard’s picture

We might put pointer links in those other sections. Just a simple page that says "Using Domain Access with TOPIC X" with a brief sentence and link to the related docs.

croryx’s picture

Draft documentation pages are now up here: http://drupal.org/node/1096938.

I flattened the hierarchical structure above in an attempt to follow recommendations from the documentation team and attempted to combine README.txt and INSTALL.txt in a useful way. Let me know if there are changes you'd like me to make.

I'm going to open documentation issues to get the location in the hierarchy reviewed and to get the recommended /documentation/modules/domain alias.

c.ciprian’s picture

Nice work.
It's much easier to read the documentation on a web page.

agentrickard’s picture

This is AWESOME. Some notes for us to tackle.:

-- The paths et. al. refer to Drupal 7 and that needs to be noted. Not sure how to handle D6 variants.

-- Much of this page http://drupal.org/node/1096944 is edge-case and warnings. Those should be moved to a separate page for 'troubleshooting' or similar. The introduction should be much more positive :-)

-- We need to remove references to INSTALL.txt and README.txt if we are going with online-only documentation.

-- The warnings here http://drupal.org/node/1096954 don't fit in this context. They probably need to go with the new troubleshooting page.

-- http://drupal.org/node/1096956 needs a note about module installation and rebuilding node access through the UI, users will get a message that can be 'scary'. We should also note the 'Domain failed to load' message here if the settings.php file is not set up.

-- Not sure about the settings.php / enabling the module order. Should we swap that?

-- http://drupal.org/node/1096956 refers to old permissions that have new titles in D7.

-- http://drupal.org/node/1096974 should probably be split into several pages.

-- http://drupal.org/node/1096994 may only apply to 7.x.3 and needs to be checked. 'Weight' for instance is a 7.x.3 feature as is drush gend.

We should also look for the 'handbook' tag in the queue to add more use-case and troubleshooting tips.

agentrickard’s picture

See #1100904: Domain Access doesn't appear to work for me. We need to make clear the docs are for D7.

croryx’s picture

I went ahead and set the pages where there was an obvious D6 vs. D7 issue to 'incomplete' just to give folks a heads up that these are still in progress. I should be able to work on this in the evenings this week.

There are 3 approaches we can take regarding D6 vs. D7: 1) I'm assuming that what we'd like to do is have the docs work for both versions with distinctions like the one you made on http://drupal.org/node/1096962; 2) It is also considered acceptable to have separate pages for D6 and D7 when they exist; or 3) we could simply mark these as D7 only and add warnings where appropriate to direct users to the README and INSTALL files for D6.

Also, the alias (http://drupal.org/documentation/modules/domain) is now setup (#1097018: Alias for documentation landing page for Domain Access) for linking to the main page once the docs are clean enough to direct people to.

agentrickard’s picture

I think the approach I took (labeling Drupal 7 or Drupal 6 where needed) is fine. If the docs team has other ideas, we should follow the standard. For things that are very different (like permissions), we should have separate pages. I really want to avoid maintaining two separate versions of everything.

Maybe a note in the intro about the approach?

croryx’s picture

Sounds good. Both options are approved by the docs team so I'll try to integrate where possible, split out the permissions into separate pages, and add a note to the main page about the approach.

croryx’s picture

I'm working on the Configuring settings.php page (http://drupal.org/node/1096962) and comparing to the D6 INSTALL.txt file it looks like $db_url on the documentation page should be $db_prefix. Understanding this is a bit above my pay grade so I haven't changed anything, but thought I'd point it out just in case.

croryx’s picture

1. Paths should now be good up through the Uninstalling page.
2. 'Configuring settings.php' has been moved ahead of 'Installing the module'.

Should I break the remaining work out into separate issues to make it easier to keep track of everything, or is it better to just have one documentation issue to follow?

agentrickard’s picture

I think one issue is fine. And $db_prefix is correct. I will fix.

croryx’s picture

I think that I have addressed everything above with the exception of these remaining/new issues:

-- http://drupal.org/node/1096956 needs a note about module installation and rebuilding node access through the UI, users will get a message that can be 'scary'. We should also note the 'Domain failed to load' message here if the settings.php file is not set up. [I could use some help on this one]

-- http://drupal.org/node/1096974 should probably be split into several pages.

-- http://drupal.org/node/1096994 may only apply to 7.x.3 and needs to be checked. 'Weight' for instance is a 7.x.3 feature as is drush gend. [I have indicated that this only applies to 7.x.3. If we want to check if it applies to other versions I could use some help with that.]

-- The troubleshooting page (http://drupal.org/node/1096944) currently only holds the bits of the old README.txt that we thought should go there (or didn't fit anywhere else). This page needs some cleanup and we should look for the 'handbook' tag in the queue to add more use-case and troubleshooting tips.

-- The current pages are located under Contributed modules > Contributed module documentation > Domain Access, but I noticed that there is also a separate set of pages under Advanced and Multisite Installation > Run multiple sites from the same code base (multi-site) > Domain Access (http://drupal.org/node/432266). Since I somehow didn't see these when getting started we now need to combine the two sets of pages. Given that the documentation alias is already setup for the Contributed Modules location and it holds the more complete documentation I'm planning on integrating the older pages into the the Contributed Modules section unless there are any objections. I did open an issue requesting feedback on this from the documentation team #1097010: Review of new contributed module pages for Domain Access

nonsie’s picture

Nice job, croryx;) I'll be going over it this weekend from 6.x perspective as I'm still using it on my sites.

Also we have documentation in the issue queue on how to set up DA in various hosting environments where users don't have access to httpd.conf themselves - where should it go? IMHO it should be a child page of http://drupal.org/node/1096954

croryx’s picture

Glad to be able to help.

The placement sounds reasonable to me. I've continued to wonder whether all of the installation related pages should be child pages of a general Installation page so that folks understand that all of these relate to installation. The docs team recommends keeping nesting to a minimum (http://drupal.org/documentation-writers-guide#hierarchical_organization) so we could also do something like this:

--Installation
----Before installing
----Special instructions for cPanel
----Special instructions for Plesk
----Configuring settings.php
----Installing the Module
--Additional Module Installation
--Uninstalling

croryx’s picture

I have (finally) taken care of the last few things on the current list, with the exception of going through the queue and adding additional information from frequently encountered issues. Let me know if you see other things that are missing or need improvement. If there isn't anything at the moment then feel free to go ahead and close this issue. I'll keep an eye on the queue and try to respond quickly to any new requests for additions/changes to the documentation.

agentrickard’s picture

Take a look at things tagged 'handbook' in the queue.

The next step is documenting common tasks that come up in the support queue. These likely need separate pages (FAQ) and child pages for each major task.

croryx’s picture

I added the FAQ landing page and a page for the perennial User 1 issue and other issues with nodes being unexpectedly accessible (http://drupal.org/node/1172680). Modify/cleanup as necessary.

This should take care of the following 'handbook' tagged issues:
http://drupal.org/node/985616
http://drupal.org/node/927984
http://drupal.org/node/965810

Should I remove the 'handbook' tags as I create pages in the docs, or leave them in place?

agentrickard’s picture

Leave them but mark closed with a pointer to the new page.

@croryx++

willyk’s picture

Guys is there any further assistance needed with the DA documentation on D.O? I was thinking that perhaps we could add this more recent video from DrupalCamp Atlanta http://archive.org/details/SharingContentAcrossMultipleSitesWithDomainAc... to the main page in addition to mentioning the DrupalCon Paris video

agentrickard’s picture

Go for it.

There are some style cleanups to do -- I know there are pages that reference the README numbering scheme, for instance.

Then we need people to move the submodule documentation as well.

agentrickard’s picture

Status: Needs review » Fixed

Marking as fixed. Nice work all.

Status: Fixed » Closed (fixed)
Issue tags: -handbook

Automatically closed -- issue fixed for 2 weeks with no activity.