When I was setting up SocRelig.com, which is essentially a bibliograhy and a blog on a single scholarly topic, I considered using Drupal’s Biblio module. I knew that it was supposed to do exactly what I wanted, but at the time I wanted to learn how to use Views, so I didn’t utilize this resource. Let me quote the essential info about Biblio, so you would see too, why it makes sense:
This module allows users manage and display lists of scholarly publications.
- Import formats: PubMed, BibTex, RIS, MARC, EndNote tagged and XML.
- Export formats: BibTex, EndNote tagged and XML.
- Output styles: AMA, APA, Chicago, CSE, IEEE, MLA, Vancouver.
Instead, I brewed my own solution, that doesn’t have all these export and import format, so from a scholarly perspective it may be less usable. If I want that site to be relevant and usable for the scholarly community, I will either have to add these features to my solution or use Biblio.
The prompt for this message was a presentation I just watched. At the 2011 November meeting of the Berkeley Drupal User Group Rochelle Terman of The Townsend Center for the Humanities at UC Berkeley gave a presentation on the Biblio module. I couldn’t make it, but they recorded it using uStream. This was their first recording using this technology, so it is not perfect as the projected screen didn’t come through very sharp. Nevertheless it is still worth to watch/listen through the 69 minutes if you are interested in learning how to use this module.
Registration for the 2011 Bay Area Drupal Camp opened last night (instead of on the 5th as originally planned. By signing up in the middle of the night I became the 36th registered user/attendee. The event will be at UC Berkeley October 21-23. It promises nothing less then “A culmination of the brightest Drupal minds in the technology hub of the world.” At this point there are no workshops listed and only 6 beginner and one intermediate sessions are scheduled, but there is plenty of time till September 12 to beef up the program.
Now that I logged my learning of the Drupalcamp I attended (1, 2, 3) I can also summarize my impressions of the whole event.
- First of all I am very happy that I went, because I learned a lot and were among people. I don’t do enough of the latter nowadays.
- I am a bit disappointed as I didn’t socialize at all, didn’t have a conversation with anybody throughout the two days. I can be a bit shy in new situations, so that was a major reason for this. But also the program didn’t have any social activity built in, besides a few “Birds of a Feather” sessions. But they conflicted with other sessions I was more interested in. Lesson learned: at future Drupalcamp’s I cannot afford to be shy if I want to have a social experience as well, not just a learning one.
- I also realized, that I am no longer the most junior drupalista. I was already familiar with a lot of the content of the lectures. This was the positive way to put the fact that I didn’t have a chance to maximize my learning: about 30% of the time I was listening to things I already knew. Despite the fact that I very carefully selected which sessions to attend.
- The quality of the organization, the location and lecturers were superb. I can’t think of anything that could have been better, with the exception of extracurricular activities.
I was torn what competing session I should start off the afternoon of the second day of Drupalcamp at Stanford. After hearing about “greyboxing” yesterday for the first time I was tempted to go to Floor Vahn’s session on “The Art of Wireframing: Using the Greybox Model to Visualize the User Experience.” But when at the description of the session I found the link to Chapter Three’s excellent blog entry on the same topic and I assumed that that’s what they would present. That entry not just outlines, but explains in details the method and they even posted the downloadable templates. Thus I felt free to go to the other session on “Configuring WYSIWYG editors” During lunchbreak I asked the presenter, Jennifer Lampton of Chapter Three, whether the session will cover Drupal 6 or 7. She explained that there is only one module difference, otherwise the process is the same and that she will demonstrate the process on Drupal 6. I already managed to configure WYSIWYG on a Drupal 6 site once correctly (I hope), so I wasn’t that enthused. But on the other hand I didn’t manage to finish it on another site and it is definitely not routine for me yet. So I went and was very please with that I did, because I learned more tricks of the trade. I won’t describe the whole configuration process, because I don’t have her files yet. She said that she will later post a link to it at the session’s info page. But here are some highlights that were mostly new to me.
- In an ideal world (from the developer’s perspective) everybody would know HTML, but you cannot tell the client that they need to learn HTML.
- WYSIWYG will be part of Drupal 8, but that’s probably two years away.
- “Input format” is a bad name: it should be called “output format”
- Users should not see the the notes under the textbox explaining what tags are allowed, allowed code, what gets converted automatically (email and URL to links) and that lines break automatically. Most users wouldn’t understand it, just confusing them.
- Putting WYSIWYG onto the “Full HTML” input format is a potential security risk; create a new “input format” instead.
- Don’t let anonymous users use the input format with WYSIWYG in it.
- If you are using WYSIWYG then disable the “line break converter” filter, because the WYSIWYG editor will take care of that.
- Use <em>, not <i>; <strong>, not <b> in the setting where you whitelist what tags are allowed for the input format.
- “WYSIWYG” module provides a generic API for editor; this is the module that will go into Drupal 8
- If you uncheck the “allow users to choose default” option then the options don’t show up in the user interface, i.e. they won’t confuse the users.
- On the screen where you check what buttons should show in the user’s WYSIWYG field the linked options are plugins. These might be useful (beyond the usual ones): “removing format,” “paste from word,” “paste text,” “HTML Block format.”
- If you want consistent look and feel don’t allow people to change font colors.
- Under the “cleanup and output” section if you check the “apply source formatting” will make it easier to read the code if you need to. If you do this though then uncheck the “remove linebreaks” option.
- The “Better Formats” module (D7 in dev) establishes default user format per roles or per node types. But they are excuted in order, so you need to move the admin editor up. Which is a potential security risk, have to tighten the lower levels. It also helps to remove the “input formats” link under the body field. (Use the permissions to set up correctly what to show.)
- The “WYSIWYG filter” (D7 is planned, not in dev yet) module is a slightly more intelligent version of HTML filter.
- The “FileField Sources” module (D7 is coming along slowly) lets people to find their images from multiple sources.
The second session I attended this afternoon was John Bickar‘s “Intro to Drush” . John is Stanford’s “User Services technology Specialist.” Drush is a “veritable Swiss Army knife” that makes your life easier when maintaining Drupal sites. John’s (2 page PDF) handout is posted on the session page. It’s prety self explanatory and I don’t have notes to share beyond that. My goal for attending this session was to demystify Drush for me and it sure did. In theory I can use the basic commands now and I see how it can speed up Drupal management a great deal. However I have to keep in mind that drush disregards any security/permission settings that was set up in Drupal. it assumes that if yuo are already using Drush you are allowed to do whatever you want. In other words I can seriously mess up if I don’t know what I am doing. On the other hand a lot of routine tasks are much-much faster to get done view drush’s command line interface than via Drupal’s own GUI.
There were two options for a third session this afternoon. I was not interested in the one titled “So what’s this “Drew-paul” thing you do? (aka explaining Drupal to others).” The other session initially sounded interesting: “What you don’t know you don’t know about Drupal 6.” However the presenter posted his slides at the session description and based on that I decided I don’t need to go. More than half of the things mentioned there I already knew and the other half was clear from the slides. Thus instead of staying for a fifth session of the day I drove home and caught a family member’s birthday party that otherwise I would have missed.
The morning sessions of the Drupalcamp at Stanford is over and I am rushing to write it up before the afternoon sessions are starting.
First I attended Harris Rashid’s (another Chapter Three employee) “Theme preprocess functions in template.php” session about “How to intercepts data coming from core and modules and customize them for your own needs.”
- It was a very hands on session, going through customizing both a node.php and template.php and deconstructing the $content variable
- Started off with Acquia Prospero theme.
- Tools used: devel module, admin module, firebug, “Basic” theme (started, based on the Zen theme)
- Example: Overriding: $submitted in template.php
– look for “theme_node_submitted” function in node.module
– copy the function from there to template.php and change it
- Always override, never change a core module
- Use dpm($vars) (drupal print message) from the “Devel module” that prints out the all the variable what’s available in node
- http://api.drupal.org/api/function/check_plain – useful to sanitize content coming from users
- There was much more, but without I didn’t manage to copy the code form screen and without that it doesn’t make much sense to post more here.
The second session I attended this morning was Sean Lange‘s “Using Panels to Make Smarter Pages” One of these days I will just need to sit down and play with Panels myself. Till then it doesn’t make much sense to make notes of the steps involved. Instead I just mention some highlights that I want to remember for the future.
- An older version of Sean’s slides are available both from the Drupalcamp site and from his own at seanlange.com.
- His professional site also has good content: http://webthingee.com/
- We went through creating panels for his imaginary “Heroes of Badcamp” site.
- Use “selection rules” for defining what type of nodes should have the panes specified.
- Different panels are called “variants.” Drupal follows them in order: the first one on the appropriate list is executed.
- Advantage of having a panel with a single pane: if users click the “edit” button, they can edit only the top part. The dynamic or view part under it is left untouched.
- “Draggable views” implements a weighing system, making “rows of a view “draggable” which means that they can be rearranged by Drag’n’Drop” by the users.
- Each pane can have a visibility rule, by user role and/or node type.
- The biggest evolution for Panels in Drupal 7 is “In-place editing”
- We didn’t get to what I’d call “smarter” pages, but I still learned a lot of new functionality.
I am at my first Drupalcamp (a conference where training and discussion on Drupal is happening) ever and loving it. It is at Stanford. This morning, I wanted to check directions and parking instruction on the event’s site, but they changed the design and it was so bad that I couldn’t read anything on it. I should have taken a screenshot of it to show it to you, particular that by now (evening) the design has been restored to its regular and functional version. As a result of my imperfect instructions I parked more than a mile away from the correct location on campus, so I had to rush through campus in the hottest and most humid day of the year. (I didn’t make that up. I am staying with my cousin, who has been a professor here for 6 years, and he said that he never experienced such a day here.)
I signed in 15 minutes before the first session and mentioned that the site was illegible. They reminded me that it was April 1. finally it dawned on me that it was a prank design. And now onto what learned today on the three sessions I attended.
The first session on “How to Execute an Effective Design Process” was led by Nica Lorber. She works at ChapterThree, a drupal design and training company, that was sponsoring the event. Her talk was an extended version of her blog entry with a similar title: How To Run A Creative Design Process For A Big Project. A lot of what she shared was not new to me, because of my training in “information science”, having worked for more 15 years with web projects and in general having a mind that is geared towards architectural thinking. Her work, talk and focus was about large projects, with lots of people working on a site both from the developer and from the clients’ end. So far I didn’t find myself in such a scenario, so her tips were not applicable yet, but they all made sense. I won’t repeat everything she wrote on her blog entry that you can read, just sharing some of the highlights of my notes.
- When somebody asks what I like to do I often say that I like to organize large amount of information into accessible ways and chunks. Nica’s personal motto covered a similar idea: “What I am good at: Making sense out of the chaos.”
- Her list of tools was great, despite many of them Mac only. From the non-Mac tools I plan to check out Fireworks and Open Atrium
- Her blog entry includes a downloadable example of all the project deliverables. Very useful considering what they are: project schedule, strategy document, content inventory, site map, template page content and goals, use cases, wireframes, graphical comps, and style guide.
- The idea behind the two boldfaced entry comes from the idea that wording/content is important. This is not a new idea, but, according to Nica, that is a shift towards rediscovering it. It is the basis of a new book called “The Elements of Content Strategy“, available from ABookApart.com.
- Scenarios, uses cases, user profiles – these are all things I learned about, but never did. She did and emphasized their importance in the design process.
- New idea for me was to create a “greybox version of a wireframe“. Supposedly it is very easy to do in Fireworks and it acts as a mockup for the real site, but it is all greyscale. Useful to show it to the client as part of an earlier stage the delivery process.
The second and third sessions I attended were both about “Development best practices” and led by two Chapter Three employees: Jenifer Lampton (director of training) and David Needham (themer and trainer). Both sessions covered two topics, so essentially I had these four mini-sessions.
- Features module: The official description of the module is a good start but it doesn’t explain well enough what it can do: “The features module enables the capture and management of features in Drupal. A feature is a collection of Drupal entities which taken together satisfy a certain use-case.”
– As I understood it “Features” is a way to pack together a lot of exportable parts of a Drupal site (e.g. certain views, menus, permissions, content types…) and export them as a “feature”, that can be used as is at another installation of the same site (e.g. dev, test, live) or possible at another site.
– The example that was shown during the presentation was a photo gallery.
– We used this site for the example.
– During the QA I made notes to check out the Strongarm module (although the presenter disliked it.
– Features is good for version control within the team and managing the lifecycle of one site. Not the best of using the exact same feature on sites of multiple clients.
- GIT – “free & open source, distributed version control system”
– The notes for this part of the session can be downloaded from session’s description at the Chapter Three website.
– This session was a bit over my head as I never used extensively any versioning system. The session was going fast, as we were running out of time, so I am not sure I followed everything. But I was told that I cannot mess up totally and will be easy if I start using it.
– Important to note that “commit” does not mean “push”: you have to “push” your files and changes to the server repository from your local/dev copy.
– During the presentation I accidentally saw that the presenter is using http://www.fillerati.com/ a cool site to get “filler” text content for sites under development.
- Theming – I decided to attend this session as this one the areas that I need to learn now and am less comfortable with
– Theming is a system of overrides: base overrides core templates, sub theme overrides base theme’s templates.
– It works like “cascading template files”.
– Base and sub theme can both go to sites/all/themes.
– Each theme needs a .info file. In it name, core, engine, description, (base theme).
– Drupal will scan the disk for a css. If it doesn’t exist it will not print the link to it in HTML. (smart)
- Module writing
– The most important lesson I took away from this session: “don’t be afraid.” The presenter assured us that once you get started with it you can do it; assuming you know PHP and how to look things up at http://api.drupal.org/api/drupal
– Modules have cascading naming system. E.g. for blocks you have block.tplp.php (any block) -> block-left.tpl.php (left side block) – > block-user.tpl.php (blocks showing up for users) -> block-user-1.tpl.php (first block showing up for users).
– Every module needs a “.info” file with name, description, core, version, dependencies (if needed) and package (if we want to show up in a particular section of the Modules admin page).
– “.module” file starts with “<?php” but drupal will close this tag for you; you don’t have to.
– Need to check Context module.
– Do php things in code, not in the GUI, don’t put php code it through a text box in the GUI.
– Don’t use the Contemplate module because it slows down things and it’s a security risk too.
I spent more time working with Ubercart, a drupal ecommerce tool and couldn’t help learning a few things. :-)
- I wanted to create custom invoices as part of the ordering, order management process. I got that far that I made a modified version of the /sites/all/modules/ubercart/uc_order/uc_order-customer.tpl.php file, but it didn’t want to show up in the GUI as an invoice template I could use. So I posted my request for help at the right forum and in a few hours I got my answer. Turns out there is a little module designed for this specific purpose, called UberInvoice. It works and yet again I am grateful for the spirit of open source development.
- There is not much I can document about it, but I am happy that I now understand conditional actions in Drupal. E.g. I managed to set up the sales tax handling: 9.25% for people with California billing address. (Yes, the company I am making the site for is based in CA.) I also configured five different shipping options and prices, also using conditional actions. Pretty nifty tool.
- I also managed to install and make work a module that allows the store/site to have both specials (discounts by % of $ off on certain items) and coupons (using unique code customer gets $ or % off). It was another module, Ubercart Discounts (Alternative) that allowed me to do it. I made the mistake of thinking that I can just using it, but it didn’t work right away. Once I read and followed the “readme.txt” file’s instructions all was well. I still have some learning to do about how to set up all the possible specials and coupons, but the option I was interested in ($1-2 off from certain items) is working now.
I am in a very active stage of developing a drupal ecommerce site with Ubercart. I suspect the next few “Drupal Learning Journal” messages will relate to that. Here are a few tidbits from the rounds I did today.
- I finally manged to configure a WYSIWYG option for textboxes from scratch. (I.e. exactly those word style formatting buttons show up at exactly those fields, that I want) The site I am building is in Drupal 6, and I suspect I will need to relearn it for Drupal 7. Fortunately I am going to my first DrupalCamp this weekend and plan to attend a session devoted to this issue.
- Installed and configured SexyBookmarks, which not just looks cooler than AddThing, but also is more standard compliant. (They are both tools to enable visitors sharing the URL of the visited page at various Social networking sites.)
- Played with the image setting of the product catalog. Now the thumbnails, product images and full size product images work as they should. Lightbox works too, meaning that if you click on an image it will pull up the full size of the image in another layer of the same window.
- My best accomplishment of the day was setting up and management page of the products, where administrators can search the products by a number of criteria and the list of products is showing half 6-7 columns of related information. The best part is that then you can select any number of products and do some actions with them in batch, e.g unpublishing them (out of stock), re-publish them (back in stock), adjust price and a few other tricks.
There is an yet-unsolved bug in the Media module (for Drupal 7) that prevented us from making the video gallery of a site work that we ported from one host to another. The issue has been documented and discussed here, here, here and here. We couldn’t wait any longer so I worked out a relatively simple substitute. There were only a few features that I had to keep in mind when thinking of a different solution:
- Paging through one video to the next within a category was a must.
- Providing a title, tags and description of each video was also required.
- On the gallery page display I could use thumbnail images only, because embedding more than one YouTube video on a webpage might cause problems.
- The site doesn’t have a lot of videos: 18+4 in two categories, so at this point the solution didn’t have to be hugely scalable.
One of the main features of Drupal’s “books” content type is the ability of paging through content, so it was obvious that I had to create my first “book” for this video gallery to satisfy criteria #1. I learned two lessons in “writing” my first book:
- Any type of content can be made a page or top page/cover of a book, but you have to put it on the list of “Content types allowed in book outlines” at “/admin/content/book/settings”.
- Only published content can be made part of a book. My original plan for this video gallery was to set it all up of unpublished pages, get the client (who has admin rights on the site) to view and approve it and then build out the whole gallery. But I couldn’t do the unpublished beta as part of a “book” so I created the gallery at temporary/secret URL for the client’s approval. Once that happened I finished building the gallery (, unpublished the old one) and specified its URL to be the same as the old, non-functioning gallery’s URL.
To make sure that criteria #2 is ideally handled I made a custom content type for the individual videos, imaginatively named “Videos”, with only the few fields needed: title, tag, description and I used the default” body” field for the HTML code of the YouTube/Vimeo embedding code. I had to pay to attention to two things with the code:
- Getting the correct code: The default code you get on YouTube when you click on the “embed” button under a video has changed recently to an “iframe” solution from the older “object/embed” method. The problem with the new system is that it is possible in some browsers to disable “iframes”, so those visitors who do that would not see the videos on our site. Fortunately the old method is still available, but you have to check the “Use old embed code” checkbox to get it. I also made sure that the other checkboxes are unchecked. (I just read the description of what the “Enable privacy-enhanced mode” checkbox does and in the future I will check that.)
- Posting the correct code: I made sure that the text format for the field on our site where I am pasting the code accepts the “object” tag. Otherwise after posting the code Drupal would simply strip it out as it does with every tag that is not explicitly listed as an acceptable one. The default text formats (Plain text and Safe HTML) do not allow the “object” tag as there is a possibility of malicious misuse, so I selected a different text format.
I could have used “Views” to make the main/top gallery page, but in this case it was faster and simpler to do a simple HTML table and paste it in “body” field of the book’s top page. Voila, the gallery is up and running. The only aspect I didn’t like about my solution that below the table of thumbnails is the list of book pages, therefore there is duplication of content. I could have created an appropriately modified tpl.php file, but that would take more time than avoiding this minor visual redundancy is worth. If there is another way to disable the listing of page son the top book page, please somebody let me know. I didn’t find it.
I have been slowly working on several sites and in the process discovered some useful modules.
Field Permissions “allows site administrators to set field-level permissions.”
- Why would you need such a thing? The idea is that certain fields could be viewed by certain roles only. E.g. I decided to add the distributors of the films I am listing at my Jewish Film Festivals site. However I am hoping to come up with a business model where this site can generate some revenue. So one of the benefits for paying members would be the access to the distributors. So I set it that the distributor info only shows up for people with the right role.
- Yes, I am aware that what I am gathering is freely available on the web, but I am putting a lot of time pulling this scattered information into one central location.
- The module has only a dev version for Drupal 7, but is working fine, i.e. there is no bug posted in its issue queue. The Drupal 6 version is solid.
Password Strength is a module that administrators can use to “restrict passwords to only be, for example, “high” strength.”
- I thought it was too inconvenient for potential users to of one of the site I was working on being forced to create a password that had to have all of these:
– at least 6 characters
– both upper and lowercase letters
- With the help of the Password Strength module I could lower the minimum characters for password to four and set the number of rules the passwords have to comply with lower.
- The module exists only for Drupal 5 and 6.
An editable grid–where content of nodes and their fields are displayed in a table format with the content of each cell editable right there–would often come handy. I’ve seen something like that in Drupal so I thought it is possible with off-the-shelf modules. My first implementation is halfway successful. With the help of the Slickgrid module I have a table where if I click on a cell I get a pop-up layer where I can edit the content. Next time I will want something without the pop-up layer, so I could edit many cells at the same time. Slickgrid works fine (for Drupal 6), but was not what I was looking for. On the plus side it required the Beautytips module, which is a great way to add balloons to any content any where. That’s a good discovery, helpful for explanation or help features.