It felt like a Monday morning. After my alarm clock didn’t get off (+ 1 hour), I noticed there was only a train 1 hour later, so instead of arriving at half past 9, I arrived at 11 and missed the first speaker.
Lightswith + Drupal
Anyhow. I picked up the last quarter of using Drupal together with Lightswitch (= Visual Studio). Apparently not a lot of devs had interest in the subject because there were only 20 people in the room. And those who didn’t attend were right, because all the speaker could tell us was that marrying Drupal and Lightswith could only result in a divorce.
Lightswitch can create a HTML5-admin environment based on a data layer. That data layer could be your Drupal database. Nothing works out the box for Drupal because MS of course wants to integrate their software (SharePoint, Office) and not someone else’s software.
Another downsides of all these MS-Drag-And-Drop-Automatic-Data-Layer-Builder-stuff, is that when you change your database, something on the other side might break and you could end up writing the data layer yourself (as a attendee commented). Plus, the actual html output looks weak and is unusable in a serious professional environment. Don’t try this at work, pro’s!
Drupal 8 discussion panel
Three Belgian core-devs (swentel, Wim Leers, aspilicious) had a one hour Q&A hour about Drupal 8. They all had a lot to tell so the number of actual public questions was limited.
You had to know some Drupal 8 in forehand, because new projects (say WSCCI, PSR or TWIG) were discussed without being explained.
The main message was that Drupal 8 is ready to port your modules to. But, there’s still a lot of work to be done. There are still upcoming API-changes, you can’t translate a node’s title yet and there are various other big and small release blockers. But: Views should be finished. Ah!
And why Drupal 8 should be better that its processors:
- PSR proof. PSR is a PHP coding standard. (aimed for PSR 4 however, it’s uncertain if it the project will get there)
- Display Suite is now a core module (however, is this really such a big plus?)
- Getting rid of the hooks in favor for a more object oriented way (however, hooks still exist)
- Configuration Management (This is actually a big plus, more about this topic further in this blog)
- TWIG as a template manager. (to no-one’s surprise this is also the template engine of Symfony2)
- As for mobile:
- Out of the box responsive theme
- Responsive images with a “picture-element”, this is not finished yet.
- Responsive toolbar
- No javascript loaded for mobile.
- WSCCI (= the routing system of Symfony2). Yes yes, ladies and gentlemen, A Routing System like MVC.
- Validation is now “separate” to allow in-site editing validation. This “enforces better structured code”.
All in all it looks – a lot – better than Drupal 6/7, but there’s still this small topic which makes Drupal 8 really bad (what’s it again?), oh yes, PERFORMANCE. Because performance will only be taken care of after all the other stuff is done. Currently, Drupal 8 is a snail.
Backdrop
The speakers also criticized Backdrop, the first official Drupal fork which was announced only a couple of days ago. While Drupal 8 will lay its focus more on professional devs, Backdrop “will lower its barrier to entry, increase performance, and position itself closer to the market of WordPress users” and “[Backdrop] will appeal to new adopters who may find Drupal 8 too complex”.
According to the speakers, Backdrop is firstly an “experiment”, they will go “back to the hooks” (however D8 also has hooks), “the timing is weird” (referencing to the release of D8) and there is no Drush support.
Varnishing Q-Music
Bernard from OpenMinds gave an interesting (but fast and stuffed) presentation about how they got the performance right of the popular (but terrible) Belgian radiostation Qmusic.
The novelty about Q-Music is the automatically loaded playlist; everytime the dj plays a new song, all the site visitors can see the new song’s cover image without refreshing the website. On peeks, the site got 10.000’s active visitors, so this means a regular server would be down within seconds. Plus, every user can have his own profile page and his own menu that’s displayed on every page. Plus, it’s in Drupal 7.
I won’t go into detail about all the hardware cause I’m more a software kinda guy. The two basic software modules you need are Memcached (to store cachable data in the RAM and access it through PHP) and Varnish (store entire pages in the RAM and place it before the webserver).
But I collected some general rules you should take in account on big sites:
- Avoid (too) much calls to Memcached, so:
- Don’t use Memcache for small data
- Cache whole blocks (or even pages)
- Cache no data you’ll never need again
- Let Drupal define a TTL (time to life) instead of configuring all the TTL-exceptions in the Varnish config file.
- Take care of 404’s, because 404’s takes much PHP-resources and are not cached by Varnish.
- Collect metrics, measure everything you can (amount of queries, php memory, varnish calls etc)
- Devs should work more together with ops for performance reasons.
- Avoid external data from Facebook, Google or Twitter. He advised to pull the external data with cron and to store it in Memcache.
Varnish ESI
Another interesting package is Varnish ESI (Edge Side Includes). ESI allows you to cache an entire page with Varnish except a certain block (or menu) on the page. Only that uncached (personal) block will be requested to the webserver (and eventually to Drupal). And even that result can be cached again.
In the Qmusic example, the personal menu that appears on every page is separately cached.
The speaker warned us to take extra good care when configuring this. Because if things go wrong you can expect anything on the website: a user could get the personal menu of someone else, even the menu of the administrator. So it’s a potential security risk if you don’t pay attention.
End of part 1. Part 2 coming soon.
