- 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.
Archive for April 4, 2011
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.