Copenhagen Day 1 - Drupalcon!
This busy first conference day has my head spinning. I arrived in time to catch the tail end of the commerce in drupal session, and my first impression is that it looks like Ubercart. My first full session was the BoF on Drupal for NGOs and not-for-profits; a rich topic deserving its own blog post (later this week). I met a fellow from Oxfam International and he expressed interest in working with us, possibly for an Ægir deployment, and somehow got signed up to organise a BoF on thursday.
Dries keynote, on where Drupal will be 2020, among other things, was a fun pep talk though I can't say I took away any lasting impressions.
I started my afternoon in a Drupal: The Next Generation talk on improving context awareness in Drupal covered performance issues, and more flexible layout and context systems for Drupal 8, accompanied by lots of admonishments to sprint on Drupal 7 issues at Friday's codesprint. The ideas look interesting but are not fully formed; there's lots of room for folks to get involved in a discussion and development of better context and rendering layers in the butler group.
Antoine went to the Varnish session, and you should read his comment on the subject. I originally and erroneously satted he said we "should use nginx".
Then on to a security configuration session. I added a few things to DrupalSecurity in the wiki, and while I was in there, I commented out the acl, since that page is valuable as documentation to the Drupal community in general and I did not see anything in it that is sensitive.
Apparently, cross-site scripting has been demonstrated to effect 60% of websites on the internet, and they showed us real-world examples of tag and devel module related Drupal vulnerabilities.
On my way to Advanced Drush Omar told me he was excited about a session called 'A Method For Getting Early Estimates Right' - hopefully a brown-bag lunch for all us budding Koumbit salespeople.
Most of my afternoon was spent in developer sessions. I've attached my notes at the end of this post.
While Omar and Antoine headed to Foubar I wandered over to the coder lounge, and spent a productive evening talking git, retheming my blog and working on a contrib field handler. We all got to bed pretty late.
Copenhagen, DK
Advanced Drush announced some exciting new features in Drush 4, including user management, limited field management for Drupal 7, drush help --html, and drush sql-sync --sanitize which will wipe email addresses and passwords from the database and allows modules to write their own sanitize functions.
In Drush 3 you can check out core-cli, site aliases ala @www.koumbit.org, sql-sync, rsync and site-upgrade. Site aliases, by the way, are being built into Ægir.
As a fun exercise for those of you with drush 3 on your own machines, try out drush -i ./examples mmas and sudo drush -i ./examples mmas turkey --spreads=mayo You'll find the code for this in drush/examples.
Omar's feature tip of the day: if you have two (or more) features dependent on common elements, e.g. imagecache presets, it is better to create two (or more) features + another one with just the presets. The idea is that you could turn off one of the two features without, in the example, losing the presets. In general, more smaller features is better than fewer bigger ones.
I was pretty tired and hungry by the end of the day, but I did manage to pick out some gold from the Debugging Drupal session:
- git bisect is a fantastic tool for tracking down where and how a specific bug was introduced.
- I was also introduced to some of the vagaries of
debug_backtrace(), and especially the wonders ofdsm(debug_backtrace()), which gives a very pretty breakdown of your execution path. - Specifically for debugging non-completing cron runs, inserting a call to watchdog() in module_invoke_all, just for hook_cron.
- You can use drush mycommand --debug | tee output.log to test drush commands and print the results simultaneously to the screen and to a log file
Commentaires
Actually, I said that we
Actually, I said that we should focus on nginx but that varnish still has its uses. Nginx is a fully-featured webserver while varnish is just a frontend cache, so they have different goals...
We are already using varnish, so there wasn't much more we can do with it at this point. :)
Noted
Noted, and the text is corrected.
Publier un nouveau commentaire