Drupal Learning Journal 24. Drupalcamp, day 2, afternoon

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.