Create new content type and Views for books

Thanks, Jennifer...

A bit more elaboration… If we want to be able to exactly replicate the current content, we need all the fields I mentioned (with a few exceptions, perhaps). As far as the taxonomies are concerned, I guess you would know better. I am still pretty new to the docs and wasn't sure if the books would stay nested deep in the docs or possibly end up in the D.A. website or promoted to a more visible part of D.O.

Anyway, the main fields might be easiest discussed by number, and I've change my original post to use an ordered list fixed the order to reflect my numbering of a few examples (from the developer books category.)

1. Title
2. Link (node reference to News/Announcement for the book’s release)*
3. Sub-title*
4. Any notes*
5. Author(s) (possibly multiple with human name linked to Drupal.org user)
6. Drupal version(s)
7. Publisher
8. Date of publication
9. page count
10. ISBN-13
11. Website for book*
12. Order link (non-Amazon)*
13. ASIN (Amazon ID)*
14. Preview link (books.google.com)
15. Cover image

1) and 2) A “Title” exists for all books (of course). Many books currently have the title as header linked to a node on D.O. about the book (hence the node-reference, but this could be any link). I'm open to this being changed, but didn't want to suggest getting rid of anything that our current book listings include.

3) Most books have a "sub-title" which might not properly be a part of the title, but is displayed on the cover and provides extra info about the book content. I think this is helpful, but it could be we could combine this with 4) (notes) and put both into the "body" field, relabeling that to “Subtitle and Notes” (or “Description” and just put any “sub-title” on the first line, followed by two line breaks then any other info.

5 - 10 ) No new comments. … I’m not sure if there is a “better way” available on D.O. to add author links than using the Link module with human name as text and their user profile page as URL.

11) Official website for the book (only some have this, and I didn't mention it initially). This could also go in the “description” (body) area, perhaps, assuming we don’t need to exactly replicate the current structure.

12) Order link (non-Amazon). E.g. a Packt link is: http://www.packtpub.com/drupal-7-module-development/book
Note: No special affiliate tags in a Packt link. They just share a percentage of Drupal-related book sales with the D.A., regardless of referrals, etc.

13) Amazon link(s) can easily be built just from their ASIN (Amazon product ID). The Views output can be rewritten to build the link with the D.A.'s affiliate tag. If the DA had other affiliate IDs (e.g. for other Amazon locales outside the U.S.), it would also be easy to build a set of Amazon purchase links for each affiliate account / locale. For books, at least all with the same language, etc, the ASIN stays the same from store to store (across Amazon locales).
Whomever enters the ASIN in the node creation form would NOT need to know the affiliate IDs or structure of the links.

Additional note: jredding indicated in his latest comment on the original topic that he really would like to have Amazon links for each book. It would be easy to implement.

14) Preview link -- Again, to keep current features. All book listings currently have this and it uses Google's book preview system. I'm open to this being changed, but maybe jcventura and/or jredding / others have an interest in keeping this (?). I did not want to suggest getting rid of anything in the current listings.

15) Image. All books have a cover image of approximately the same size. In the View, this could be linked to a larger version of the image (Lightbox or Colorbox), if desired.

Additional note about the Google book preview link... have you looked at one?
http://books.google.com/books?id=Oqi_eei2kq8C
Pretty cool, IMHO. Lots of good info and quite a lot of pages available in the preview. The only downside I can see is that it's more likely users from D.O. might follow this link for more info and then not use the Amazon link (with affiliate tag) to finally purchase.

Agree / agree. Maybe jredding and/or others with a stake in the outcome have some input before we start slashing features currently in the book listings, though?

If we had a CSV file for all the current books, it could be a time-saver, though. Copy and paste errors can happen... and it's just tedious. I could create a PHP script to generate Selenium code to copy all the fields into our new node/create/drupal-book form, as long as the CSV file has a standard format.

I'd like to know what modules D.O. has available. If a user (CCK reference) can be displayed as human-name (i.e. “Larry Garfield”, not “crell”) linked to drupal user profile path, that's ideal; I'm hoping that's easy to implement in Views. Otherwise we can have a Selenium Script that inserts the link text—i.e. the author name(s)—for each and a placeholder for the URL (user path minus the user ID, which we'd need to change (manually, after searching) for each author's user ID. That would be using a simple CCK link field with multiple values.

Commenting on the book nodes is a good idea, I think. So would rating them, if D.O. has any rating module(s) available (Fivestar?). I'm assuming the images can be resized on the server (imagecache) and displayed in the multi-book view with a pre-set "thumbnail" size, and in the individual nodes with a larger image. If not, I can do that with an image editor, but we already have cover images for all the books that will initially go into the system, so ... If any module like Colorbox or Lightbox2 is available for us, we could have the small images linked to original and displayed in the "Colorbox/Lightbox" overlay, which not only looks cool, but gives users a better look at details that might not be shown.

Thanks, Jennifer, that's great to have.

I think that I can assume the content type and views will be pretty simple, then. And no reference fields, no Lightbox/Colorbox... but we can manage to replicate the current book listings and add some features to it. I hope that the move to D7 might introduce a couple more "cool features" (fivestar ratings and stuff would be great), as would a system for flagging spam (with Rules integration to alert the webmasters). Well... one step at a time. ;-)

Is the Project module ready enough for the migration or will the site be "split D6/D7" for a while?

Good news... it's not a very heavily used module in terms of numbers of sites or percentage of Drupal sites, but it is a critical one (and not just for D.O.) I thought they already had a sprint for that and I'd thought it was going to be ready then, but I guess it's close now and just needs to be made "production ready". Anyway, I'm glad to hear that. I'd like to see more of the modules ported that are blockers for my personal site, but I can't justify working on more than a couple of them, especially since modules that aren't ported yet are mostly pretty trivial. But I decided to see if I can't port one simple one this evening. :-)

Anyway... back on topic: I was thinking that maybe the "authors list" would actually be easier to implement as an HTML text area with just the list of authors pasted in from the existing books... unless we want to be able to sort/search by individual authors, which might still work with each book being a node and the Solr Search being so awesome. The other benefit to this approach would be that we would have grammatically-proper: "Joe Smith and Joan Doe" / Joe Smith, Joan Doe, and Harry Halverson -type formatting pretty easily — with just a bunch of link fields it might be trickier to deal with the commas and "ands", etc. Or is Views good at that these days?

Well... I'm wondering if we can call this issue "approved" at this point, at least in terms of ready for me to apply for the dev site to work through the next steps and experiment. Even if we don't have all the details 100% ironed out, it might be good to take it a certain way along so I can see if there are any hurdles and start tweaking the workflow... and I have time to do that now (this week and soon) so there's no time like the present. ;-)

Re-ordered list of fields and made it an "ordered list" to match a numbered image (to be uploaded).

The issue has been updated to reflect the better understanding that has come from discussion (above and in IRC).

Please do continue to provide feedback and/or brainstorm so this can be an awesome new feature for the site. :-)

Do be aware of the limited list of modules on D.O. (comment #9) before suggesting ideas that would require modules which are not available for our use.

Plan updated. I'll wait for a "green light" from both you and jredding before I put in my dev server request. :-)

Cheers, Jennifer. :-)

And what jredding did say to me (via email) was that he was busy with the DrupalCon, so hadn't had time to fully respond but in short:

[ ... ] I think you're headed in the right direction if not in the spot-on direction.

If he does have other feature requests, I'm happy to adapt the content type and Views/displays after I've made a first draft. As I've indicated, it would also not be very hard to add links for other Amazon locales, as long as the DA gets the affiliate IDs for additional locales (we would then have everything necessary to build the links in our Views display). Given the rapid growth in Drupal interest in Europe, I think this is a good idea.

So I will go ahead and put in the request. Thank you. :-)

My request has been put in:

http://drupal.org/node/1493106

Hi Jennifer,

Maybe there are common credentials for just browsing the site (guest rather than admin access), but I can't even get to it without having a username/password for access.

Is the SSH access I have for Git the same for this, btw? I mean, will my Git SSH access for d.o. be used or … ? I've not used SSH that much, but if there are directions for what to do, I'm sure I can figure it out.

Cheers,

Lowell

@jcnventura: Hey the spreadsheet would be great. I'd like to have all the information that is available in a TSV/CSV format so that I can write a simple script to turn that structure into a script that at least partially automates the content creation process (i.e. Selenium IDE test-case generated for each row in the TSV document).

Anyway, yes. The spreadsheet would be great. And I do think that this might take some work to be very useful, but I believe we will get there. Your ideas are pretty much in line with the plan (to create a Features-generated module that is used to bring the new fields, content type, Views, etc, to d.o. For now, I don't think that there is flexibility to add new modules, so we probably won't have any fancy logic, but perhaps that might be implemented in the future. I'd at least like to see a list of links to purchase from various Amazon locales, but of course that would mean the d.a. would need to have multiple affiliate IDs.

I agree that using the Amazon module would be ideal, in many ways. I've experimented with it enough to know how awesome it is. That said, I understand it's not easy to get new modules added to d.o. and we would still need to incorporate listing books as nodes which would have all the d.o. taxonomies (version, target audience, skill level, keywords, etc).

That said, the simple solution, at least for the interim, is to just implement book-listings as a content type. Turning it into a module (one that possibly depends on the Amazon module) might be the next step, especially if that can help make maintaining the books easier. But looking over the Amazon documentation, we’d ideally want a few more modules active (others which are not in the list of d.o. modules jhodgdon pasted, above); these might include Token and Automatic Nodetitles… possibly others, as well, for an ideal set-up. And if we wanted to allow people to shop from multiple Amazon locales, not only would we need to get the multiple Amazon affiliate IDs (for the Drupal Association), but we would also need to build multiple-locale listing support into the Amazon module. So there would be a fair bit to do to get a truly ideal solution for book listings on d.o. that makes direct use of the Amazon module.

One problem I'm already running into is the fact that we don't have the Date module, so in my experimental “Book listing” node type, we currently have a text field for publication date of the books, which won't be easy to use as a filtering/sorting mechanism in related Views displays. It would be great to either have the Date module or figure out a workaround for its absence.

If we don't have the Date module available, I think we might best display the publication dates in a more "sortable" format, e.g. 2012-03 (I don't think the "day" is so important, since it's usually not accurate and often not available), but YYYY-MM format should be sortable. This is what I'll try. Right now I'm going to work on building a quick-and-dirty "Selenium generator" with lots of "HEREDOC" output with placeholders that stick in all the information from jcventura's spreadsheet. I can use it to create a bunch of testing nodes (for now) and later, we can use this to take some of the tedium out of creating the actual book listing nodes on d.o.

Thanks for putting in your good word on this, Angie! I've created a new issue for that:
Please add Date module to d.o.

Summary info:
Project: Drupal.org infrastructure
Component: Drupal.org module
Category: feature request
Priority: normal
Assigned: Unassigned
Status: active
Issue tags: Site builder improvements

I'm not sure if the "component" is correct or if d.o module is for d.o-specific (custom) module issues, but I didn't see a more suitable component; at least no other one seemed obvious.

In the content type, I'm also unsure about the cover image. Ideally, we should be able to upload a "largish" cover image, which would be resized to "thumbnail" in the listings (Views displays) and be sized down (if necessary) to maybe 350px wide in the node display, where it could be linked to the original uploaded image (if larger than 350px wide). On d.o. it seems there are three possible options:
1) Add image as attachment with "thumbnail" as the display size for "teaser". But there's nothing between "thumbnail" and 700px "Preview", so I don't know if it would be okay to add another preset between these sizes for node display of an "image field".
2) Add image as a file field (image). But here there are a ton of presets that I don't know, labeled from grid-1 to grid-12.
3) Image added as Image node and linked by reference.

Ideally, I'd like the image just to "float right" in the Views display lists... and also in the node displays, at a reasonable size for each. And I'd like the image upload field to be as obvious as possible, so I like the idea of using the file field. But I don't know if the "grid" options are for placement or for size... or what? I could experiment a bunch to try to figure this out, but I think it makes more sense to ask what "best practice" for d.o. node types with an image should be.

For some reason I wasn't able to SSH in from the Macbook drumm used for giving me SSH access to the dev server. Ideally, so I can work on theming/templates, I'd like to get my "home" SSH added for this server. jhodgdon got me on with a "one-time" login and I upped the credentials on the dev server for the LoMo account, reset my password, etc, so I've been able to work on the content type and Views by logging in on that account.

Anyway, I've got things working reasonably well… still some wrinkles to iron out and we should discuss exactly how the user interface for this should work. I think something like the filtering available on the Marketplace Preview would be nice. I've written a script to generate Selenium code from a simple spreadsheet (TSV) document with all the books, so I should be able to replicate all the data on the live server, when we are ready to "go live". I'll elaborate about how that works, but it's created "stubs" (separate HTML docs) for the "body" section of the page, which it reads when generating the Selenium code for the "body" content, so I can gather the standard "publisher/Amazon" book description in those documents and it will be a part of the content staging.

Current books:

http://docs-infra-drupal.redesign.devdrupal.org/books/current <-- All books tagged with versions D6/D7/D8 which are currently "available)
This Views display accepts arguments for "audience" so:
http://docs-infra-drupal.redesign.devdrupal.org/books/current/site-builders (same Views display with argument)
http://docs-infra-drupal.redesign.devdrupal.org/books/current/themers (synonym for Designers/themers term now in use on the dev site, but maybe it's better to avoid a slash in any term, since (even encoded) it seems Views doesn't manage it. At least not the version of Views (6.x-2.16+5-dev) on the dev server.
http://docs-infra-drupal.redesign.devdrupal.org/books/current/programmers <--- maybe "coders" is a better term to replace "developers" ?
http://docs-infra-drupal.redesign.devdrupal.org/books/current/site-administrators
etc... I've also exposed the "Drupal version" filter to allow users to select a particular version of Drupal to limit display to, e.g., just books covering Theming for D7.

Upcoming books:

http://docs-infra-drupal.redesign.devdrupal.org/books/upcoming <--- Works similarly to the above, but without the exposed versions filter (they are pretty much all for D7). It also accepts an argument for "Audiences" taxonomy.
Note/explanation: This is for books flagged "Upcoming" in the "Book status" taxonomy, i.e. not yet shipping.)

Books for older versions of Drupal

http://docs-infra-drupal.redesign.devdrupal.org/books/old <--- Also similar. Shows only "available" -status books prior to D6. There aren't so many.

What else?

I've got all 70 books* in the dev system now; the only thing missing is the full product details (for most, anyway), but I have a couple with a full description in the body area so we can better look at the layout when theming the image and content together.

*I removed one D5-related book that seemed to only be tangentially "about" Drupal ("Advanced Flex Application Development")

Other outstanding questions might include where this would fit into the current site structure and whether we also want to build links (it would be fairly simple) for multiple Amazon locales; the Drupal Association would just need to sign up and get additional affiliate IDs for other locales (Canada, Germany, Italy, France, UK, Japan, etc). I think that if people are aware of these pages and that they can use the links to support the D.A., while building their Drupal libraries, having multiple affiliate IDs and locale-links could be a GoodThing™. ;-)

Also, I think the dev server needs updates of a number of modules before we generate a "Feature". Views, ImageField, ImageCache, FileField, Features, itself (and a number of other modules not related to this task) are all a bit stale on this dev server, not to mention D6 "core" (6.23)

Other thoughts: Even if d.o is all English, I don't see any reason not to have another field (or Taxonomy) for "Language" in the content type (default: 'English'), especially if there are multiple locales for the purchase links. There are a number of books in German which are not in the current system, but are in a separate spreadsheet page from jcnventura. I think helping to promote non-English titles about Drupal would also benefit the community as a whole.

Again, bear in mind that neither the Views displays nor the content pages have had any theming, so things look a bit rough at the moment.

@jcnventura: Just to view the site, you only need "drupal" and "drupal" (username and password). That much is basic. I could also edit your user account to put in a new password for you and give you elevated permissions to help tweak the Views displays and such if you would like to take part in this. :-)

More than that (e.g. SSH access for uploading CSS and templates) would have to be done by drumm.

I can also email you my full scripts for the Selenium generator I've built, along with the simplified spreadsheet data (now all pages are in one and the "available" / "upcoming" status is a column. "Old books" get into that category based on the Drupal version(s) they cover. I renamed all the images and found the rest I needed so the Selenium scripts also uploads the images (which it looks for in a directory on your HDD ~/images/drupal_book_covers, according to the expected name.) Or I could zip it all up and attach them here. I've tried to write things so that, as much as possible, the Selenium generator could be useful for other projects where modules like "Migrate" are not on the server. (Actually I wrote a more complex version of this for populating a project for Cocomore with hundreds of nodes of testing content, so in writing this, I had to come up with some new tricks and improve some of the "basics", but it's an interesting piece of code for me). I think in my next revision, I have some ideas for making the code more "portable" (i.e. useful for other projects and tasks).

By the way, the old format lists (those linked on /books) had their layout totally broken by the move to "all docs pages are Filtered HTML", since it used DIVs with classes and the DIV tags are no longer allowed, so I used a bit of RegEx to process the content and reformat it without DIV tags, so now it still mostly looks like it did before being "broken". I've also moved a couple other books off of the "Upcoming" list and into the "Site builders" and "Themers" pages.

Hi jhodgdon: Right. Sorry for being presumptuous, but I did figure jcnventura was okay for adding as a participant in the process on the server since he's long been involved in maintaining the /books page.

a) Right. That works. Well, we can experiment with different methods of filtering and appearances for the "path" (e.g. what is a "filter" and what is an "argument"). I was planning to give the user these options, but we need to build menus for that or something. I'm not really sure how the current marketplace-preview page is constructed, but that's the final effect I did have in mind. Clearly there is more going on there (menus, etc) than what's in the Views display. I'm assuming the controls for that are in the templating layer?

b) I was assuming we would have a right sidebar, e.g. what jredding suggested in the "split the books page" issue (here, too). I consider what we have now a rough idea, so filters, arguments, theming, etc, are all in a very experimental stage. As I said: It's the theming stage that I will need support on for two reasons: firstly, because I have not got the proper SSH access yet, so can't add templates or CSS (or easily view what's in use currently on other areas of the site); and secondly because it's just not (yet) something I've done a whole lot, since I've more often worked in a team situation where others were the "designated themers" (and designers). I would like to build my skills in this area, but I am totally open to stepping aside and letting someone with that experience take over to polish things in the last stages.

c) Really? Please take a look at this, because the core and modules do seem a bit out-of-date when looking at the updates page. I know exported Features can be a bit wonky if the module versions don't match up, so we don't want to be more "up-to-date", but I'm surprised that the production server is not using more of the "latest" versions. I guess the modules in question just caused issues(?) or it takes a while to accept each release for the d.o production server.

Hi Jennifer,

Regarding the current set-up, I should point out a couple of reasons for the logic behind it.
1) The path "/books" is currently in use. So I can get rid of that path, but I wasn't sure about that initially. Is that the approach we want to take?
2) The reason for having "upcoming" as a separate display: Our current "Upcoming books" page is sorted in chronological order (ascending). I think that makes sense, since people want to see the books coming soonest (I would think) at the top of the list. Other displays have the most recent books at the top—I think this makes sense for books which are "available" (in-print); they want to see the "most current" books at the top. We don't currently have any books which are "out-of-print", although the "Books status" taxonomy allows for this.

So I do think it makes most sense to keep the "upcoming" books as a separate display (with reversed sort order from the standard). Whether we use filters or arguments might also have a bearing on the look of things. I like the "arguments" approach, since it keeps a very clean-looking path (no queries, just neat paths). I don't know that much about caching, but it might also be more cacheable. I do think the Marketplace Preview has cached views of the different argument options combinations. So performance could be a consideration here. I'm not at all an expert on this matter, but I think it makes sense to think of performance issues. There are not that many books, so the "arguments" approach provides a finite number of combinations for filtering the books, with neat-looking paths. The "exposed filters for everything" approach doesn't have as clean-looking paths and probably is not very "cacheable", so could have ramifications for performance, although I would agree that it's unlikely to get a ton of traffic (i.e. not likely to be a huge concern).

Anyway, for now, I will remove the path for /books on the dev server. Then I'll export the current state of the View so that we can revert more easily, if we wish to. And I'll remove the argument for "Audiences" and put exposed filters in its place. When we are happy with the Views displays, the next step will be theming and I'll at least need support with getting SSH to the server.

Okay. I just made versions of the views with almost full filter exposure. I've emailed you those, but for the sake of group discussion, I'll attach and include them here.

This is a "snapshot" of keeping the "upcoming" as a separate display, filterable by "audience" and the main "books" path display filterable by everything except the "status" taxonomy. With a single-column "grid" display, the images are pulled in more tightly.

This is the display for /books with all filters exposed.

"Archive" is now "Canceled" as a temporary stage between "Upcoming" and actually deleting a node for a canceled book… also since more people will likely have permissions to change the tags than to delete nodes, right? "Archive" is no longer a "status". The label for the "Authors" field is now gone. It's a text area with human name(s) linked to Drupal user nodes, ideally with a "title" attribute showing their Drupal user name. (I usually use TextMate, which has a great "link-selected-text-to-URL-from-clipboard" function, which automatically inserts the title of the page as "title" attribute for the link.) Anyway, a text area is appropriate since the authors list can be very long and contains HTML, so it's nice to have the BUEditor there.

Please see http://docs-infra-drupal.redesign.devdrupal.org/books for the current look of the listings. To access the dev server, use "drupal" as both username and password.

We need to give the node view a little CSS/template love. :-) For that, I need SSH access for my "home" system. Not sure why, but was never able to use the SSH key from my MacBook, which drumm added, so can't add my home system, myself. (see http://drupal.org/node/1493106#comment-5823840)

I'll try the SSH later today. I hope it works this time. We actually do need a template since it will have the order links (in full node view). The ISBN-10 is not displayed, but used to build the link(s) for Amazon.

Thank you, jhodgdon, for taking the time to look things over and provide such detailed comments. :-) You are right. Some areas were thrown together initially and not looked at again, e.g. the node/add stuff since I added all nodes with a script, is one I haven't looked at much since creating the fields. I've fixed most items and have provided an explanation for others. The following is mostly re: #46:

a) Fixed. It's a Views quirk, I guess. I'm trying to keep the original look of the Books pages which used a "clear" class for the title headers, which are h3. Using the "output as link" option means Views wraps the link around the rewritten output, but I've added a hidden node:nid field before the title, so now I can use its token to build the link within the h3 tagset. I don't think we need a label for the title field or for some others. And some fields are not used for every book, so we don't want "default" display for most fields. Some have complex rewrites, e.g. the ISBN-10 field, which provides the Amazon link including the Drupal Association's affiliate ID. It could be extended to provide links to multiple Amazon locales (with separate affiliate IDs for each).
b) They never did have any "vendor code" in the original book listings, if you mean "affiliate" id. Packt shares money with the d.a. when they sell Drupal books. This can easily be changed if the d.a does have an affiliate code and wishes to use it.
c) The full node view includes the "body" field, which now includes full details from the publisher or Amazon. I think there is no issue with plagiarism since affiliates can get this via Amazon API and modules like Amazon get this automatically. But sometimes this is glitchy, so manually formatting this info probably looks better. I've now got details for all books. Full nodes will also allow comments to be displayed, as per the proposal (and suggestion in #6)
d) About half the size is the same size as the thumbnail shown in the list view. Personally, I like the 300px wide images on the full node, but we could make it smaller and link to a larger version. I'd be interested to hear what others think about image size on the full nodes, especially once this content is themed.
e)

• Removed (s) from labels.
• Most fields have some necessary changes. Others are totally default and still don't have a bold label, so I think this is a theme quirk (we can fix this in the CSS, but I was getting strange results when attempting to rewrite with a bold title for some fields—e.g. multi-select terms with more than one term selected had the label more than once). This CSS should fix labels: .view-book-listings label {font-weight: bold; }
• I've got mixed feelings about this since there actually are two ISBN fields. We also have an ISBN-10 field (used to build the Amazon links, but currently not otherwise displayed in the Views output). That's the default label, btw; that field is entirely default and the label is not bold.
• I wanted to differentiate between the "order from" and "order direct" (from the publisher), but having two "Order from:" labels looks bad and one of them is optional, so I've hidden output from Packt and added it to the Amazon rewrite, so it now looks like: Order from: Amazon.com or Packt. We might want to include a Views header that tells about ordering directly from Packt (eBooks stay on your account and can be downloaded in any format at any future time. Your account page on Packt also includes links to download code and/or errata).

f) Changed to "A published book about Drupal, e.g. 'Cracking Drupal' by Greg Knaddison". I would keep it simpler or omit the description, but then there's the totally-unrelated "Book" content type, so the description helps eliminate any confusion. ;-)
g)

• Changed author field description, per suggestion.
• Changed (human-readable) name of "Book status" taxonomy to "Book availability" and omitted description.
• Help text for "brief notes" shortened.
• Removed "note to self" on Publisher field. Actually that parenthetical remark was for anyone involved in this process (you?)—It was: "we could change this field to a taxonomy or node reference to easily see all books with same publisher." Should we? As a node reference, that would mean having to add a Publisher node type; imho, that't too much trouble. As a taxonomy term, we could use an autocomplete field to allow for adding new publishers, but also easily selecting those already used. This could provide another filter option, etc.
• Page count made optional, although actually, all upcoming books I've seen have an estimated page count. Note: This field is one that could require changing when a book is actually available (other than the "availability" taxonomy selector)
• I think I've managed them all now. ;-)
• It is now rel="nofollow". I've used http://crackingdrupal.com as an example of an "official website" and some additional explanatory text has been added. I think these are important to include as, in many cases, this may be where errata is published or code from the book may be downloaded, etc.

Further to the theme of theming… the output of authors field appears in <p> tags. I suggest we add this CSS to get rid of the excessive bottom margin:

.view-book-listings p {
    margin-bottom: 0.5em;
}

I've now also seen #47, so will continue to muck around with this a bit more before I get to theming. I need to know how CSS should be managed to be easily added to d.o infrastructure, so could use some pointers here re. "best practices". :-)

I've also attached a screenshot which shows the Views UI for the Taxonomy term fields output. It's different from other fields (where you sometimes might have a selector for the "Label" field to be "default" -formatted). In any case, almost all the other fields have a "default" -formatted label and, for whatever reason, they are not appearing in bold type, but the CSS I showed (above in 'e' ) does fix this.

Responses to #49:

I've created a copy of content-field.tpl.php and a new content-field-field_book_isbn_10.tpl.php within the bluecheese theme directory, so the Amazon link is built from the ISBN-10 field. It took me a while to figure out why my initial attempts weren't working, but now it seems to work. :-)

I think I still want another tpl.php file to theme the output of the taxonomies. Right now they are just getting dumped into one "Categories: ..... " area, with terms from all categories jumbled together. I've fixed this before (in the theming layer on another site), but it's been long enough I'll have to look, again, at how. That's one thing left on my "to-do" list.

Regarding image sizes, in the full node view, my plan was to float the image to the right, so it shouldn't add much scrolling, but I've taken it down one "grid-size", too. Images are now floated right and "grid-3" (instead of "grid-4"). I still think I preferred the somewhat larger images on the node view, but this might be better for smaller displays, anyway. The images there are linked to the original image, so you can get a closer look.

Anyway, I've made a few tweaks here and there and added some code (below) to the bottom of the styles.css file, so I think things look a bit better now. Labels are bold in the Views, and spacing of elements is a bit nicer. Purchase links are unlabeled and as-discussed. I never had any "huge" rewrites in the Views. There are a couple of fields that are hidden and then added to output of another field. Nothing's changed there, really. I agree that that can be a pain to maintain.

I'm ready for another "review" and need to know what the final steps are to getting this deployed, (e.g. best practices for the "Feature", how CSS and styling elements should be packed, etc)

/**
 * Book listings
 */
.view-book-listings p {
   margin-bottom: 0em;
}
.view-book-listings label {
   font-weight:  bold;
}
.view-book-listings div {
  padding-left: 1.0em;
  text-indent:-1.0em;
}
.view-book-listings .views-exposed-form label {
  padding-left: 2em;
}
.view-book-listings .views-row h3 {
  padding-top: 1em;
  margin-bottom: 0em;
}
.node-type-book_listing img {
  float: right;
  padding-bottom: 0.5em;
  padding-left: 1em;
}

Screenshots of the current state of the View and an example node:

Thanks, webchick. I forgot about the "issue status" setting. There are a few things I still want to tweak in the "node display".

I've also been thinking about the "keywords", which are currently not displayed, since none have been entered for any of the books. But maybe we want to choose some for each book and look at having another exposed filter for the keywords. Of course keywords would be another taxonomy to sort out of the current "categories jumble", too.

I don't know if there is as much garbage in the keywords taxonomy on the current live site, but this is part of why I hadn't yet selected keywords. This mess of terms is also why I originally suggested a limited set of "topic" keywords for the books section so that only a privileged user could add new topics and we wouldn't end up with spammy keywords, misspelled duplicates, and tons of unlinked synonyms. ufff...

Current keywords list (as it is on docs-infra server)

I'm going to go through this list and delete all the terms (not in the actual taxonomy) which don't make sense to me as book topic keywords, then look at the Amazon descriptions and contents (or my own copies of the books, where applicable) to select some keywords for each book. Then we can experiment with filtering by keyword terms, too... or at least include them in the displays.

I've gotten rid of the content-field.tpl.php and content-field-field_book_isbn_10.tpl.php since I've figured out, well enough (it seems), how to write a preprocess function that takes the ISBN-10 and turns it into a nice link to purchase from Amazon, just as the special template file did. I believe this might be a better solution? The following function is now at the bottom of our bluecheese template.php file.

/**
 * Implementation of template_preprocess_content_field().
 *
 * Turn ISBN-10 field into affiliate link to purchase from Amazon.
 */
function bluecheese_preprocess_content_field(&$variables){
  if ($variables['field_name'] == 'field_book_isbn_10') {
    $amazon_link = '<a class="amazon-link" '
      . ' title="Ordering via this link benefits the Drupal Association"'
      . ' href="http://www.amazon.com/dp/' . $variables['items'][0]['view']
      . '/?tag=drupal0a-20" rel="nofollow">Order from Amazon.com</a>';
    $variables['items'][0]['view'] = $amazon_link;
  }
}

re #55: I don't know anything about adding extra functions to a Features-generated module. Can you just add in a "template.php" file? Or where would a preprocess function go? So far, I've only created the feature to be able to run dpm() locally when working out the preprocess function, since it seems that dpm() output is suppressed on the d.o dev sites (?)… yes, I had Devel active, so I'm not sure if this is intentional or just some conflict with modules on the site, the Bluecheese theme, or something. There are still some things I would like to see, but I'm not sure what the best approach is or if there is already a "d.o way" of implementing them, e.g. I know there is a module that displays the taxonomy terms in the right sidebar for the docs pages. Perhaps tweaking it to also do the same for "book-listing" pages would be ideal. (?)

I'm also thinking that if the only publisher who we will show a "direct purchase link", at this time, is Packt, we could just do away with the "link title" (text for the link) and have it set by a pre-process function which would test that the link is to packpub.com and replace with a "Order from Packt" link, if so. Otherwise it would either unset the link (as not authorized), or we could assume that there might be other publishers who could have this arrangement (share portion of Drupal-related book sales with d.a) and that the people creating book-listing nodes will be "in the know" (privileged, not just any user), in which the link text could be written to "Order from the publisher" if not to a Packt URL.

Anyway, I haven't given this any attention the past week, between first my wife, then myself being ill, and catching up on other stuff, but it would be nice to get some more progress on this.

re #56: I'm considering building a library of Selenium code functions that would work with a Drupal setup (i.e. a "content generator" that could take input from a tab-delimited "spreadsheet", but would require at least some custom coding for each specific use), so that's a possible "contrib" project that could come from this work, but I think that there are too many d.o-specific modules and taxonomies involved here for this "feature" to actually be useful for other sites.

Really, if you want Amazon support on a site, the typical solution is to use the Amazon module, but adding new modules to d.o doesn't happen (often) and for this particular use case, it might not be the best solution.

This is the amended preprocess function which also tests the link to Packt and unsets it, if not actually to packtpub.com. It's tested and working on the dev server. If we DO wish to allow links to other publishers, we can amend the function. The benefit here is that we will have consistency for the link text (since it's added by this function or in Views) and we can prevent those who don't know better from adding purchase links that are not beneficial to the d.a.

/**
 * Implementation of template_preprocess_content_field().
 *
 * Turn ISBN-10 field into affiliate link to purchase from Amazon.
 * Rewrite or unset Packt purchase link (unset if not to packtpub.com)
 */
function bluecheese_preprocess_content_field(&$variables){
  if ($variables['field_name'] == 'field_book_isbn_10') {
    $amazon_link = '<a class="amazon-link" '
      . ' title="Ordering via this link benefits the Drupal Association"'
      . ' href="http://www.amazon.com/dp/' . $variables['items'][0]['view']
      . '/?tag=drupal0a-20" rel="nofollow">Order from Amazon.com</a>';
    $variables['items'][0]['view'] = $amazon_link;
  }
  if ($variables['field_name'] == 'field_book_purchase_link') {
    if (!strpos($variables['items'][0]['url'], 'packtpub')) {
      unset($variables['items'][0]['view']);
    }
    else {
      $packt_link = '<a class="packt-link" '
        . ' title="Ordering via this link benefits the Drupal Association"'
        . ' href="' . $variables['items'][0]['url'] . '" rel="nofollow">'
        . 'Order from Packt</a>';
      $variables['items'][0]['view'] = $packt_link;      
    }
  }
}

When d.o goes to D7, we might want to use ISBN2node to help streamline adding new book listings, if that module could be added to the site. It might be even more useful than the Amazon module for our use case.

Re 61: I should have some time to work on this again on Tuesday/Wednesday, but have made a few "quick fixes" for some of these.

a) Ok. Easy. Done.
b) Also easy to change. I agree the "filter memory" is often not helpful. I've removed "remember" from both the "status" and "audience" filters.
c) Not my department (right?)
d) I agree that it should be added, somehow. On the book pages, it's currently just in the list of term links displayed below the description, but it should be fixed to have terms by vocabulary (as in the Views lists) and the book status should be very clearly displayed.
e) Yes, that was in the book description, just for that book. I'll just remove that from the "description" field import script. Anyway, a remaining "to-do" is to get permission from the other book publishers to use their official book descriptions. Amazon said we can't do this without using the API (i.e. that would mean using the Amazon module), but often there are mess-ups and someone enters the description in a "editorial review" area on Amazon, so the product info is missing when you try to import a description with the API. Better we just have permission from each publisher and gather details from them, directly (it's always the same as what Amazon has for a book, as far as I can tell, anyway.)
f) All the field items are indented like that. Second and subsequent lines are indented a bit more so that it's clear they are part of the same group. I prefer this indentation, personally, at least when the label is "inline" as it is here. It's purposefully in the CSS that way, but feel free to modify that CSS if you want. As far as I'm concerned, it's better than the default and I like it this way, but I'm sure that any changes you might make would also look good. I just wouldn't know what changes to make here.
g) Yes. All the books are available in print. Some can also be bought as ebooks, but the point was to clearly indicate these are not "published 'book' nodes" on a Drupal site, but actual books. I'd prefer to keep the description, as-is, or come up with a better way to clearly indicate what we mean by "book" here.
h) - It's an example entry from one book, not meant as two examples of links. The display is a bug, as far as I'm concerned. The "help/description" field renders the code that is within CODE tags. I wanted the HTML to be displayed, not the rendered links. The HTML gets rendered whether or not CODE tags enclose it... the only difference is the font. I guess we could use HTML "entities" to make sure the code is displayed.
- "Please choose" is default in a D6 select list, I guess. I didn't try to customize this.
- "List" has been changed to "enter".
- ISBN fields are now together on the node/add page.

Re c) I realize I misinterpreted your meaning. My mistake. Of course I can turn off display of "created by" info. OTOH, if this content type would be editable by various people, we might want to maintain diff and edited by info, as for other "docs" pages.

Re (g): So far the books which are not "self-published" all have print versions, but we could easily add "or electronic" (or something like that). I just want to avoid the confusion that we might mean a "published book node".

Re (h): Right. I agree that showing the code is better, so I'll make them display with entities and use just one author, as you suggest.

Re #65:
g) That should be clear enough. :-)
c) I'm not sure. I have mixed feelings about this for a number of reasons: 1) We only allow books from regular publishers, 2) the content creation is a bit more complex than a standard "book" page and should be done consistently, 3) We should make sure that we have permission to use the official book descriptions from publishers, 4) maybe better to have this be a content type that book authors and docs moderators oversee (i.e. "curated"). But of course there are compelling arguments for keeping the content creation/editing open, too. :-/

It was not my policy. ;-) That's just the current system which, some time back, removed all "self-published" books. I can't remember which thread discussed this, but the reasoning was that, almost without exception, the "books" in question should "never have seen the light of day".

I'm fine with whatever: If a book is listed on Amazon and people can see existing ratings and reviews, they can decide whether they want to buy it or not. But some of the "print-to-order" books had good promise in their descriptions (I understand), but did not usually live up to the promise and that might not have been clear to the initial purchasers.

I agree that voting/points would be great to have in place on d.o; our forums should also include this, imho. Is there any movement toward this actually happening, though?

Re: 73. Been sidetracked. Last time I was working on this, I was trying to add a Views display for the single nodes, but I realized I would also need to attach a view of comments, etc. Not sure what "best practice" is for d.o. I was thinking that using Views for the single nodes would make it easier for people to edit in the future (help eliminate special pre-process functions and need for a special node.tpl.php for the books. It could also help with SEO, since I could include the ASIN/ISBN-10 as an argument in the path, e.g. http://drupal.org/books/123456789X

jhodgdon: I remember you saying it was best to avoid needing a tpl.php file for theming the fields since new fields wouldn't be in it, but that's how I would normally do this. I'm not sure what other options there are other than a view for a single book, nor what d.o "best practices" would/should be. So, yes... I guess I could use some assistance or at least advice. :-)

I'm also wondering if we should put in a "language" field for the language of the book and start with a select list that includes all languages known to have good Drupal books already published. I know there are some good books for most languages spoken in western Europe. But maybe this should also be a taxonomy?

Sorry, I had to back-burner work on this and I'm glad that there has been some extra discussion. Since theming is not my strongest suit and I'm not sure what methods are considered "best practice" for d.o pages, I'd like to have some advice, at least, about the approaches best taken to getting the node view the way that we want it. I can think of a number of approaches I might use if I had total control of the site, but since that's not the case... ;-)

Anyway, I'd like to be consistent with d.o practices and I'd love some suggestions (with detail). I'd also be happy to let anyone else step up and finish the theming.

If someone can advise me, I'd be happy to wrap this up in the coming week. After that I'll be gone for a while (and then playing catch up) so it might be several weeks before I would have sufficient time to put this task back into my agenda.

I'll have to take a look when I'm back home to be very specific about the exact remaining tasks, as I see them (at Developer Days in Barcelona now), but it's mostly theming and display of fields / terms, etc for the full node pages. Other outstanding tasks are to contact all major publishers (other than Packt, who have already provided consent) to ask if we can use their "official" descriptions of the books in our "description" field. I suspect they will all agree to this.

I'll take other more recent comments into consideration for how these pages should be structured (any changes) and try to update the list of remaining steps to call this "good to go".

Remaining “to-dos” for the book listings content type display:
a) Theme the terms to split them up into:

1. Status notification shown prominently. Maybe with a bright background if “upcoming”
2. Audience level level(s)
3. Audience(s), i.e. “coders”, “themers”
4. “Tags” (general categories the book covers)
5. Drupal version(s)

b) Combine the publication fields into one line, as on the Views list, e.g.:
Published by: O'Reilly Media on March 30, 2012 (50 pages)
I’m not sure what the best-practices approach is for doing this, but I'm guessing we need some kind of pre-process function that deals with all three of the fields(?). This is where using Views for the node display would make things a lot easier.

See http://docs-infra-drupal.redesign.devdrupal.org/node/1478225 for an example of the current look of a single book listing.

Other thoughts: I'll need to clear out some of the experimental displays from the book listings view before we create a final Features module and I guess we need to move the theming / preprocess functions, etc, into that module somehow. I don't know anything about this. I'm also both rusty with D6 theming and not very experienced with it, so I definitely need some suggestions and/or handholding and/or someone with appropriate experience to step forward and see the theming through. ;-)

Summarizing discussion in Docs open hours:

We need community feedback about WHERE this should logically fit into drupal.org. It would be nice not to have the books hidden deep in the "getting started" section of the documentation. Should "Books" be in the main menu (e.g. next to "Marketplace")? Or somewhere else?

jhodgdon has offered to take care of writing a patch to the drupalorg module which places terms in the sidebar, similar to other docs pages. This will basically take care of all the "to-dos" I outlined as far as nice placement of terms goes. Thank you, Jennifer! :-)

I will clean up the books-listing Views displays (delete experimental unused displays, etc) and give everything a final look-over.

Other thoughts... edit privileges and list of "who wrote/edited it...". It sounds like these will be open to community edits, so ideally should have a list of editors, as per other docs pages. I will add a note in the "help text" for the book "description" field that we need to have authorization from publishers for any "official description" details shown for books. Packt has said we can copy/paste from their descriptions. Amazon says we need to use their API (no copy/paste), although it seems their book descriptions are almost always the same as the publishers' official "blurbs". I will write contact emails (as I did for Packt) to O'Reilly and other book publishers/authors.

Publishers to contact:

• Apress
• Course Technology
• Neal-Schuman Publishers
• O'Reilly Media
• Packt (confirmed and email forwarded to jredding)
• http://www.pearsoned.co.uk (imprints include: Addison-Wesley / Peachpit Press / Prentice Hall / QUE / Sams)
• Wiley / "For Dummies" / Wrox

If anyone here has contacts or represents these publishers, that might help streamline the approval for using the publishers' book descriptions in the "description" fields for the book listings.

Update: I have consolidated the list where publishers have multiple imprints and I have done some searches on all websites and collected lists of likely contact emails for each publisher.

Re #87: I would assume what you do, but descriptions of books are still copyright information or could be construed as such, so we are playing on the safe side and not just copying/pasting. I'm not talking about number of pages and author lists, but cover images, table of contents, full descriptions, back-cover details, etc... stuff that might be on their websites but might not be a "given" that we can just copy it.

Presumably they are happy to have us use this information here and this should be no problem, but the issue was raised, so I want to make sure we have a "paper trail" ... just in case. ;-)

The other reason to contact the publishers would be to make them aware of what we are doing to help market their books to the Drupal community. Maybe more publishers might adopt a policy similar to Packt’s, where they offer to share a percentage of sales with the Drupal Association. That would be cool, too, wouldn't it? :-) (So where available, I'm also collecting "partner with us / media relations" contact emails for the publishers in addition to the "permissions/legal" email addresses.)

Re #91: The /books page already does have that at the top (community documentation) but in a sense the current books pages and the new listings ARE a kind of community documentation of what books are available. The community will be able to edit the listings, help categorize them, comment on them (review the books), etc. I do think that at least having a link in the documentation section makes sense since they are likely to be read by people seeking such info (more than "marketplace" -type info). Of course we should also keep the link to /books in the "Get started" page.

Re 117 (among others): I apologize for being so out-of-the-loop for a while. I've been a bit swamped with issues on client work, so lots of late nights without time to catch up on other commitments.

Yes, I wrote a Selenium system that should allow me to move content into Drupal.org with minimal fuss. It reads a table of settings/info for a book, inserts that info into the node/add/book-listing form (including uploading the picture), copies in info from a separate html file for each book (descriptions), etc.

I can use that if I am given permissions to create "book-listing" nodes or I can lead someone else through its use. The former would probably be simplest since it's likely I'll need to tweak my scripts a bit to 1) work on d.o, and 2) be up-to-date with any changes, e.g. differences in field names on d.o.

We still need to get permission to use the publishers' official book descriptions. This stalled out with some discussion that certain people might have good contacts with the publishers that could simplify this process. But I had already gathered a list of contacts for each publisher (based on searches of their websites) and believe I could probably get us the permissions we need with a few emails.

Re #124: Actually, this is explicitly prohibited by Amazon. I asked them first. We can only get descriptions using the Amazon API, but the API does not always work correctly (I think the description info isn't always in the right field in their system). So most books got their "description" in my testing system from Amazon. It's somewhat trivial, since -- for all listings I've compared -- what Amazon displays is EXACTLY what is available from the publishers, but we should still have explicit permission from the publisher since Amazon does not hold copyright to the book descriptions, and the publishers do. ;-)

Re: 127:
My script doesn't scrape Amazon, but before they told me "no", I'd assumed we could use the descriptions from Amazon, so had text in the top of each of my book's description files which had the text "... from Amazon...", which I only changed for Packt.

No big deal. I have the text descriptions for each book. I just need to globally replace the heading "Details from Amazon" (or whatever it is) with "Details from publisher" after we have permission from each publisher to use their "official descriptions". As I said, I have yet to see such a description on Amazon (for a Drupal book) that wasn't verbatim the description on the publishers' websites.

Right... well on a password-protected testing site which isn't indexed by Google or anything, I don't really see the problem. Indeed, I'd really rather leave it there so we have a demo that publishers can approve.

After the DrupalCon, when I'm back on my home machine (where I have all the info files and the scripts), I can make some changes (e.g. get rid of old reference to Amazon on the details page)... and I could set up the script to ensure that there is another column in our import data which indicates publisher permission. Without publisher permission, full description details would not be displayed, whether or not we have a file with that info.

Re 131:

a) definitely! I'm hoping this could also take the form of a limit-one-per-authenticated-user "review" (e.g. 5-star rating).
b) This could "look like" a number of different things, depending on how we want to code it. One example (from before I realized each locale required a separate affiliate ID, but otherwise valid), can be seen on the original issue where I proposed these changes: Split the books pages into 2 (or more) subpages. This could be flag icons instead of 2-character country codes, but I prefer the latter. I've lived in countries where I could never remember what the flag looked like. :-/

1) Hmmm... I think that, since these tend to have their own ISBNs, they should have their own nodes, too. I don't know if we need an "audio" version of a Drupal book. Are there any? What I would suggest is a "media type" where options might be paperback / hard-cover or pdf / epub / mobi (three ebook formats currently most popular). Maybe the taxonomy could help see all offerings for a particular media type, but the media type should ideally be shown in the node title (if not standard paperback).
2) Agreed. But a way to fix minor typos could be nice. Versions? Ideally, nobody should be allowed to edit and add unwanted stuff, but they should be able to fix issues and someone could moderate such fixes, so I wouldn't remove all such links.
...
5) Ideally, we should mainly just change the line that indicates that the info came from Amazon, verify that the "publisher info" is the same (it has been in all cases I've seen) and make sure we have permission from all publishers. Suggestion: If we don't have permission from the publisher (to show full details of the book), we don't include the book at all—that would keep things simple and could make the "publisher" a limited "select list".

For now, I will assume that it won't be a lot of work for us to get permission from all publishers (or almost all), so I propose that the "prototype" view stays more-or-less as-is. I can easily edit the "book details" pages I have that get imported by the Selenium scripts, but I would rather take the time, first, to contact each publisher. I thought that someone else was "on that" (someone with personal contacts to the publishers), but I can easily send a simple short letter to each, based on the contact info I scraped together.

I'm looking forward to seeing this on d.o!

Following up from #5, above, since it has been a long time since others were talking about having "good contacts" with all the publishers, and since I had also gathered a list of "permissions contacts" with all the Drupal-related publishers, I've gone ahead and sent out six more emails to the remaining six publishers (some with several "imprints") from whom we still have to get permission. Hopefully they will all respond.

Packt was quick about replying that we could use their book descriptions on drupal.org. Amazon was also quick about responding that we could NOT simply copy book descriptions from them (but that we could use their API for product details, which might be a future solution). It makes sense, since the details are not actually "owned" by Amazon; at least as far as I could see, they display exactly the same info as is published on Packt and other publishers' sites so these kind of "back-cover" descriptions come from publishers, not Amazon.

This is something I've been thinking about...

Currently we only list books "about Drupal, but it makes sense (IMHO) to also include (at least at some point) other related topics of interest to Drupal community members, e.g. mobile development topics, JavaScript / jQuery, various database technologies, PHP, Symfony, HTML5, CSS3, responsive design, Agile development, project management... to name just a few topics. Such topics might actually be of greater interest to the average Drupal.org member who likely knows the basics of Drupal and can find loads of information in drupal.org’s documentation, but might need to keep up with other relevant technologies.

When I look around the office, I see a ton of books on my colleagues’ desks. We have a huge library about a wide array of development topics which support Drupal sites, but which are not actually Drupal-specific. Of course there are quite a few Drupal-specific titles around the office, but they are dwarfed by all the "related topics". I think listing such books on Drupal.org might yield more money for the Drupal association than the Drupal-specific books… and help provide more useful information to people working on Drupal-based sites.

Anyway, as regards the "Views" display and content type, of course this might mean a "primary subject" selector, where "Drupal" is the default value and where the Views display would normally only show those books, but people can add to the filtered results by selecting other topics of interest from the select list. This would probably be a new taxonomy with a limited set of values.

Maybe discussing this should be moved to a new "issue", but I wanted to put these thoughts out there for initial feedback.

Speaking of taxonomies, I haven't checked lately, but there were some small changes we (jhodgdon and I) discussed with regard to the "target audience" of the books and I changed the terms used on http://docs-infra-drupal.redesign.devdrupal.org:
Contributors, Designers/themers, Programmers, Site builders, Site administrators).

It looks like the terms currently on Drupal.org are still:
Developers and coders, Documentation contributors, Site administrators, Site users, Themers.

For me to script the staging of content onto d.o, these taxonomies should, ideally, be brought into alignment and I do think the "audience terms" on the docs staging site are more ideal than those still used on d.o.

Drupal.org (current) -> New (as on docs staging server)
Documentation contributors -> Contributors
Themers -> Designers/themers
Developers and coders Programmers
Site administrators (no change, but differentiated from "Site builders")
Site builders (new term; also appropriate for use on d.o docs where not all "site builder" info is pertinent to maintaining (administering) an existing Drupal site or vice versa)
Site users (no change; term not used for Drupal books, but still valid for Drupal.org documentation).

Great work, tvn! :-)

I've been too busy to have done much the past couple of weeks, but will try to follow up with a couple publishers I think I still need to re-contact (e.g. ones where the initial contact sent me a "referral" to another, rather than forwarding my message to the right person). I need to create a table of the "state of approvals", but most got back to me and said they were happy to have us use their book descriptions. Others wanted a full list of books for which we wanted permission to copy descriptions... so I need to take some time to follow up and follow through and send the confirmation messages to DA management, etc.

I'll try to get back to this in the next couple days.

since I don't see LoMo chiming in to say he's ready to put the content in there, I don't see what the rush is?

Okay... I'm ready (-ish) now. I'll go back to the testing site in the next day and see what needs to be changed in my Selenium generation scripts, and (of course) edit all the "description" texts to remove the attribution to Amazon (and instead say "the publisher").

There are still three publishers that I'd like to get a confirmation from and I've followed up with those. We have confirmations from Packt, Apress, Neal-Schuman, O’Reilly, and Wiley (also has "For Dummies" and Wrox imprints). This is the vast majority of the books in our list. We are waiting for confirmation from Course Technology, aka Cengage (2 titles), and Pearson / InformIt (imprints include Addison-Wesley, Peachpit Press, Prentice-Hall, Que, Sams, with a total of 5 titles in our list), but I do have a reply, received today, from Pearson’s Senior Publicist, who said she would check with her team (sounded promising). The worst-case scenario is that some of these 7 titles go up with no "full info", just the basic info and a bit of text saying we are waiting for permission to include more. I can modify the scripts to exclude the "description" texts I have for those publishers who have not confirmed our use by the time we want to take this "live".

I've just updated my information from #147. We now only have two publishers who have not finally given us the confirmation, but one of those sounds close, so I'm hopeful we might only have a couple titles without permissions for full description (or better, none), by the time we are ready to “go live”.

@jhodgdon: Please give me the access info I'll need for the new site and I'll test the scripts there, whenever you are ready. :-)

Re #154: I'd be happy to run them again, after I've done any maintenance necessary on the scripts and/or data. I just tried to log in, though, and it seems my user account no longer exists or the password is reset to random nonsense, so I'll need my account there set back to allow me to log in, with a role that allows me to create book listings, of course. I suspect the database there also does not include my email address, since I've gotten no email (I tried to use the "reset password" link, but it's been over an hour since then).

(Re #151)

LoMo: Can you edit http://drupal.org/node/1691562 with the current information on which publishers we can use, and attach your confirmation letters as text files to that page? It currently just says we can use info from Packt. Thanks!

1. I'm waiting for clarifications to what we can do and encouraging publishers’ representatives to give us fairly broad permission to copy/paste from their book descriptions in future. Some already have done so; others I want to clear up any ambiguity about whether we just have permission for titles we have discussed or also future titles (and/or possibly interesting titles not specifically about Drupal, if we decide to include any, which I still feel might be good—many sessions at recent Drupalcons have been about topics that are not Drupal-specific).
2. I'm not sure I'm comfortable with publicly posting private emails (including our email addresses and people in CC). I did not indicate to the people I was emailing that I'd be doing anything like that. But I would be happy to zip them all up and make sure that (a long list of?) interested parties all have copies in case we ever need to provide proof we had permission to copy these descriptions. Since we are not using anything other than marketing text/cover images that the publishers use to promote the books... and since we DO have permission for that, I seriously doubt anyone would ever need to see these emails.
3. Once we have clarifications of the terms of our use, I'd be happy to update that page to indicate which publishers have granted permission to copy/paste without contacting them (and which only granted permission for particular titles / who to contact for additional permissions).

This looks much better. :-)

Please email me when I should run the scripts on drupal.org. Of course my account here will need to have suitable permissions for the content type before I run (at least "create", but the edit/delete could help if anything goes wrong in the process and if they are unpublished on creation, I suppose I'd need additional perms, i.e. to access admin/content. If I have only the create permission, I suppose someone with the other necessary perms could support me via IRC, though.

I suggest we use publication date and month in the form 2012-10 (or 2011-02, etc.) This would still be sortable by date without having as loose granularity as year-only. I do see killes’s point. Date is a pretty heavy module just to use in this one place.

I've just changed this in my data files and I've also just removed the date field in the content type (in the dev site) and replaced it with an identically-named text field, 7 characters long with help text saying this should be date in form "2012-05". I think this should work in our Views display, without issues, but I'm deleting all the books and re-running the script to be sure it works well.

**Naming the field the same does not result in an input field with exactly the same name, unfortunately, due to quirks in the date module, etc. So the new date field has the name "edit-field-book-listing-date-0-value" in the node/add form ... the old one was: "edit-field-book-listing-date-0-value-date"... which might mean we need to tweak theming and Views, after all. :-/

Update. The View has only been only slightly changed for this modification.

In the "Book listing" content type, the old Date-module-provided field is gone and a text field is there in its place. If we could do a field preprocess or something, we could still have the date displayed more nicely (e.g. June 2011, instead of 2011-06), but it's not that critical.

I don't think anything else needs to be changed, but the Feature will need to be rebuilt, and any custom mods moved into it... well, however that works. I'll leave this last step to jhodgdon, but my modified scripts run through (all book listings have been deleted and re-added) and I think things are "good to go" again. :-)

I've just taken a few minutes to write a simple function to help with the date display. Perhaps it could be used to build a preprocess function for the new textual date field so that we still have more nicely displayed dates:

/**
 * Simple function to take a date in the format Year-Month (2012-05)
 * and output this as May 2012. There is no validation here, so a separate
 * function should validate the date field string format before passing it
 * to this function.
 *
 * @param string $date_string 
 *  A date in the format '2012-05'
 *
 * @return string
 *  Date in format 'May 2012'
 */
function _book_listing_print_month_year($date_string) {
  $date_string_array = explode('-', $date_string);
  $year = $date_string_array[0];
  $month = $date_string_array[1];
  switch ($month) {
    case '01':
      $month = 'January';
      break;
    case '02':
      $month = 'February';
      break;
    case '03':
      $month = 'March';
      break;
    case '04':
      $month = 'April';
      break;
    case '05':
      $month = 'May';
      break;
    case '06':
      $month = 'June';
      break;
    case '07':
      $month = 'July';
      break;
    case '08':
      $month = 'August';
      break;
    case '09':
      $month = 'September';
      break;
    case '10':
      $month = 'October';
      break;
    case '11':
      $month = 'November';
      break;
    case '12':
      $month = 'December';
      break;
  }

  return $month . ' ' . $year;
}

Re 176/177:

Thanks for taking care of the content type and Views update, and updating your scripts, LoMo!

Thank YOU for testing things and getting the Feature updated. :-)

I am not all that inclined to do anything complicated with displaying the publication month/year

I hear you. I just thought I'd write a helper function that could be used for that if we wanted to make this closer to the output we had with the Date module. It would be a bit prettier, but maybe not really worth the hassle.

Please give me a heads-up when we are ready for me to run the scripts on d.o. I usually see my email more often than I check my Dashboard here... and I could run IRC if I know that I need to be in close Drupal community contact for the process.

Any update about when we can create the content on d.o?