Problem/Motivation

The current Books page (listing published books about Drupal, currently at http://drupal.org/books) is hard to maintain, as it is a collection of several static pages.

Proposed resolution

Create a Book Listing content type, and a filterable View, to replace the current static pages.

Development site: http://docs-infra-drupal.redesign.devdrupal.org/books
Guidelines discussion: #1681566: Decide on guidelines for new Book Listings content type

Test site: http://marketplace-drupal.redesign.devdrupal.org/books

Remaining tasks

Test and deploy.

Deployment instructions

  1. Remove /books path alias from http://drupal.org/node/42200 ( admin/build/path/list/books to search )
  2. Upload and enable drupalorg_book_listings feature ( admin/build/features )
    If /books pages gives "invalid vocabulary is selected" or "illegal choice" error - go to Views ( admin/build/views ), edit the book_listings view, click on first Taxonomy:Term in Filters and select "Book availability" as the taxonomy, and select "Available" as the default. Do the same taxonomy selection in the Availability taxonomy field (near bottom of fields list). Save the view. [note: the preceding should never be necessary]
  3. Apply the patches to bluecheese, drupalorg_handbook, drupalorg_crosssite projects and clear the cache
  4. Edit taxonomy vocabularies: Drupal version, Audience, Keywords, Level, Book availability, Book format to add them to "Book listing" content type ( admin/content/taxonomy )
  5. Enable blocks "Book listing add link" and "Book listings Information", and put them on the right sidebar in that order ( admin/build/block )
  6. Edit new Book Listing content type ( admin/content/node-type/book-listing ) and set:
    • "Published" off
    • "Promoted to front page" off
    • "Sticky at top of lists" off
    • "Create new revision" on
    • "Attachments" disabled
    • Comments are turned on
  7. Go to global Theme settings ( admin/build/themes/settings ) and check off "Display post information" for Book listing
  8. Check user permissions ( admin/user/permissions ): authenticated users should be able to create book listings and edit own book listings (these are in the "features" section of permissions).

To-Dos after deployment:

1. LoMo to fill in new content type using his Selenium script
2. Manually add a link to the new Books page from Documentation landing page, and from "Understanding Drupal" http://drupal.org/documentation/understand (where Books used to be).
3. Manually delete the previous node pages for the books listings, and redirect them to /books (or if we want to get fancy, to a filtered subset of /books):

Files: 
CommentFileSizeAuthor
#176 bluecheese-books-bzr-164.patch1.62 KBjhodgdon
#176 crosssite-books-git-152_2.patch2 KBjhodgdon
#176 drupalorg-books-git-164.patch8.94 KBjhodgdon
#176 drupalorg_book_listings-6.x-1.0.tgz5.42 KBjhodgdon
#164 drupalorg_book_listing-153.tgz5.69 KBjhodgdon
#164 crosssite-books-git-152.patch2 KBjhodgdon
#164 drupalorg-books-git-164.patch8.94 KBjhodgdon
#164 bluecheese-books-bzr-164.patch1.62 KBjhodgdon
#160 drupalorg-books-git-160.patch7.8 KBjhodgdon
#160 crosssite-books-git-152.patch2 KBjhodgdon
#160 drupalorg_book_listing-153.tgz5.69 KBjhodgdon
#160 bluecheese-books-bzr-159.patch2.34 KBjhodgdon
#159 drupalorg-books-git-159.patch7.81 KBjhodgdon
#153 drupalorg_book_listing-153.tgz5.69 KBjhodgdon
#153 drupalorg-books-git-153.patch7.12 KBjhodgdon
#153 crosssite-books-git-152.patch2 KBjhodgdon
#153 bluecheese-books-bzr-152.patch2.04 KBjhodgdon
#152 drupalorg_book_listings.tgz5.68 KBjhodgdon
#152 crosssite-books-git-152.patch2 KBjhodgdon
#152 drupalorg-books-git-152.patch7.12 KBjhodgdon
#152 bluecheese-books-bzr-152.patch2.04 KBjhodgdon
#142 crosssite.patch2 KBtvn
#142 bluecheese.patch2.48 KBtvn
#142 drupalorg_book_listings.tar_.txt54 KBtvn
#142 handbook-2.patch6.2 KBtvn
#137 drupalorg_book_listings-6.x-1.0.tar_.txt5.58 KBtvn
#137 bluecheese.patch2.48 KBtvn
#137 crosssite.patch2 KBtvn
#137 handbook.patch5.92 KBtvn
#112 bluecheese-books-content-type-v3.diff2.01 KBjhodgdon
#112 crosssite-books-listing-v2_0.patch2.21 KBjhodgdon
#112 drupalorg_book_listings-v6.patch57.36 KBjhodgdon
#111 tmp.patch2.65 KBjhodgdon
#110 bluecheese-book-listings.patch2.15 KBtvn
#102 bluecheese-books-content-type-v1.diff2.13 KBjhodgdon
#102 crosssite-books-listing-v2.patch2.21 KBjhodgdon
#102 drupalorg_book_listings-v5.patch56.9 KBjhodgdon
#101 drupalorg_book_listings-v4.patch3.68 KBjhodgdon
#100 drupalorg_book_listings-v3.patch2.87 KBjhodgdon
#99 drupalorg_book_listings-v2.patch1.96 KBjhodgdon
#99 crosssite-books-listing-v2.patch2.21 KBjhodgdon
#98 drupalorg_book_listings-v1.patch1.4 KBjhodgdon
#97 bluecheese-books-content-type-v1.diff2.13 KBjhodgdon
#97 crosssite-books-listing-v1.patch2.21 KBjhodgdon
#61 authorindent.png45.07 KBjhodgdon

Comments

jhodgdon’s picture

Great proposal LoMo!

A few thoughts:
- Sub-title -- I think this should just be part of the main title field.
- "Any notes" -- we should just call this field "Description".
- Link to news & announcements -- hmmm. I'm inclined to skip this. If the Description field is formatted HTML, then you could put a link to the release announcement there; let's leave it at that.
- Order links - can't the Amazon order link be generated automatically from the ASID? Can something similar be done for Packt? I'd like to avoid the person creating the content item having to know what our particular vendor ID would be -- they're not likely to create the right links all the time.
- Preview link... again, maybe put this in the Description if it's available? And is it even necessary? I think Amazon/Packt both have some preview capability.
- Taxonomy - maybe we can just use the Keywords taxonomy that we have now for book pages? It seems like we don't need to have a separate one.

jhodgdon’s picture

Issue summary:View changes

Minor edits, links, etc

LoMo’s picture

StatusFileSize
new126.12 KB

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.)

Numbered image of existing book listings

  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.

LoMo’s picture

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.

jhodgdon’s picture

- I don't think we need to exactly replicate what is currently on the Books page.
- Google Preview: yes that is what I'm thinking, it will be less likely they would use the affiliate link to purchase.

LoMo’s picture

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?

jcnventura’s picture

ASIN is the ISBN-10.. Explaining a bit how the OOcalc file that I used to use to generate all these pages work:

I add a new ISBN-10 to a text file that is passed to a script that crawls Amazon.com and gets all the remaining info (pages, ISBN-13, title, authors, etc. etc.). The result of the crawl is a CSV file that contains the basic template for a book.. Then I copy paste that into the OOcalc file and that one takes part of that information to generate some automatic links (such as the Amazon link and the Google Preview). The only "work" is finding the Packt page for one of their books, the author links and the announcement node for a book (we used to have book announcements on the old d.o homepage, but now no one does them anymore).

Ah, and of course resizing the image is also crap..

What I'd suggest for a new book/media content type would be to do the same. Creating a book node would start by asking the ISBN-10. Then it would crawl Amazon to fill most of what remains, and allow the user to edit them before "publishing" the node. The relationship to the book author's should be handled by a cck relationship field (author numbers vary from 1 to 30+).

The new book nodes should allow for commenting, which is something that only happens when someone decides to create an announcement node for a book.

So my list of fields:

  • ISBN-10
  • Title*
  • Sub-title*
  • Author(s)* ** (possibly multiple with human name linked to Drupal.org user)
  • Drupal version(s)**
  • Publisher*
  • Date of publication*
  • Publication status** (published, upcoming, cancelled, out-of-print)
  • page count*
  • ISBN-13*
  • Website for book**
  • Publisher book webpage (only used in Packt books)**
  • Book audience** (newbies, developers, themers, etc.)
  • Cover image (imagecache)**
  • Book description** (long book description as currently available in dedicated book announcement nodes)

Where:
* would be crawled from Amazon
** needs to be inserted manually

jhodgdon’s picture

Having a crawler doesn't sound like something we can/will install on Drupal.org, and this seems more complicated than is merited. If I am adding a new book to the listing, it's really not going to take me that long to copy/paste a few fields from the Amazon page into the node creation fields, is it? We're talking about quite a bit of effort (it seems to me) to save someone a minute or two of effort each time a book-for-sale node is created, right?

LoMo’s picture

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.

jhodgdon’s picture

Here's a list of the modules currently on d.o (sorry for the formatting, it's a cut/paste of ls sites/all/modules on my d.o test server, but should at least get you going):

apachesolr                  filter_html_image_secure  path_redirect
apachesolr_mess_up_results  flag                      project
apachesolr_multisitesearch  flot                      project_dependency
autoload                    forum2                    project_git_instructions
bakery                      google_admanager          project_issue
beanstalkd                  google_analytics          project_issue_file_test
bueditor                    homebox                   site_network
cck                         html5_user_geolocation    sshkey
codefilter                  httpbl                    tracker2
comment_alter_taxonomy      image                     versioncontrol
comment_upload              imageapi                  versioncontrol_git
ctools                      imagecache                versioncontrol_project
dbtng                       imagefield                views
devel                       jquery_ui                 views_bulk_operations
diff                        link                      views_content_cache
drupal_queue                materialized_view         views_field_view
drupalorg                   memcache                  views_litepager
features                    multiple_email            waiting_queue
filefield                   paranoia
jhodgdon’s picture

Keep in mind that d.o is currently running Drupal 6, but it's supposed to be updated to D7 this year sometime (sprints may be starting this week at DrupalCon, and there's a big one planned for April).

LoMo’s picture

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?

jhodgdon’s picture

It won't be split. There is a planned sprint next month to port project* modules and anything else that needs it.

LoMo’s picture

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. ;-)

LoMo’s picture

Issue summary:View changes

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

LoMo’s picture

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.

jhodgdon’s picture

The new plan looks good! I would just amend the Taxonomies section slightly, to say that we want to use the following taxonomies from Documentation Book nodes:
Drupal version [instead of it being a stand-alone field]
Level
Audience
Keywords [note: this is the name of the "tagging" taxonomy you are I hope referencing]

And then you would have another taxonomy for
Publishing status [values: Published, Upcoming, Out of print]

Otherwise, let's go for it!

jhodgdon’s picture

Issue summary:View changes

Updated to reflect a more full development of the plan.

LoMo’s picture

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

jhodgdon’s picture

+1 green light from me. :)

I think it's OK to put in your request now for a server. jredding indicated to me that he's not so concerned with the exact formatting etc.

LoMo’s picture

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. :-)

LoMo’s picture

My request has been put in:

http://drupal.org/node/1493106

jhodgdon’s picture

Hey, I was thinking while I took a walk today (always a good time to think) and you can probably use the existing site I've been using for some other docs infrastructure issues. It's at
http://docs-infra-drupal.redesign.devdrupal.org/

You'll still need ssh access to the server in order to get anything done (such as log in as admin).

LoMo’s picture

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’s picture

@LoMo: I can provide you the current OOcalc spreadsheet so if you want to import data from that, it could make it simpler to you.

As to my comments in the now-closed issue.. I do like the way it is (but I preferred the way it was :).. However, I agree that "power-users" are probably not using that page anyway (they'd be following amazon.com sorted by release date), so no one is really interested in having the newest books on top vs. having categories. What I did have is a system that alllowed me to update that with minimum effort. After these changes the effort is increased somewhat, so I'll stop curating the list.

However, and looking forward, I see we're finally moving away from the this-is-crap-but-leave-it-until-we-make-it-a-view approach to someone getting his hands dirty.. I'd be willing to help if you need.. It'd be neat if we could eventually recycle the existing book articles to the new content-type, in order to maintain the existing system.

I'd suggest that you organize the work as a feature that is created around a book-type module. This would include the content type, imagecache presets and the view, but it might be useful to separate some code (like a mutable list of bookstores depending on the user's geo location).

LoMo’s picture

@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.

jcnventura’s picture

I'd suggest keeping the book-content-type-features-module generic.. Develop it as something that might be useful to other sites, and everyone will benefit from it (including d.o).

The reason why I chose Drupal over Mambo (yeah, that long ago), was because of the biblio module, which defines a content type and a list for scientific papers, that is useful to academic institutions and to wannabee scientists with their small collection of papers (like me).

I'd suggest looking at the Amazon module and see what could be done to improve it, instead of starting from scratch and ending up with something like the project module that is so d.o.-specific that it needs someone to come and work on it every time d.o. needs to be upgraded.

LoMo’s picture

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.

LoMo’s picture

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.

webchick’s picture

Well, we might be able to put Date module on d.o. Could you open a separate issue for that (probably in the "Drupal.org Infrastructure" queue)?

jhodgdon’s picture

tagging

LoMo’s picture

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.

jhodgdon’s picture

From IRC - drumm says that we can have the Date module on d.o when we're ready to deploy this. :)

I will go add it to the staging server...

That is done. The Date module is added to (installed/enabled) docs-infra-drupal.redesign.devdrupal.org

jhodgdon’s picture

Version I downloaded of Date is 6.x-2.8

jhodgdon’s picture

RE images on #31... What I would do is:

a) Use a file field (with image widget/formatter).
b) Set this image field so people have to upload the largest size you actually need, and don't allow anything larger than that to be uploaded.
c) Create a new imagecache preset (or presets) to resize to the smaller size(s) you need. Use those in the View and in the full Node display settings.
d) You can use CSS to make the image float to the right spot in full-node and Views page. That will be a patch to the Bluecheese theme.

Ignore the existing Imagecache presets... they are for some other purpose that we don't need to worry about, unless one of them happens to resize to the exact size that you need, in which case you don't need to create a new one.

LoMo’s picture

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’s picture

The "Advanced Flex Application Development" book covered Drupal partly at a time when almost no books covered Drupal.. Nowadays that there are 70+ with Drupal in their titles, it seems strange indeed :)

Would there be a way to provide me with enough credentials to see the links above? Currently it asks me for a username and pass.

jcnventura’s picture

Also, note that I stopped updating the German list once the German books were removed from d.o.. I know of a lot of Drupal books in Spanish, French, German and Brazilian Portuguese. Using Drupal 1st edition by webchick et al, was translated into a lot of languages :)

LoMo’s picture

@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.

jhodgdon’s picture

LoMo: Please don't grant anyone admin permissions on the docs-infra site without checking with me first -- I am also using it for other issues. jcnventura is fine to add. :)

So... I took a look at the new site. I have a few suggestions:

a) Rather than having different pages like books/current, books/current/site-builders, etc. -- just make one page called "books", with some default values for the filters, and give the user the ability to filter by Drupal version, audience, and current vs. upcoming vs. out of print. I also think it would be good if all of those filters allowed multiple selections (e.g., find books on Drupal 6 for both site builders and themers).

b) With the page full-screen like this (no right sidebar), it's hard for me to scan and associate images with books. Maybe the image should go on the left, which would probably make the images closer to the text?

c) Regarding stale modules, the server should be using the same versions that are on Drupal.org, as of a couple of weeks ago when it was built.

LoMo’s picture

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.

jhodgdon’s picture

(a) What do you mean "we need to build menus for that or something"? I don't see why, just use exposed views filters. We don't need to get fancy.

(c) I am certain that when the site was built, module config was the same as drupal.org. It's possible drupal.org has been updated in the meantime, but updating contrib modules often introduces incompatibilities (in my own experience maintaining sites), so I wouldn't count on it. Just export with what you have.

LoMo’s picture

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.

jhodgdon’s picture

Yes, of course, we are going to use this instead of the current path /books, and we can redirect any other previous URL aliases to appropriate filtered pages.

Regarding sorting -- I don't think that's a killer feature really, and having full filter capability would more than make up for it, in my opinion.

LoMo’s picture

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.

Default books view; version “next”Upcoming books view, version ”next”

LoMo’s picture

StatusFileSize
new111.47 KB

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

Version 2 of the default books display

jhodgdon’s picture

What is "archive" in #43?

Other than that, I like #43 over #42 (as stated above, I think the flexibility is better to have).

LoMo’s picture

"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)

jhodgdon’s picture

If you are still unable to ssh into the site, let me know what lines need to be added to the CSS and I will add them.

Anyway... the site looks pretty good to me!

A few comments on the current look of the books page on the test site:

a) I am confused as to why the typography is so strange on the title. I would undo everything custom you did in the view fields and see if it gets better (you should be able to just use the fields as-is). I didn't realize the book titles were links in their current state, and I think it's because they have H3 inside the A link rather than the other way around. Also, if you just use the default field formatting, you'd get bold field labels, which IMO would be a plus for scannability.

b) The order links for Packt -- should it have some kind of vendor code in it?

c) Is there going to be any difference between the full-node view and the summary in the View page? Right now I don't see any except that the image is larger. If there is no difference, I would not bother to make the book titles be links or indicate that there is a page view at all. If there is a difference, I think a "more information" link at the bottom of the listing would help make it clearer that you can click through (especially for anyone familiar with the old page, which did not have any extra information available).

d) If we are keeping the full-node page, let's make the image about half the size. Actually, I really don't see why it needs to be any bigger than on the view page, but if you want you could make it that size, and if you click on it you could get the full-size image.

e) Formatting nitipicks:
- I don't think we need the (s) on Drupal version or Level. It makes them look strange in comparison to Audience.
- Field labels should be bold (mentioned above).
- ISBN-13 label could just be ISBN
- The two "order from" labels should have the same label (Order from:) and both end with :.

f) I went to /node/add and I think the "on drupal.org" should be left out of the content type description. If you do feel it's necessary, it should be "Drupal.org" (capitalized). It probably also shouldn't start with "A book listing...", since all of the added content types omit duplicating their content type names. So it could just start with "Describes a book...".

g) I also went to the node edit page to look at that. It looks mostly good, with a few small nitpicks:
- On the author field: just tell people what to do, not "ideally", and there are some grammar/punctuation issues.... How about:
Enter list of authors' full names (as shown by publisher), with each one being a link to that author's Drupal.org user profile. Include a title attribute on each link showing the Drupal.org username; e.g., [your examples]
- Book status: "Select a term describing the book's current availability." -- none of the other vocabulary descriptions say "a term"... I think you could actually just change the vocabulary name to "Book availability" and leave out the description entirely.
- Brief notes: Can you make the help text much shorter, and not use "ideally"? Probably it's not necessary to describe in depth what it's used for.
- Publisher help - obviously you left notes for yourself to change this...
- Page count field manadatory?!?!? I think this is unlikely to be known for books that are not yet in print.
- Generally... I didn't get through the rest, but you get the idea -- make the help text short and definite.
- Maybe add help text to website field explaining this is a web site about the book, not where to purchase it? Or omit this field -- do we need it for something? Also make sure when it is output that it is "nofollow".

jhodgdon’s picture

And a couple more thoughts:

Generally, when I build D6 content types for sites, I avoid using the built-in D6 "body" field, and substitute a CCK field. The body field is special, and is very difficult to use for theming and filtering later, should that become necessary. In this case, I think I would just have one field for the description (get rid of the brief/long dual field), and just cut it off at, say, 250 characters (experiment with this cut-off) with a "read more" link at the end for the view.

And regarding the node add/edit help, I would point you at these UI text guidelines/standards:
http://drupal.org/node/604342

LoMo’s picture

StatusFileSize
new85.21 KB

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.

jhodgdon’s picture

You should be able to turn on/off display of any fields you don't want displayed for the node, on the Display Fields settings page for the content type... oh I see, you do need a template, or maybe just a preprocess function -- and hopefully just for the ISBN-10 field display and not the whole content type? That would be preferred, because then if someone adds a field at least it would get displayed. Hopefully you can take care of this.

Regarding image sizes... The cover image is not all that important and it takes up nearly a screenfull of space on the full node view. Use a smaller image and link to the larger one if you want, but don't make me scroll just to see the information I actually need. Right?

Regarding order from... You could just make the link text "Order from Amazon" and "Order from Packt", and leave off the "order from" labels entirely? Those would be more usable/accessible link text anyway. Just saying "Amazon" is not good UI design actually.

Regarding custom/rewritten fields vs. using the default field output: I would try to keep this at an absolute minimum -- like rewrite individual fields if it's entirely necessary, but don't set all of them to invisible and have one big rewrite. Those kinds of things are just really difficult to maintain, in my experience, and it's preferable to live with things not being absolutely perfect vs. impossible to maintain. IMO.

Anyway... Let me know when you're done with a round of changes and want another review, and I'll take a look.

LoMo’s picture

Status:Needs review» Active
StatusFileSize
new331.75 KB
new109.37 KB

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:

Current Views display for /books pageCurrent look of a typical book-listing node.

webchick’s picture

Status:Active» Needs review

Marking needs review. Nice work on this, LoMo!

LoMo’s picture

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.

LoMo’s picture

StatusFileSize
new11.12 KB

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.

LoMo’s picture

Status:Active» Needs review

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.

<?php
/**
 * 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;
  }
}
?>
jhodgdon’s picture

A better place for the preprocessing might be in the custom module for this feature, rather than in Bluecheese, but that looks like a good approach.

I'll make some time later today to give the test site another look. Anyone else following the issue can do so too. :)

Taxoman’s picture

Is there any way the results of this work could also be made as a "feature" for reuse on other sites?
(That would probably be a separate issue "somewhere", though.)

LoMo’s picture

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.

LoMo’s picture

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.

<?php
/**
 * 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;     
    }
  }
}
?>
LoMo’s picture

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.

jhodgdon’s picture

RE #57 - I guess it can be a bluecheese patch, but since it's code, I think it would be better to add to the drupalorg project instead of to the theme.

RE #56 - not sure what you mean by "this stuff". The content type and view will be exported as a feature eventually and added to the drupalorg project.

jhodgdon’s picture

Status:Needs review» Needs work
StatusFileSize
new45.07 KB

Sorry, I've been busy with the Drupal 7 port of the API module, and I've neglected this issue... just getting back to it.

So. I took a look at
http://docs-infra-drupal.redesign.devdrupal.org/books

It looks mostly great! I think there are only a couple of remaining things that should be fixed, and then we can make a patch and a deployment plan:

a) In the "official web site" link's title attribute, "etc" needs to have a . after it. [this is in the book listing page]

b) I did NOT like that after doing some filtering, when I then went to /books in another browser tab, it remembered the filter settings that I had used on the other tab. I think we should turn off the "remember my settings" checkbox for the exposed filters in Views, because it would make it impossible (I think) to be looking in one browser tab for current and another tab for upcoming books, for instance.

c) I don't think we need the "posted by" information to show up on individual book item pages. Turning that off should be part of the deployment plan.

d) The Status value needs to be shown for each book in /books, in case you are filtering with multiple terms selected. Also it seems to be not shown on the individual book page, and it should be.

e) The authors should not be shown twice on the book listing pages. Maybe that is specific to this book:
http://docs-infra-drupal.redesign.devdrupal.org/node/1478240

f) The authors are indented strangely on the book listing page (see authorindent.png attached screenshot).

g) When I logged in, at node/add I saw this description for the content type:
A published print-media book covering a Drupal-related topic.
What about electronic books? I think maybe we should just leave out "print-media" here.

h) When I went through to node/add/book-listing:
- Can the help/description for the Authors field give the raw HTML for the title attribute rather than the link (which isn't very useful really)? And we probably don't need two examples.
- Did you customize the "Please Choose" on the book availability or is that the default? Normally we don't use "please" in Drupal UI (I can find a reference for you if you don't believe me). So if you did customize it, put it back to the default please. :)
- Under Website: list it here -> enter it here
- Could the two ISBN fields be put next to each other?

These are all (I think/hope) fairly minor tweaks... The site looks great and is a vast improvement over what we have now -- so let's get this done!

LoMo’s picture

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.

jhodgdon’s picture

RE (c) - *someone* has to make a patch and deployment instructions for this. I was hoping it was "your department", because you would know better than I would what changes you made in the admin UI.

But just as a note, there are a couple of things I think we'd want to do on deploy:
- We know from experience on past Features that did content types that the Publishing Options (published, promote to front page, sticky) are not set by Features for content types, so we need to specify to turn off "promote to front page" after enabling the feature.
- Similarly, the installer would need to visit the theme config page and turn off "display post information" for book listing nodes, if we want it turned off.

RE (f) - OK.

RE (g) - if someone publishes an electronic-only e-book, are you saying we couldn't include it in the Books listing? That seems silly, as I think people are increasingly going that route. I think it should encompass both print and e-books, and I don't see any technical reason why it shouldn't, if they have ISBNs and stuff?

RE (h) author - yes, use HTML entity &gt; and we really only need one example please (it doesn't even have to be a real d.o user or a real author).

LoMo’s picture

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.

jhodgdon’s picture

g) OK, how about saying "published print or e-book"? :)

c) True... I'm OK either way. I was thinking that we would let anyone create/edit these book listing nodes, just like docs pages. What's your thought on that?

LoMo’s picture

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. :-/

jhodgdon’s picture

(c) further thoughts:

1) Where is this policy stated? What is a "regular publisher"? Paper books are really declining in popularity as time goes on, and the big publishing houses are losing market share. Why wouldn't we want a major Drupal project contributor's (future, hypothetical) self-published-on-Amazon but excellent e-book on Drupal 8.x to be added to the list? I think you're looking at this too narrowly. We should be inclusive rather than exclusive, if the objective is to help people find quality information.

2) What do you think people would mess up? It seems like the node/add page is pretty clear, and if it isn't, it should be made clearer in the areas you think would be problematic. What's the big deal anyway? If one of the listings is bad, and anyone can edit it, anyone can fix it too. That's the philosophy of community documentation...

3) Put a note on the node/add form about that then please, below the field in question.

4) I'm not planning to add to the responsibilities of the community docs moderators or the future curated docs team that they be the only ones to update this section. I think it needs to be open to everyone and be part of the Community Documentation, rather than maintained by a small team (or worse yet, one person), or it won't ever get updated.

Taxoman’s picture

#67:

1) "Why wouldn't we want a major Drupal project contributor's (future, hypothetical) self-published-on-Amazon but excellent e-book on Drupal 8.x to be added to the list?"

Yes, why should we not want that? Do we need any kind of restrictions at all? And if there are any, they should be documented, kept open for debate, and easy to find (...). Would be nice with a link if there is an existing info page or discussion about this "somewhere". (I am sure it has been debated.)

How about simply "whenever a book gets good reviews from the community", then it can be listed? It is newsworth for the development of the community anyway.

(On the other hand, here is where we would benefit from having a decent voting and userpoints system in place. Then we could set some rules according to that to find out a combination of good reviews, number of votes and previous author points, for example. But that is for another debate.)

I'd say that any Drupal books should be listed, and then we should find a way to assign points/votes or some kind of rating to each, and to offer (re-)sorted listings and filters based on criterias such as year, category, votes/points, price, format (ebook/etc.).

LoMo’s picture

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?

jhodgdon’s picture

People put spam on drupal.org/documentation all the time, and we have a "report to moderator" link so the community can request it be deleted. Let's just use the same system here. We'll have comments turned on too, right? So people would be able to comment on individual books. Crowd sourcing. :)

Points and voting are a separate issue, being discussed elsewhere for other purposes... not sure where though.

tvn’s picture

I took a look at the dev site and it looks great! We could tweak things like indented fields later with some theming.
One minor thing - would be good to add some "empty text' to the view for when nothing is found during filtering.

Sidebars on both listing page and individual nodes could use some blocks with useful links - like "Add a book", "Report to moderator", "All books" etc., could be done later also.

As we're adding new content type, we probably should open new issue and discuss content creation guidelines for books, and include there all requirements like permission to use the official book descriptions from publishers etc.

Right now we are also discussing such guidelines for case studies so later we could centralize guidelines for various content types here #1041394: Organize guidelines for content by type; move them to About drupal.org

jhodgdon’s picture

Sidebars: Yes, I was thinking about that. The site needs to be set up how it will be eventually -- you might need to make the view be a Block rather than a Page, and embed it on a Book page (probably via a patch to the drupalorg_handbook module), in order to get it to appear in the proper place in the Documentation outline. Or if it is not supposed to be in the Documentation outline, we need a patch in the drupalorg_crossite module to put it in whatever place it should be. In either case, we would also need a patch in drupalorg_crossite to make individual Book pages appear in the right section of the site.

Guidelines: good idea.

jhodgdon’s picture

LoMo: How are things going? Do you need any assistance to take this to completion?

jcnventura’s picture

Just a note on "the policy": It wasn't to exclude all author editions and/or ebooks.. It was just to level the playing field.

One thing that a book published by an editor has is an editor and/or a technical reviewer.. An author edition is usually only viewed by the book author (and maybe his mom) before being "released" out there.. Even Johan Falk's "Drupal 7 Essentials" suffered from this.. I spoke with him after I removed that book from the list asking for some kind of review process prior to publication, and his reply was "the swedish version was reviewed, but not the translation into English". Maybe we got lucky and his translation is spot on, but I have my concerns.. (see the original here: http://www.bokus.com/bok/9789144075440/drupal-7-borja-har/)

As to where "the policy" is stated: http://drupal.org/node/383388 (second paragraph). This page is linked from the "upcoming books" page.

There are some really bad books out there, and the best Occam's Razor was this policy.. The 2 books in the above page are pretty good IMHO, but I didn't want to play "god" when choosing books. I played an experiment (there's a thread in the Policies group in g.d.o where this is detailed), where an "Amazon SalesRank(tm)" was used to weight the books, but this also involved a robot fetching Amazon, and in the end it wasn't suitable for automation in d.o, and created too much of an overhead on the book list update process.

jhodgdon’s picture

Great, thanks for the insight! I think we can probably keep that policy for the time being at least, and we'll formalize it with a short page in this section of the style/content guide:
http://drupal.org/node/1588120

jcnventura’s picture

Just for completeness: the previous discussion on g.d.o/Drupal.org policies: http://groups.drupal.org/node/174354

LoMo’s picture

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?

jhodgdon’s picture

- I don't think we want to use Views for the individual page node display. Too complicated (comments, etc.). What is the problem you are trying to get around, specifically?
- Language field -- I think I would leave that off. Drupal.org documentation is currently English-only, and we leave documentation in other languages to the web sites maintained by those language communities. Let's also let them deal with making lists of books relevant to their language.

jhodgdon’s picture

And LoMo: Do you want someone else to take this over and get it done, or are you still planning to finish it?

LoMo’s picture

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.

jhodgdon’s picture

LoMo: What all needs to be done on this project?

LoMo’s picture

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".

LoMo’s picture

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. ;-)

jhodgdon’s picture

One other ToDo item:

c) These pages are not getting any sidebars or navigation, so we would also need to figure out where they belong, and get the appropriate section navigation and sidebars. Any thoughts on that?

Regarding (b): I don't really think that is totally necessary.

Regarding (a): Like documentation-book nodes, we could probably put this status information on the right sidebar (and it would be consistent with those pages then).

LoMo’s picture

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.

LoMo’s picture

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.

webchick’s picture

Wait. I'm confused. Why do we need permission to copy/paste what is freely available online? Especially when the whole point is to get people to buy those books?

LoMo’s picture

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.)

tvn’s picture

Great to see this is moving again.

We do not really need views for individual pages and agree with jhodgdon "b) Combine the publication fields into one line" is not really necessary.

As for the placement, they definitely should not be deep in the documentation. I do not think they belong to the main menu either. I think that we could put them into Marketplace (http://drupal.org/marketplace), adding "Books" to the subnav ("Services Hosting Training Books"). Potentially later we'll also add Jobs there.
Maybe we could also use top navigation from http://drupal.org/marketplace-preview for books listings.

All theme changes should go to Bluecheese, generally we try to re-use current theme classes etc. as much as possible.
I'll wait for you to finish current to-dos and then will take closer look on the dev site and help with some theming.

jhodgdon’s picture

RE: Placement... I think if it's in Marketplace, people are not going to notice it. I personally never go to Marketplace, and I am not sure people who might buy books would go there?

I was actually thinking that when you go to http://drupal.org/documentation, that we could add it to that sub-navigation (where it currently says "Community documentation home", "Installation guide", etc.). Then we could add a link from Marketplace to that page too.

Or we could do it the other way around (make it a sub-nav of Marketplace and put a link on the Documentation landing page).

Any votes or other ideas?

tvn’s picture

All pages in the subnav "Community documentation home", "Installation guide" etc. have "Community documentation" as a page title which will look strange for books. Also "Documentation" implies that you can read it right there, whereas you can't actually read books there - you need to buy them first. And from this perspective Marketplace seems more fitting as it suggests you to buy something. So I think it is better to make it subnav of the Marketplace and link to it from various places in Documentation to make sure people notice it.

jhodgdon’s picture

RE #91 - OK. :)

silverwing’s picture

Being a part of Drupal services makes sense. (The top nav Marketplace title is "Buy Drupal Products and Services.")

However, we really need to turn http://drupal.org/drupal-services into a real landing page instead of having the list of companies there. But that's another issue :)

LoMo’s picture

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.

silverwing’s picture

Found an old issue about placing advertisements on /books and I'm not sure how it would work now. So I thought it worth mentioning here.
#1154298: Create new ad placements on /books

jhodgdon’s picture

Assigned:LoMo» jhodgdon

I guess it's time to assign this to myself for final touches, and to get it done as soon as I can!

jhodgdon’s picture

Here are some ***preliminary*** patches for Bluecheese [work by LoMo] and drupalorg_crosssite... not ready for testing yet...

jhodgdon’s picture

StatusFileSize
new1.4 KB

One more preliminary patch (note: previous crosssite patch has a typo! don't use!).

jhodgdon’s picture

New versions of patches... still testing...

jhodgdon’s picture

StatusFileSize
new2.87 KB

One more try...

jhodgdon’s picture

StatusFileSize
new3.68 KB

Sorry about all the traffic. If someone wants to tell me a better way to transfer patch files to the dev server so I can try applying them and testing them, please do (I find it much easier to develop and make patches on my own machine with git and not via ssh/bzr). My current method is: upload the patch here, and use wget on the command line on the dev server. Crude but effective...

jhodgdon’s picture

Status:Needs work» Needs review
StatusFileSize
new56.9 KB
new2.21 KB
new2.13 KB

OK, I think I have a working set of patches now. I've added the Books pages to the Marketplace, and moved the taxonomies to the sidebar. You can check it out at:
http://docs-infra-drupal.redesign.devdrupal.org/books
and then click on individual book titles to get to the detail pages, such as:
http://docs-infra-drupal.redesign.devdrupal.org/node/1478225

I think it might be useful to test deployment on another dev site before going live on Drupal.org. The deployment will be a bit complicated:

1. Apply the attached patches to bluecheese (sorry, this is a bzr diff -- not sure how to do anything else for Bluecheese), drupalorg, and drupalorg_crosssite projects.

2. Add the Date module to drupal.org (http://drupal.org/project/date).

3. Do whatever is needed to enable the Feature that is in the drupalorg patch.

4. We know from experience on past Features that did content types that the Publishing Options (published, promote to front page, sticky) are not set by Features for content types. So after turning on the feature, someone will need to edit the new Book Listing content type:
- Turn off "promoted to front page"
- Turn off "sticky".
And on the Theme config:
- Turn off "display post information" for book listing nodes.

5. LoMo I think (??) has a way to generate the content for the existing book listing nodes once the content type is up there.

6. Add link to new Books page from Documentation landing page, and from
"Understanding Drupal" http://drupal.org/documentation/understand (where Books
used to be).

7. Redirect the previous node pages for the books listings to /books and delete them:
http://drupal.org/node/42200
http://drupal.org/node/1485156
http://drupal.org/node/1485194
http://drupal.org/node/1485204
http://drupal.org/node/1485226
http://drupal.org/node/1134466
http://drupal.org/node/1134462

8. Decide on permissions -- who should be able to create/edit book listings? I'm inclined to say "everyone with a d.o account" at least for now. Give these permissions to the appropriate role(s).

9. Decide on guidelines for books. (E-books vs. paper books? established publishers vs. self-published, and how do we decide what constitutes which -- the lines are rather blurry these days? Etc.) The current policy for books is at the top of http://drupal.org/node/383388 (rather terse). Eventually, the policy should go as a sub-page to http://drupal.org/node/1588120 -- and as a note, it should include the list of publishers whose web sites it is OK to copy/paste book descriptions from (LoMo has been managing that).

Whew! Please take a look at the new layout and let me know if I did anything stupid. And please read the deployment instructions and let me know if I forgot anything (or if you have ideas about guidelines -- items 8/9).

tvn’s picture

Thanks for finishing this one jhodgdon. I'll do a proper review early next week.

jhodgdon’s picture

Something to think about: What should go into the right sidebar on the Books landing page? Right now, nothing is in there at all (adding it to the Marketplace section didn't enable any sidebars).

Things we could put there:
- Copyright information (probably a good idea, although a lot of the info on the Books pages is not written by d.o authors -- it's book descriptions from the publishers).
- Link to add a new book listing.
- Link to the guidelines page (when we create one).

The individual book listing pages already have the book taxonomy on the right sidebar, but presumably any right sidebar block we make for the books section should also go on the individual book pages.

Thoughts?

tvn’s picture

I looked around on the dev site today, some comments:

Revisions should be enabled for book_listing content type (I did enable them).

Individual pages looking good, only I think we should remove

"Edit this page
Report to moderator"

from the sidebar if possible. We don't need to encourage edits as much on this pages as on doc pages and issues about them should probably go to webmasters queue not docs. Also I don't really want this book pages to look absolutely like documentation book pages to make a bit less confusion.

Listing view:
- titles should be changed to h2, this will be in line with other listings such as marketplace, case studies
- view should use full pager
- view has some hard-coded styles for example on images
- the view should stretch on full grid-8 width
- i think view should be changed from HTML list to unformatted, it will be easier to fix previous item and generally clean up css a bit

jhodgdon, if it is ok - I can do these changes to the view and clean up the view and css.

Another issue is filtering on the top of the listing, I'd love to have standard filtering/navigation same on all pages in the marketplace: drupal services, books, trainings, potentially jobs later. Right now filtering on the top of marketplace-preview is a bunch of custom code which we won't copy for each section. I opened an issue here to think about making this navigation flexible and usable for every section of the Marketplace: #1671320: Re-write categories navigation on top of /marketplace-preview to be more generic
I think we could probably deploy this right now, with current filtering, just something to think about.

Sidebar:
I think we should start from adding a block similar to the one on Marketplace preview and Case studies - with "Add a book" button and link to Books guidelines page. This block should not be shown on individual pages.

I'll open an issue for Books guidelines tomorrow.

Also I'd love to know more on
"5. LoMo I think (??) has a way to generate the content for the existing book listing nodes once the content type is up there." - is there a way to generate or we'll have to populate the listing manually?

tvn’s picture

Issue summary:View changes

Updated taxonomy descriptions and removed "Drupal version" as a field. It will be the existing Drupal Docs taxonomy.

jhodgdon’s picture

Thanks for the review!
- I've just edited the issue summary. The Remaining Tasks section now contains the deployment instructions from #102, with the addition from #105 on turning on revisions.
- I emailed LoMo - he's on vacation this week, and plans to come back to this issue and explain his content importing (I think) and review the changes (definitely) next week.
- I opened an issue for discussing guidelines: #1681566: Decide on guidelines for new Book Listings content type

Regarding the other questions in #105, tvn and I are going to talk shortly in IRC and decide who should do what -- will report back.

jhodgdon’s picture

Issue summary:View changes

Add standard issue summary with status

jhodgdon’s picture

Plan agreed to (I think) by tvn, silverwing, and myself in IRC just now for the ideas in #105:

a) tvn will take care of updating the view/CSS as described in section "Listing view".

b) I will take care of the "edit this page" and "report to moderator" changes. We'll actually make "report to moderator" go to the Webmasters queue for all book pages too, since most of the issue reports have been spam issues anyway. And we won't have an "Edit this page" on the sidebar of book listings.

c) We will stick with using Views filtering for now.

d) I will add a block to the drupalorg_handbook module containing:
- for people with permission there is an 'add a new book' link.
- something about copyrights on the text (which is a bit complicated for these pages)
- link to the guidelines.
And We display this block on the individual book listing pages as well as the view page.

tvn’s picture

I've updated the view and cleaned css. Also moved the field "Availability" up so "more information" link would be last, I think this makes more sense. Attached is a patch for Bluecheese, apparently it also includes the patch for #1528530: Add CSS support to Bluecheese D7 for common HTML elements in content - should I remove it or let's deploy them together?

jhodgdon’s picture

RE #108 - thanks! I don't see an attached patch... We should remove the part for #1528530: Add CSS support to Bluecheese D7 for common HTML elements in content and get that deployed separately. (I forgot to bring that other issue to office hours yesterday - can we get that on the agenda?)

Anyway, I'll take a look at what you did, make my changes, and roll new patches probably tomorrow.

tvn’s picture

StatusFileSize
new2.15 KB

Ehh, forgot an attachment indeed :) Removed superscripts part and attaching now. Neil is ready to review this issue and deploy this week. So we just need clarification on how we are going to populate new content type.

I forgot to bring that other issue to office hours yesterday - can we get that on the agenda?

sure

tvn’s picture

Issue summary:View changes

update status on guidelines

jhodgdon’s picture

StatusFileSize
new2.65 KB

Temporary interdiff patch, in testing, ignore...

jhodgdon’s picture

Issue summary:View changes

update instructions slightly

jhodgdon’s picture

OK, here are some new patches, based on the task list in #107. Some notes:

- Edit this page link - this will only appear for people who have permission to edit the page, so I didn't remove it after all.

- New patch for Bluecheese - I thought the Book Listings styles should be all in one section, and I added a newline to the end (as compared to the patch in #110).

- No change to the drupalorg_crosssite patch (re-uploaded so they are all together).

- Changes to the drupalorg patch [aside from the feature, the interdiff from the last version is in the previous comment]:
-- Moderator links - now going to Webmasters. The link does not seem to work on the dev site (I think the Webmasters project doesn't exist there), but you can copy the URL and substitute drupal.org and test that way.
-- Block added to sidebar - needs review. Note that the link to the guidelines page doesn't work on the dev site (I just added the page to the live d.o site and it does not exist on dev; again, substitute drupal.org to test the link).
-- Feature exported again (tvn made changes to the View).

tvn’s picture

I had one style at another section just to control space for all this sort of listings in one place, so when we decide to change it - it's same everywhere. If however you think it's better to move it, please change the value 2em to 2.077em.

As for the block - to make this look good I think we need 2 of them.
1st - contains:
- button-styled link "Add book listing" (class .action-button) same as we have on case studies, marketplace etc. (I can't see such button now so not sure if it's there or not)
- link to the guidelines, I think link's text should be just "Book listing guidelines" without "view", to be similar to what we have at other places
This block should have no gray background and should be visible only on listing pages.
2nd - contains the text about the copyright, has gray background and is visible on both listing pages and individual pages.

"Edit this page" and "Report to moderator" - I still think we should remove them because this content type is not something that should/will be edited a lot. And looking at the guidelines issues, seems that everyone will have permission to add/edit books and therefore will see this links.

jhodgdon’s picture

Seriously, 2.077em? That seems ridiculous... but if you want that specifically, then let's go back to the patch you posted in #100, except it needs a newline at the end of the file.

I can make those changes to the blocks, but let's wait until we decide on the guidelines for sure, because right now I wouldn't say it's certain who is going to be able to edit the listings. #1681566: Decide on guidelines for new Book Listings content type

jhodgdon’s picture

Status:Needs review» Postponed

Actually, let's postpone this issue until the guidelines are decided upon (I don't want to make another patch here and then have to change it because the guidelines are changed).

Also, hopefully LoMo will let us know how to get the content transported to Drupal.org -- we don't really want to deploy this until we have a plan for that.

jhodgdon’s picture

Anyone interested in the guidelines and workflow for getting new books listed should take a look at the proposal on http://drupal.org/node/1691562

If you have opinions, please post them on the guidelines issue:
#1681566: Decide on guidelines for new Book Listings content type
If we don't hear any dissenting opinions within a few days, we'll probably adopt these guidelines (at least for the initial release; can revisit if they become problematic).

I'll update the issue summary here too...

jhodgdon’s picture

Issue summary:View changes

another deployment instruction

jhodgdon’s picture

Changes that will need to be made to the existing patches from #112 if we adopt the proposed guidelines:
a) Add (and export) a new book format taxonomy (multi-valued -- not sure what the values should be? print, electronic ... should we be specific about electronic formats?).
b) Remove the edit this page and report to moderators links.
c) Change the sidebar blocks (see #113).
d) Possibly some CSS tweaks (see #113/#114).

And LoMo: Can you please comment here about how we can import the content for the new book listings when we deploy? We aren't going to deploy until we know how that will be done. Thanks!

tvn’s picture

re: a) - I don't think we should be specific about various formats. I suggest we use "Paperback" and "eBook" terms. And potentially someday "Audiobook"?

Taxoman’s picture

I'd say "Audiobook" is relevant already. Including that one too will help paving the way for further developments in that direction.

webchick’s picture

Dude. I'm totally going to lobby O'Reilly for Using Drupal, in the voice of Samuel L. Jackson. :D

webchick’s picture

Issue summary:View changes

status update

tvn’s picture

One more note: on the dev site sidebar block with the link to guidelines and copyright text is now being shown on every page including front page, /support, /forum etc.

LoMo’s picture

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.

tvn’s picture

Lomo, your Selenium system sounds good. (Make sure you don't add new books too fast to avoid troubles with the infra team :) )

Could you contact publishers for permissions so we have that settled before deployment?
We'll need to do some changes to patches etc., as well as work on D7 version of the listing so deployment will happen only after DrupalCon Munich, but would be good to have that one ready.

jhodgdon’s picture

tvn: In an email thread, we actually decided *not* to contact publishers for permisssions for now, I think. Most of the books are available on Amazon and we can use those descriptions.

LoMo’s picture

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. ;-)

jhodgdon’s picture

We should be discussing this (copyrights) on #1681566: Decide on guidelines for new Book Listings content type so moving there.

jhodgdon’s picture

But... wait a minute. LoMo are you saying that the information you currently are putting in the book listings on the test page, we don't have permission to post because your Selenium script is grabbing it from Amazon? If so, we should get rid of that immediately.

LoMo’s picture

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.

jhodgdon’s picture

So... are you saying that most of the information we have on the test site now is information we don't have permission to use? In which case, we need to remove it.

LoMo’s picture

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.

jhodgdon’s picture

Status:Postponed» Needs work

Some thoughts from #1681566-30: Decide on guidelines for new Book Listings content type and the previous two comments from that issue:

a) We should turn on comments.
b) Add dummy links to purchase at other Amazon stores (Canada, UK, Germany, France) to see what this would look like, so we can ask the DA to create affiliate stores there, if they're willing to.

Other ToDos from above:

1. Add (and export) a new book format taxonomy: Print, Electronic, Audio
2. Remove the "edit this page" and "report to moderators" links (since we are pre-moderating)
3. Change the sidebar blocks (see #113), and make sure the guidelines block is only visible on the correct pages.
4. CSS tweaks (see #113/#114).
5. LoMo needs to tweak his Selenium import script to have the new book taxonomy, and to make sure not to include any copyrighted information we don't have permission to post.

I think the guidelines are sufficiently agreed to that it's time to get this rolling again...

LoMo’s picture

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!

LoMo’s picture

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.

LoMo’s picture

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.

LoMo’s picture

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).

jhodgdon’s picture

RE #134 - discuss that on the Guidelines page.

RE #135 - yes we need to add that to the deployment checklist.

jhodgdon’s picture

Issue summary:View changes

typo

tvn’s picture

Issue summary:View changes

update, remove original post for easier reading

tvn’s picture

Issue summary:View changes

.

tvn’s picture

Issue summary:View changes

.

tvn’s picture

Issue summary:View changes

.

tvn’s picture

Issue summary:View changes

formats done

tvn’s picture

Issue summary:View changes

.

tvn’s picture

Issue summary:View changes

3 done

tvn’s picture

Issue summary:View changes

.

tvn’s picture

Issue summary:View changes

updating instructions

tvn’s picture

Issue summary:View changes

.

tvn’s picture

Issue summary:View changes

.

tvn’s picture

Issue summary:View changes

.

tvn’s picture

Issue summary:View changes

.

tvn’s picture

Issue summary:View changes

.

tvn’s picture

Issue summary:View changes

.

tvn’s picture

Issue summary:View changes

.

tvn’s picture

StatusFileSize
new5.92 KB
new2 KB
new2.48 KB
new5.58 KB

I finished to-dos:
- Added book format taxonomy
- Removed links from the sidebar
- Changed sidebar blocks. Left one in code and added 2nd with the button and guidelines link manually
- CSS tweaks

I went ahead and created Book availability and Book formats vocabularies on d.o, to have them ready before deployment.

Cleaned up patches, so they would apply to current d.o and deployed everything on:
http://marketplace-drupal.redesign.devdrupal.org/books

Exported feature and patches attached.
Deployment instructions in the issue summary updated. If step 1 is just term edit via UI, I'd do it now, not waiting for deployment.

Please test and we can deploy this next week.

Please open new issues for any additional features suggestions, this issue is now only about testing current version and deployment.

tvn’s picture

Status:Needs work» Needs review

The only problem now is that taxonomy term "Available" has different id on live site and dev site. So we should either manually edit feature with correct id or update views after deployment as noted in deployment instructions.

LoMo’s picture

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.

jhodgdon’s picture

Status:Needs review» Needs work

Looks pretty good! A couple of things I noticed that I think still need to be fixed:

a) When I was on the marketplace dev site as an anonymous user, I had "log in to edit this page" links in the sidebar and footer. I think those should be removed (one of the changes tvn just did was to remove the "edit this page" links for logged-in users from those spots, so for consistently I think the "log in to edit" links should also be removed).

b) Logged in as myself, I don't see any links to create a new book. Isn't there supposed to be a block for that? I have permission for node/add/book-listing so I should be able to see that link?

c) When I'm on the node/add/book-listing page, I don't see a link to the guidelines. Isn't there supposed to be a link? Actually I think the guidelines block is supposed to be visible on every book page and the book listings page too, so it seems to be missing.

tvn’s picture

a) agree, "log in to edit this page" should be removed.
Bottom one though says "login or register to post comments" - I think we could keep this one?

b) There is a block on /books page. I logged in with bananas (which has no special permissions I think) and was able to see it. Can you check again please?

c) Good point, I added message on top of the form via content type's settings.

tvn’s picture

Status:Needs work» Needs review
StatusFileSize
new6.2 KB
new54 KB
new2.48 KB
new2 KB

Removed "log in to edit this page". Updated handbook patch attached.
Updated feature attached, I also manually edited feature per #138 so it has now correct id.
Other 2 patches without changes.

jhodgdon’s picture

Status:Needs review» Needs work

This is better, but there are still a couple of problems:

a) When I'm not logged in and I go to
- http://marketplace-drupal.redesign.devdrupal.org/books (listing page)
- http://marketplace-drupal.redesign.devdrupal.org/node/1791042 (individual book page)
I am still not seeing a link to the guidelines page. I think it is important for this to be visible to everyone, so they know why a particular book is or is not included in the listings.

Even when I'm logged in, I am not seeing a link to the guidelines on the individual book pages.

b) The crosssite patch has some extra whitespace in this line:

'training' => array('title' => t('Training'), 'href' => 'training', '#active' => drupalorg_crosssite_child_of('training')),
+ 'books' => array('title' => t('Books'), 'href' => 'books', '#active' => drupalorg_crosssite_child_of('books') || drupalorg_crosssite_is_type(array('book_listing')) || drupalorg_crosssite_child_of('node/add/book-listing')),

c) [done] I went ahead and edited the Audience taxonomy on drupal.org with the suggestions in #135 from LoMo.

d) The final patch that we deploy needs to not have the "Order from test" link that is currently on the Goats book on the test site.

e) It would be great if LoMo could test his Selenium script on the current test site so we can verify that it's all working correctly before we deploy to drupal.org.

f) This line in the handbook patch cannot be correct:

++            drupalorg_crosssite_child_of('node/add/book-listing')) {

It should not have two + signs on it.

jhodgdon’s picture

Assigned:jhodgdon» Unassigned

tvn or LoMo - maybe you should assign this to yourself... I'm obviously not working on it very actively right now, just reviewing changes others do.

jhodgdon’s picture

Issue summary:View changes

.

tvn’s picture

a) block with "Add your listing" button and guidelines link is shown only on the listing page /books and only for authenticated users. Let's deploy this basic version and improve later.

d) I removed "Order from [Publisher]" field from the view. Please tell me if there is anything else I need to remove. If nothing else - I'll recreate feature again.
I'll upload updated patches for b and f with the feature.

To clarify #137 by "cleaned up patches" I meant that I applied original patches to tvn- dev site, not all of them worked. I then manually edited module files to work how we want them, created bzr diff patches off that and applied this new set of patches to fresh dev site marketplace-. Apparently it applied with extra + :/, removed it now from handbook file on marketplace-.

jhodgdon’s picture

I disagree with #145 (a). People (even unauthenticated users) need to see the guidelines. If we deploy it will never get fixed "later". Probably the block needs to be put in code so that it can display the guidelines on the right pages, and only display the "add" link on the correct pages for authorized users, as we do for other documentation-related blocks. Deploying things that need immediate fixes seems silly, and 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?

LoMo’s picture

Assigned:jhodgdon» Unassigned

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".

jhodgdon’s picture

LoMo: Thanks! Please edit the Guidelines page if you haven't already, to say that these publishers have granted us permission. And maybe forward the confirmations to someone at the DA so they can keep them on file... Or better yet attach them as text files to the Guidelines page itself? I think that might be useful so we don't lose them.

I guess we'd better get this thing finalized... I can probably work on it today.

jhodgdon’s picture

Assigned:Unassigned» jhodgdon

OK, I'm going to take on the last bit of work here now. I'll be making updates to
http://marketplace-drupal.redesign.devdrupal.org/books
and then I'll make some new patches to attach here.

Then I plan to do a test deploy on a newly created dev site, at which point hopefully LoMo can test his Selenium scripts on that site, and if we get this all done by Thursday morning, we should be able to deploy live this week and put this one to rest finally! :)

LoMo’s picture

Assigned:Unassigned» jhodgdon

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. :-)

jhodgdon’s picture

Thanks LoMo -- I will post back here when it's ready to test.

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!

jhodgdon’s picture

Issue summary:View changes

one item is done

jhodgdon’s picture

Issue summary:View changes

Edit deployment instructions

jhodgdon’s picture

OK, I've made a few tweaks to the site -- I moved the guidelines link and the "add new" button into the block that was already in code (removed the manually-added block), and fixed the typos in the earlier patches.

I also updated the deploy instructions in the issue summary, and I'm about to test them (will report back in a separate comment).

Attached are:
- zip file for the Feature (add to drupalorg project in directory features). [same as previous export]
- git diff patch for crosssite [slight change for whitespace and it's a git diff]
- git diff patch for drupalorg [combined blocks and it's a git diff]
- bzr diff patch for bluecheese [one style line removed since that block is eliminated]

jhodgdon’s picture

Issue summary:View changes

update to deploy guidelines

jhodgdon’s picture

Issue summary:View changes

update instructions

jhodgdon’s picture

Assigned:jhodgdon» Unassigned
Status:Needs work» Needs review
StatusFileSize
new2.04 KB
new2 KB
new7.12 KB
new5.69 KB

Welll... there were a few deployment glitches, mostly due to the taxonomies having different IDs on drupal.org than they did on the test sites (and I just deployed it on a newly rebuilt test site).

So here is a new patch for drupalorg and a new export of the feature. The other two patches from #152 are still fine, but I've attached them again anyway.

I think this is now ready for LoMo to test his Selenium script on, and if that goes fine, we should be ready to deploy on drupal.org I think? LoMo: The site to use is http://docs-infra-drupal.redesign.devdrupal.org/books and I've made it so you can log in as yourself using password "tmppwd".

jhodgdon’s picture

To Dos before we say this is ready to go:
- LoMo to run Selenium scripts on http://docs-infra-drupal.redesign.devdrupal.org/books
- tvn, jhodgdon, LoMo to look at http://docs-infra-drupal.redesign.devdrupal.org/books after scripts are done to see if the listings look OK.
- LoMo to edit http://drupal.org/node/1691562 (guidelines page) with list of publishers we have OK from, and attach the confirmation letters as text files to that page

LoMo’s picture

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).

LoMo’s picture

(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).
tvn’s picture

LoMo, I just set your password to "lomo" on the docs-infra site and was able to login, please try. ping me on IRC if there is anything else you need help with.

jhodgdon’s picture

RE #156 - Well, since this is a legal matter, maybe you could forward the email messages to someone who handles that kind of stuff in the DA? I just think they need to be on record somewhere besides in your email inbox. :) Thanks!

jhodgdon’s picture

StatusFileSize
new7.81 KB

tvn pointed out in IRC that we need to have two separate blocks for the add link/guidelines vs. the copyright, for consistency with training and case studies sections.

So, here's a new patch (needs testing!) for drupalorg. The other patches from #153 still are valid. I will apply this patch and report back shortly.

jhodgdon’s picture

Issue summary:View changes

update instructions again

jhodgdon’s picture

There's a typo in that previous patch (block didn't appear). And an additional bluecheese CSS addition was needed. So here is a set of new patches. Disregard any previous ones. I also edited the deploy instructions to include the new block.

Both tvn and I think this is looking good now, so I guess it's ready to commit/deploy!

jhodgdon’s picture

Since the deployment of this apparently needs to wait for a downtime (to install date module -- it alters the user table) and will therefore be delayed for a short time, we can do a couple of style tweaks suggested by LoMo:
a) Float the book images right on the node pages
b) Put the authors in-line with the Author label (have to see how this would do with the few books we have with a lot of authors).

We now have the books uploaded to the demo site (thanks Lomo!), so we should have plenty of data to test on.

LoMo also suggested a bit of formatting for the Views page:

c) "I was just thinking it might look nicer with tighter spacing between related lines (e.g. wrapped authors, etc) and a bit looser between the fields... more "type-set" with appropriate indents for wrapped groups."

As I am not a CSS wizard, I am hoping that someone else can do these tweaks... Otherwise if they don't get done before the deploy time, we can file a separate Bluecheese d7 issue and fix them later.

drumm’s picture

Status:Needs review» Needs work

I'd also like to see template_preprocess_content_field() moved into drupalorg module. We don't need it on other sites, and modules are the right place for PHP.

A 30 min downtime window will have to be scheduled with nnewton.

jhodgdon’s picture

Assigned:Unassigned» jhodgdon

Doh! Sorry about that. I'm on the job...

jhodgdon’s picture

OK, #162 and #161 are taken care of. You can see the new formatting on:
http://docs-infra-drupal.redesign.devdrupal.org/books [view]
http://docs-infra-drupal.redesign.devdrupal.org/node/1801786 [lots of authors]
http://docs-infra-drupal.redesign.devdrupal.org/node/1801774 [a few authors]
http://docs-infra-drupal.redesign.devdrupal.org/node/1801767 [one author]

Attached are new (and old) patches. Install instructions remain the same.

jhodgdon’s picture

Assigned:jhodgdon» Unassigned
Status:Needs work» Needs review

Hopefully tvn/LoMo can take a look at the site to check formatting etc., and drumm can review the patches. Thanks!

LoMo’s picture

This looks much better. :-)

tvn’s picture

Looking good, thanks Jennifer.

jhodgdon’s picture

Status:Needs review» Reviewed & tested by the community

All right, pending @drumm's review of the patches, setting to RTBC again then.

LoMo’s picture

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.

killes@www.drop.org’s picture

Status:Reviewed & tested by the community» Needs work

I am not happy to deploy date module just for a mini-feature such as a date of publication. We could use a textfield for this.

Date is a huge blob of code.

jhodgdon’s picture

OK. I wish we had known that 130 comments and 6 months ago. On #27/#29 above we filed #1504778: Please add Date module to d.o. in March, where we were told that we could deploy Date if we had a reason for it (it was marked as a dup of this issue). Now we find out that we can't. Sigh. We should have gotten a firmer decision then I guess. Processes on d.o are eternally frustrating...

So, I think the best thing will be just to have the publication year and not the entire date, to avoid formatting issues and still allow us to do some filtering.

And I think we will need a new dev site where I can test deployment again, since I will need to create a new feature and probably some different code here and there.

LoMo: your scripts, sigh, will also need some tweaking.

LoMo’s picture

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.

webchick’s picture

Yes, please YYYY-MM. a) sortable, b) year isn't quite granular enough; a lot can happen in a year. :)

LoMo’s picture

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. :-/

LoMo’s picture

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:

<?php
/**
 * 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;
}
?>
jhodgdon’s picture

Status:Needs work» Needs review
StatusFileSize
new5.42 KB
new8.94 KB
new2 KB
new1.62 KB

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

So it sounds like what we need to do is just export the feature again, have people take a final look at the dev site to make sure it looks OK, and update the deployment instructions... I took a look and I think it's fine. Here are some URLs again:
http://docs-infra-drupal.redesign.devdrupal.org/books
http://docs-infra-drupal.redesign.devdrupal.org/node/1801841 [one-author book]
http://docs-infra-drupal.redesign.devdrupal.org/node/1801856 [many-author book]

I am not all that inclined to do anything complicated with displaying the publication month/year -- I think everyone can figure out what it means as-is, and I just want to get this done. So, given that... the patches in #164 are still the ones we want to use, and here they are along with a new Features export tgz... and once again I think this is RTBC (pending drumm reviewing the patches and anyone else seeing any problems with how the pages look).

I will also go update the deployment instructions in the issue summary right after I save this. Since Date is now not involved, we shouldn't need to have a downtime in order to deploy this, right?

But... I do think it might be useful to test deployment on another site, since the feature is different, just to make sure... do we have one we can use for testing?

jhodgdon’s picture

Status:Needs review» Reviewed & tested by the community

Hm. Maybe this was enough of a test: I used Drush to disable the Date module and the book listings feature module, then I downloaded the new tgz attached above and unpacked it, then I used drush to enable the module. Everything seems to work fine, and the Features admin page on the dev site reports that the feature has not been overridden and is in its default state. So, I think we're probably OK without further testing.

That said, if drumm wants to see it tested again before final depoyment, and can point me to a dev site to use for deployment testing, I'd be happy to do that.

jhodgdon’s picture

Issue summary:View changes

new block added to instructions

LoMo’s picture

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.

LoMo’s picture

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

jhodgdon’s picture

Hi LoMo! This is currently scheduled to get deployed to drupal.org this Thursday (oct 25). I just found this out yesterday and was going to update this issue but I forgot. Sorry!

drumm’s picture

All Drupal.org deployments are frozen for #1793968: Deploy Apache Solr Search Integration 6.x-3.x. That has been rescheduled for Saturday. If that goes well, then this can go Monday.

jhodgdon’s picture

The deployment has been postponed (again). Current ETA is Sunday or Monday. It's waiting on Solr new version deployment, which continues to be problematic.

LoMo’s picture

Thanks for the update... I need to get some sleep, anyway, so I'm happy to put this off for a few more days. Hope the Solr deployment goes smoothly. :-)

Senpai’s picture

Title:Create new content type and Views for books.» Create new content type and Views for books
Status:Reviewed & tested by the community» Needs work
Issue tags:+Drupal.org D7

The drupal.org push-to-prod schedule is every Thursday at 1:00pm PDT (see https://drupal.org/website-schedule), but I don't see a D7 branch of this feature anywhere, so I'm marking it as 'needs work'.

jhodgdon’s picture

Status:Needs work» Reviewed & tested by the community

If we have to have a d7 port before deployment than this is never going to get deployed. I think that is an unacceptable criterion on an issue that was ready to deploy MONTHS ago and has been delayed through no fault of the people who worked on this.

Senpai’s picture

Status:Reviewed & tested by the community» Needs review
Issue tags:+8hr

@jhodgdon, it looks like you're the closest person to the details of this feature, so could you estimate how much time will it take to make a D7 version of this thing? One day? Two days?

jhodgdon’s picture

Status:Needs review» Reviewed & tested by the community

This is mostly just a feature (a content type with a few text fields and an image field, plus a view). I don't think these take long to port, but I have no experience porting features to d7 so I cannot say for sure. I think all that has to be done is run the update (which ports the fields?) and then open and save the view like techgirlgeek was doing yesterday, and then export the feature again (10 minutes).

Then there are a few easily-ported lines in crossssssite (10 minutes), and probably an hour of work to port the drupalorg module lines. And a few CSS additions to be added to Bluecheese (10 minutes).

So, is that 2 hours or so total? Anyway the port should really be a separate issue please. We already have way too many comments on this issue for anyone to grok.

Senpai’s picture

Assigned:Unassigned» sdboyer
Status:Reviewed & tested by the community» Needs review
Issue tags:+porting

Assigning to @sdboyer for a review of this code in light of the automated D7 build process. Sam, if nothing looks like it will break our nightlies, please give a green light on this deployment before 1pm today.

sdboyer’s picture

Status:Needs review» Reviewed & tested by the community

sorry i didn't make it by the deadline.

i don't THINK anything should break our build process here, but it's honestly hard to say without letting it run at least once. the best course of action here is really just to assume it will break, run the upgrade off the reduced snapshot so we get data, and go from there.

drumm’s picture

Assigned:sdboyer» drumm

This deployed on http://staging.devdrupal.org/. I am making some final checks and deploying.

drumm’s picture

Deployed.

jhodgdon’s picture

THANK YOU !!!!!

Should we file a separate issue for the d7 port, or has that been done?

drumm’s picture

Assigned:drumm» Unassigned

Committed basic merges to drupalorg and crosssite 7.x. They will still need attention, at least in QA. This does not include the feature code, since it will have to be recreated anyway. And does not include theme changes, because our CSS is now SASS.

Leaving open to make sure we have our D7 issues open and content migration done.

drumm’s picture

The D7 issue should be separate from this one. I'm not aware of one filed already.

An issue in http://drupal.org/project/doobie to make automated tests for the functionality is good too. They need to know what behavior to test for. Behat does either simulate a browser or drive Selenium.

tvn’s picture

Status:Reviewed & tested by the community» Fixed

Yesss!

Opened separate issue for content migration with all after-deployment to-dos: #1836258: Migrate Drupal books from book pages to new book-listing content type. LoMo please use that issue for further work with your script.

Upgrade issue: #1836252: Upgrade Book listings feature to D7
Theming issue: #1836254: Theme Book listing pages and view
I'll take care of BDD tests as well.

Closing this issue before we hit 200 comments.

Tor Arne Thune’s picture

Removed comment, as I suppose no books are migrated yet.

jhodgdon’s picture

Thanks for making those issues tvn! yes re #196, getting the content in there is #1836258: Migrate Drupal books from book pages to new book-listing content type and I already emailed LoMo to request that he run his script.

LoMo’s picture

Ah, thanks, jhodgdon, tvn, drumm, everyone. :-)

I had some problems with my home computer (built a new desktop in the end) and was also a bit ill for a while and now, for the past couple of days, experiencing a flare-up of an old back problem which is making it hard to sit very long. So anyway, it seems I missed your email, jhodgdon, but I see it now, amidst all the normal stuff that ends up in my inbox. ;-)

Well... It's getting late here now and I'm in the middle of other things, but I'll check and see if my scripts need any tweaks to run, tomorrow, then I should be able to get all the book listings created. Woohoo!

Tor Arne Thune’s picture

Gotta love scripts :) Great work, all. The new view looks very clean and helpful.

Status:Fixed» Closed (fixed)

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

LoMo’s picture

Okay... sorry it's taken so long. I had some problems finding the time to do this and then to debug the issues I found when I tried to do it. It turned out the issue was that I moved my scripts to a different machine (my notebook, since I rebuilt my home system and need to find some time to get it fully working). Anyway, I was missing the images or they weren't in the right place, and I was getting no indication of where the problem was... just the "submit" process timed out each time I tried to upload with the script. Rookie move, but I only just figured it out and got all the scripted books uploaded. There are probably a few more that I didn't have in my input data (since this process has been going on for months), so that's the next step.

Right now, all the nodes have been created, but they need to be published. :-)

I need to go now, but I'll try getting into IRC to find someone with the powah to publish (if when I get back these nodes are still unpublished).

LoMo’s picture

https://drupal.org/node/1836786 (the "Coming soon..." node) needs to be deleted now since it might be a bit confusing with all the other book listings below it.

greggles’s picture

Fixed #202 - node deleted.

LoMo’s picture

Great! Thanks... :-)

tvn’s picture

Thanks for creating book listings LoMo! We now have a separate issue for everything related to books migration, please use that one for further comments: #1836258: Migrate Drupal books from book pages to new book-listing content type.

tvn’s picture

Quick note for those who were active in this issue. The books view/content type is now live, issue queue and guidelines are in place. We need someone to take over moderation of book listing requests. If you'd like to do it, please comment in this issue: #1794810: Documenting team leaders for webmasters issue queue components.

The queue is located here: http://drupal.org/project/issues/content?status=Open&component=Books+lis...
Guidelines for book listings: http://drupal.org/node/1691562
Guidelines for reviewers (in progress): http://drupal.org/node/1860526

tvn’s picture

Issue summary:View changes

update instructions - not using date module