DrupalCon Paris: Amy's notes, day 1
If you are not at drupalcon or are not a drupal user, feel free to skip this post entirely. These are just my notes from the sessions I attended.
Extension to code freeze. Obvious reasons; some things just aren't ready, and some of the majors are worth postponing for. No big shock there, at least to me. Concept of beginning effort on the next version right around the time the current version starts to plateau. My question, though: I see a significant chunk of the development time is coming from a few major people instead of an evenly distributed larger group; does a one-year development cycle run the risk of burning out those few people who are growing more critical over time? (Earl, Jeff, etc.) Framework versus product (something that you build on versus something you push a button on).
Drupal 7 status -- Angie Byron
- Lots of UX changes.
- Password friendliness
- Vertical tabs.
- Created an 'administrator' role.
- Shortcut bar in admin area!
- Overlays in admin area -- when choosing options an overlay screen shows up and then can be closed
- Edit-in-place for blocks, etc.
- Click 'authenticated user' for a permission, all authed roles get checked automatically
- Beginnings of install profile -- including a 'minimal' profile
- Finally got rid of 'story' type b/c no one knew whatit was
- Info architecture: dealing with content, building structure, changing appearance, managing people, configuring modules. Splitting things apart into these sections.
- Resplitting the items on the main admin page along the lines of info architecture listed above
- Site builders: more database support, better timezone support (you odn't have to set timezones manually when there is a DST change)
- Better image handling in core
- ImageCache in core
Cron.php is more secure
Limit on login attempts
New permission for running site updates so you don't have to be user/1 -- means site updates could be outsourced to someone not the full siteadmin
Lots of modules swapped in and out.
CCK added to core.
.tpl.php files are being revamped. Improving so that CSS-only designs are easier. Trying to prevent designers from needing to know PHP.
changes to $content
fieldAPI - you can add fields to anything
bunch of new hooks
Coder module should make it easier to help migrate contrib modules to D7.
First after-lunch session
skipped - caught Alex U. and talked about tech and libraries - found out he's about to bid on a library-related job, and by the time we were done, I realized that I couldn't get a seat with plugin space in the Acquia room, which was the only one that marginally interested me
Sustainable theming, caroltron and johnalbin
It's not just about now, but later, the things you cannot anticipate, including working with a group instead of just working by yourself.
Stating the obvious, you need to finish your data architecture before you start crafting your CSS
Build your content types before building your CSS
Add in your content and build your views before doing CSS
Don't fiddle with .tpl.php files until you really have to. Use admin settings to hide fields if you have to.
Try to work with the CSS provided by modules instead of theming, to guard against changes
cck_exclude? Might help to hide fields? CCK -> display settings -> there's a checkbox for "exclude from teaser" and "exclude from full node"
You can rearrange CCK fields in $content? Look into that.
Theme from the top down. Theme generic tables. Generic views. Then do smaller overrides to individual items
Make yourself replaceable.
Don't remove or modify markup, rearrange first
Consider ease of workflow before ease of theming
Use the admin menu before using the .tpl file
Why use Zen?
- CSS is broken out by task
- Layout method for markup source reordering
- Flexible and complex designs, predictable markup and CSS
Better for if you have multiple themers working on a project simultaneously
Drupal isn't a website. It manages your content.
Skinning is not theming.
module written: IE CSS Optimizer -- adds a toggle to the settings/performance page so that CSS aggregation isn't just enable/disable, but enable / enable only module CSS aggregation / disable -- this will help with the problem of IE only allowing a max of ~30 CSS files per page. Means you don't have to edit - flush - reload all the (*@$&)@ time.
look into the menu-block module that John wrote -- might help with making modules self-maintainable. it's intended to overcome the limitation of drupal core int hat it shows up every child of every menu -- too much info. This pares it down to 2 levels tops and can be used to pare things down and make menus usable and stylable on a page.
Discuss use cases for taxonomy.
D6 explanation - nothing new for me.
Yes, I know -- classification is a single sort, but taxonomy is more comprehensive and complex.
Obviously, taxonomy + views is money.
Families of contrib for taxonomies:
- manage -
- input terms - content taxonomy, active tags, taxonomy manager, taxonomy image, term fields
- displaytagadelic, similar by terms, taxonomy blocks
- import / export - taxonomy import by xml, feed element mapper + feed api, taxonomy csv import
- structure - taxonomy manager, community tags
- auto-categorize - suggested terms, calais, auto tag, open dover, taxonomy autotagger
Use it as an argument to view
Use taxonomy breadcrumb or 'menu trails' to create context and navigation
workflow - "taxonomy hide", "taxonomy manager"
Top 10 most used:
- taxonomy menu,
- content taxonomy - CCK field type for referencing taxonomy terms, more flexible than core taxonomy fields. D7 -- taxonomy fields are in core. This could be important for hmcpl.org.
- tax manager - tool for managing large sets of terms, doing work en masse.
- feed element mapper,
- tax breadcrumb,
- menu trails,
- tax image,
- tax access control,
- tax access control lite
Look at the 'active tags' module -- shows the tags you've entered above the fields, so you don't have to separate terms with commas.
Hierarchical select makes it easier to work through selecting from hierarchical list.
Changes in D7....
- Since everything is fieldable, terms can get more info other than just a name. Look for synonym-related features.
- New hooks allow us to perform taxonomy work in more places than add or delete.
- Taxonomy terms can now apparently appear in more than one vocabulary? No longer have to bend vocabs to our content?
Building mobile sites with Drupal
Siruna is an open source comapny, yay
Less than 35% of sites have mobile sites, Less than 60% of users report success doing tasks on mobile sites
Driving the move to mobile: facebook, twitter, rss, yelp, google
There is a mobile version of zen?
Complexity: device fragmentation (devices, OS, capabilities), usability (less scrolling, links clickable, easy nav), how to bring users there? (separate urls? redirection?)
Going from a multi-column site to a single-colormn site. You have to go generic.
No fixed margins, no floats, no fixed fonts, reduce table usage, put nav in a dropdown list, strip out extras like who is online or who is new. Separate versions for iphone and android.
Optional extras: remove node content from the front page. Overview blocks can be reduced to link point to page views. Keep the front page as simple as possible. Let users choose what they need with a minimum of scrolling.
Overview of Mobile Tools module -- device detection, switching, functionality + content, theming. Rocks pretty hard, actually. First auto-detect that's actually worked properly for me.
Goals: get everything mobile-related into one module. Device detection, user notification (I see you surf mobile, try this!), redirection, mobile permissions, theme switching
Do redirection properly and users won't have to know two URLs. Do seamless transitions. Be classy about it.
Mobile context now in the permission system.
Theme switching: switch on device group, based on domain name, or per device group (android, iPhone, etc.)
Creating the mobile look... either you have to create your own theme, or use an adaptation service
Now a heavy demo of Siruna. I'm wondering if any of the major contrib themes have developed mobile versions.