emergency weblog; or: epersonae; or: elaine nelson

in which I write about stuff

PNW Drupal Summit, Day 2

More D7 previews: theming & JavaScript. Also Panels 3, Staging & Deployment.

Categories: conference notes, pnwds

Theming, with John Albin Wilkins (johnalbin) from Taiwan

[still no wifi! altho at some point in here I figured out how to connect via a router from the lovely CivicActions folks.]

fun chitchat in the fiber-scifi-geek gal corner. :)

D6 core themes: 75% themes that suck; 25% Garland – gave people a bad 1st impression
D7: Garland, Stark, Seven

Stark: nothing in it. .info, layout.css, no .tpl.php! still not done with redoing HTML markup in core. Stark allows you to see basic markup.

Seven: Mark Boulton’s admin theme, usability testing showed people when editing because they couldn’t sense the difference between content mode & editing mode. Is default for admin.

Missing piece in the pie chart…might still get some more themes into core. (paint? zen? – my musings, not what he said.)

Showing a default brand new D7 site. “Appearance” link. He added a “pacific” theme for this presentation.

Don’t have to go to separate page to set admin theme!!!!!

Primary & secondary menus renamed: main & secondary.

Looking at page.tpl.php – $main_menu & $secondary_menu – a bunch of variable renaming to make things easier to grasp. sidebar_first and sidebar_second – renamed from “left” and “right” because of RTL language issues. (and I can see where you might do a site with two sidebars both on a single “side”) shows amnesty international site, switches between English & Arabic (also french & spanish), flips the entire design. (a little dance while we’re waiting!) which makes “sidebar_right” a WTF for RTL language developers! first and second is more natural.

template.php – can’t shoot yrself in the foot. “phptemplate”? (missed a bit while switching my phone 2 vibrate)

switches to pacific theme – something about classes – a bit confused about what this change means. is using devel & template function to spit out all page info. classes_array. makes it easier to add stuff to body classes. screwiness with what’s actually showing up in the array. “what happens when you do a live presentation” shows classes being set for the particular block, again, in an array. classes_array[0] = ‘block’ etc. preprocess function, also now process functions, get run after preprocess functions. can turn array created in preprocess into string that can be printed in tpl file. “let me go clear the cache” all caches vs just theme registry? “let’s pretend that worked” o.O?

hated $submitted in D6 – string that had user’s name and date, smushed stuff inside one variable. node.tpl – $name variable, $date variable. Oh, I think I get that now. Also fixed in comments.tpl.

$contextual links – yes, it is like in the Zen D6 block editing thing – but in D7 is extended to lots of things. Can go directly to the admin for menus, for example. (yay!) (how would that look on a dropdown/suckerfish menu? create style specifically for contextual link?)

more page.tpl – mission statement completely removed both from site info and as a variable. same thing with search box variable. D6 theme had search template & checkbox in settings, but wd be greyed out if you didn’t have search enabled, instead show automatically based on template files. (help text is a block too!) I’m a hair confused, but I think that might make more sense once I get to play with it. (one of these days.) All themes need a help region.

$message (footer?) variable that was hard-coded, now custom block. (which I was doing already, I think.)
main page content. content is a region, main page content is a block. could put recent comments in the content region above the main page content, for example. (menu_block module?)

jquery ui (yay!) now included.

granular theming…render($page[‘content’]) in page.tpl instead of printing content region. means that — ah, missed it! arrays that we can modify, may take a while to figure out how to do it.

top & bottom of html no longer in page.tpl – now have html.tpl – easier to generate styles and scripts. (o look: RDFa in doctype.)

issue for allowing themes to alter page? a bit confused. may or may not happen. for little tweaks to forms. I sorta kinda understand, altho not entirely.

JS in D7

interfering with other libraries

wrap everything in:
(function($) {
…yr code…
})(jQuery);
otherwise get JS alert. NEED TO REMEMBER THIS.

drupal_add_js (actually, I’ve never used that, I don’t think) – changed a lot in D7, more parameters. also add external.

want latest jQuery, but isn’t in core! use hook_js_alter to swap out for latest.

rendering arrays, pass in attached property, this output needs this JS. so, ok, homepage has its own little thing w/slides, use attach to add just to that thing? not sure.

no standard way of adding jQuery plugins, etc. now can define a library – hook_library, so system_library includes $libraries[‘vertical-tabs’] – then need to call to actually use. can pass settings and dependencies as well. then use drupal_add_library in template functions.

AHAH forms – example? quicktabs module admin form, adding a new element to the form. holy moley, that’s a lot of code to put in the new form element, and first big chunk of code goes into ANY similar item. new code: 3 lines.

now a framework for ajax in D7. showing ajax.inc, all the form processing that was in form.inc and it just does work for you! series of php functions, sends JSON — handwave-y stuff.

examples module in D7, to show how to use new stuff. :)

was looking at documentation – noticed mention of using class & link, attach behavior. neat! but doesn’t actually work in core as-is. :( shows her hacking. I think she just said that the link will go to a real thing if JS not avail. she added her own render_link function. has been submitted to/as RTBC?

stuff going kinda over my head. :) JS and my brain are not exactly friends, adding in Drupal coding…yeah. I think eventually this will make things vastly easier, but not quite yet.

she actually asked if eyes are glazing over. in my case, yes, but not everybody.

yep, jQuery UI in core. only loads when needed. super-easy to get accordion. yay! now I can do super neato stuff with annual reports!

misc code changes, both in behaviors and in naming. and a function to make sure a behavior only gets attached once.

just seems like lots easier stuff.

materials will be online, but caveat that she’s using a patched version of core in re: that one function mentioned earlier. will include link to issues related.

Q: will this enable drag & drop, infinite scrolling stuff like other sites? a lot of that in jQuery UI. Q: will there be standard way to include/manage libraries? if 2 modules define same plugin, if they use the same version, will only get added once. :) huge amount of discussion about that. Q: anything going to be rolled back into D6? some stuff has workarounds in D6.

Panels 3 (yes, this is the version I’m using)

would rather be sailing? srsly?

super-excited to be talking abt panels. panels.anguspratt.com

might be skipping some stuff he doesn’t quite yet grok. heh.

how much collision: always lots of ways of doing [x] in drupal. no kidding.

terminology. audience: “pane is a great name…they just spelled it wrong.”

logged in vs not logged in page. basically like Star City site.

audience advice to show the UI. yep.

can u have pane inside page w/out panel? no.

[warm in here. can haz AC?]

contexts w/features — also works w/panels? or is it using the same word for different modules. can’t quite grasp how context is different from relationship. info about how data elements are connected.

ashley asking for more info…context only knows about UI? another audience talking abt panels 2, use case: news section for nonprofit site, each article had taxonomy, full page view, block with “other new jersey news” not easy to do. panels & context, grab the taxonomy from the main node, then make available in another pane in that panel and use as a filter.

NO, this is NOT the same as the module context! panes know about other panes. many contexts at once in panels. (great audience input on this session!) you can write a module that creates its own context.

panel node: [what was I going to write here, anyway? probly something about exposing panels to search.]

creating context automatically = a relationship? am very very very confused. Jen just explained, and I was unfortunately looking at something else. context can take info from URL and pass in, if you need to define explicity connection between info in the panel, that becomes a relationship. (I’m wondering if there’s some significant changes in terms from P2 to P3.)

some settings warnings.

selector rules, including custom PHP. o rly? put most specific first, general later, if nothing matches, have default. different stuff at the same URL.

don’t use flexible — bogs down. good for wireframing. hrm. check out the template files, can define custom layout in custom module? panels3 has way more terminology for layouts. what’s the benefit of having made it so much more complicated? making regions more general to get away from table-concept layout. “because it was written by a developer” heh.

hm, use “variants” for panels? instead of how I actually did it. should make the layout much easier, plus remembering what should and should not be visible.

oh, can turn off Drupal blocks with a checkbox. wow, making me feel dumb.

the layout designer. lots of discussion about how stuff works.

panels or blocks? a dashboard in a panel, rest of the site uses blocks. performance hit issues? block visibility setting in theme setting? can be done, can be PITA.

“thank you for this interactive presentation” [that’s one of my favorite things about this session, lots of audience expertise/experience.]

“just the code that was importing the variants was completely wrong”

caching…which would be good for some of those relatively static bits. override settings in the node itself, etc. don’t forget that you set something in panels!

blocks show up in miscellaneous.

whew, there’s a lot going on with this!

Staging & Deployment – Greg D (heyrocker)

deployment is well understood in traditional software (website?) deployment

Drupal puts lots in the DB that you might not normally put there. Contemplate module (evil! but I like it. :( ) and PHP in blocks or content (do that a lot too) – and stuff moves both ways. testing data over here – comments over there. can’t push anything either direction! “to launch a huge bunch of changes…and you’re screwed.” I remember him first talking about this at a Seattle Times related event. not a lot of tools. :( I think it’s not just “large development shops” but people who don’t fly by the seat of their pants. Normally I wouldn’t care about just doing stuff to a site, but doesn’t work w/work site.

content and configuration have very different issues. “going to assume that everybody’s pretty nerdy” node ids not matching (primary keys), pieces of data that didn’t have any APIs. no “role_load” etc. Config has no standards for how to set from module to another or for exportability. Plus all that other stuff. Exporting blocks from dev to live. (Yep. I’ve been just recreating stuff from scratch each time, like recent addition of [????! oh, yeah, https://www.twinstarcu.com/repo/home – created just last week IIRC]

nice simpsons quote – cause of and solution to all life’s problems

hook_form_alter – in a module, inject terms of service into registration form, for example. oh, that’s what that’s about. 80% that drupal works is because of hook_form_alter. but…makes exporting INSANE. when node goes out, no way to make sure the module stuff comes with the node or form.

nice graphic of picard & riker.

options that suck: develop on production (this is what I meant by “seat of pants”); repeat by hand (hey, that’s what I’ve done!).

move db stuff into code. okaaaaaay. (what does that mean, exactly?)

find import/export mechanism, write update hook.

devel macro module – d5. records things that you do, saves into a file, puts into an update hook, run execute. (ok, lost something there) but doesn’t quite work in D6.

views/panels/cck export & import mechanisms.

patterns?

programmatic cck, managing views in code, a lullabot article.

if I make 15 views, have to remember to export, and make sure client doesn’t change anything. gah.
“this thing kinda makes me sick” – reserved key ids, auto-inc ids on dev at 1, on live at 1001, module to move over, and supposedly get clear set of IDs. “this is bad” and yet I find it weird & fascinating. odd and even IDs?! wtf.

database scripts module automates that process, worth looking at, keep DB dumps in version control. huh. I’ve never used version control for anything, and probably should try it. :\ not always db-portable, not community-oriented solutions.

5 species develop at the same time. (2nd time I’ve heard that analogy.)

Exportables – concept more than thing. part of CTools. talk abt bringing into core for D8. you have to write yr own import stuff. kind of a hook thing for modules, etc. “in 3 years we may have something that really works well”

Features – development seed thing. refers to Robin’s talk. ack. that kinda sorta went over my head. built on the exportables concept. curious. context and “spaces” — that last new to me.

Deploy – that he wrote. For pushing content around – foreign affairs magazine, write content on editorial server and push to live server: unwilling to accept usual drupal way. group pieces to go live together. I like that. (for promos!!!!) Services module – core API. “deployment plan” way to group together stuff to the live site. modules then integrate. Uses services to receive & manage deployed data. Implements UUIDs to alleviate primary key issues. if you add a node & choose to deploy, will also pull along nodes referenced, taxonomies, etc. Oh, like Dreamweaver FTP publish dependencies. (which I always turn off in DW, but might be useful here.)

example: content about drupal books. deploy has stuff, live is blank. “add to deployment plan” XMLRPC? works for anything in drupal that uses [setting forms?]. doesn’t work with blocks? for content type, uses cck copy, can’t push updates to existing fields. OMG. that would’ve made that foreclosed homes page EVEN EASIER to set up. pushing live. needs to be logged in with a user on the remote server that has sufficient permissions, ATM need to enter pwd every time, which is honestly ok by me. 6 things in plan, but pushing 32 items, and in an order where nothing breaks. doesn’t push permissions or roles, but does push users. “nothing up my sleeves” duuuuude.

and can deploy nodes immediately after editing on dev. some sort of counting error, tho.

image: services module has files service, works with all binary types, and works with drupal security.

directionally agnostic – q of whether can push back to dev. yep. actually got automated pulling content back into dev for foreign relations, altho couldn’t release as part of contrib module.

no rollback, that’s where to go from there.

if not using pathauto, there will be issues.

Issues: revisioning, rollback, mysqldump before pushing. can’t do unattended deployments. gaps: upload.module, translations, block, permissions.

no magic bullets – investigate, ask questions, know yr needs, PLAN. sounds a lot like my work doing import/export on the initial setup. missed what group is talking abt that stuff. [change mgmt group] lot of activity around this area, likely to be a focus for D8. bring up use cases, do testing.

how does update.php factor in? not w/Deploy, doesn’t use it at all, not pushing changes to code. update.php is mostly for code.

I’m really glad I stuck around for this one, actually. I’ve got some (admittedly vague) idea of how to handle future updates, especially in adding new features. might try it out for top-secret project I want to pull together this week.

Comment feed

Comments are closed.