Move pages that appear elsewhere out of the books

I already covered this in #429410: Page titles when viewing pages with a content menu - i.e. Modules page:

"Note that some pages will be tricky and will need handbook reorganization for example. Such as the mailing list page. It has a tab in the navigation on its own, but it is also currently a handbook page. So by general rules, the handbook tabs and title should appear, but it has its own tab and title. We could make exceptions in code, but I'd rather have the handbook clearly organized to avoid such cases."

I am not sure that having one-per-one special casing for these nodes is a good idea. We have such ugly code enough. I believe the handbook just should not have pages wildly included from around the site. The handbook can always reference those pages.

Changing types does not solve any of our problems. That code in crosssite module should check for book navigation placement (!empty($node->book['bid'])), which is completely node-type agnostic and is filled in for every node which is somehow in a book. I think we need a documentation change. We need to explain this to the documentation team:

Dear documentation team,

The new redesigned site requires us to display a section header on top of pages. For all documentation pages, a "Documentation" section header will display with the documentation tab being selected. This is cool. People will know where they are and can navigate around. Drupal.org is a huge site and this gives them guidance.

However, there are nodes in the documentation currently, which should show up elsewhere too. Like the Drupal core project page, which is put into a book or the CVS account request form or the mailing list page. When these pages are shown, the redesign requires us to display their corresponding section header "Download and Extend" and "Community" respectively. If such pages are kept in the handbooks, when their URL is called, the site has no way to know whether the user was coming from another docs page and should be kept in the Documentation section or is coming from Download and Extend for example, and should be kept there. Dropping users out from either and putting them into the other would be a usability issue.

Therefore we made a rule that for every node, there should only be one parent section. This translates to the Drupal core node, the CVS application form or the mailing list page not being in the handbooks. Please make the appropriate changes in the books.

Thanks,
The redesign team

Due to the hopefully clearly explained reasons, I believe our only way to solve this is to break out from this "can show up in multiple sections" state.

Moving it to the documentation team. Please read the above explanation. We need a list of docs pages which are in this conflict, so that the docs team can work this out.

I don't think this is a doc team issue. This is a webmaster issue as far as I can tell since it is about higher level, moving stuff around for the redesign. That is, I don't see what the doc team needs to "work out" but I do see that webmasters need to sort some things out.

I'm not clear what is required. I'm assuming that, since all book pages must be part of a book, that you will need to copy the contents into a page content type instead, or make each existing page its own "book"? Either way is fine to me, though I think making them pages makes things cleaner, though that would require a redirect for the node IDs. The Drupal project page (http://drupal.org/project/drupal) isn't part of any book right now, so I'm not sure what we need to do to it.

A more detailed list of the pages that need to move, as well exactly what info in them is needed (i.e. is the entire IRC page content needed or just a subset of it?), and what we need to do to them to "move" them would be great.

Hm, well, I believe the core project was part of a book previously. Anyway, keeping existing node IDs and just migrating the node type from book to page is certainly possible since we are looking at tasks involving writing update functions, munging the DB and so no. The more such changes we do before the redesign deployment however on the live site, the better, so the possible problem areas are kept in control.

Ah, agreed. If we can just move the node type (and check for book outline stuff), that would be ideal.

This reads like something for redesign to look at ?

Linking this from the Redesign project #661566: Meta issue for Drupal.org webmaster project because this issue was tagged 'drupal.org redesign'

I'm removing the Blue Cheese tag, as this isn't really a theme-related issue.

Seems to have been done at some point.