In part 1 of this series, I introduced the workflow we use for managing i18n-friendly configuration using Features.
oEmbed is a simple and popular protocol for embedding external media in web pages. It supports many types of content, including images, videos, and even "rich" content (i.e., HTML snippets). Unfortunately, the current Facebook embed mechanism does not work so well when the embed code is loaded dynamically on a page, e.g.
Last week, I started writing about my tribulations managing the configuration of a multisite, multilingual application using Features, i18n, and friends. I listed the site components that needed to be managed, and described the basics of saving string translations in a feature.
This week, I'll describe a particularly challenging component I had to deal with: inoffensive-sounding menu items. Should be easy, right?
In my role as development team leader, I am responsible for the application architecture that allows other team members to focus on building functionality with minimum friction and rework. As such, one of my biggest tasks is to ensure that new features and configurations can be reliably deployed to the various stages: development, testing and production.
My current project is an Arabic/English application built on Drupal 7, that is deployed in multisite fashion to several partners.
I wrote last time about the latest developments to my Views Auto-Refresh module, which periodically refreshes a Views page, either by reloading the whole view, or by incrementally inserting new items only. It's a useful tool for activity streams and other Twitter-like, real-time lists.
Still, I had a nagging feeling that my code was endangering the server. Consider this: every 15 seconds, each connected browser invokes a full Drupal bootstrap plus a full View render, just to ask the server if there are new items.
Imagine you are creating an activity stream for your site. You'd like to use Views because it gives you all the power you need to query items and style them on the page - all in time for your 11am nap. However, the resulting page is static and users have to keep refreshing it manually to see updates. In 2011, that's just uncool.
That's why I created Views Auto-Refresh, a Views Hacks sub-module that implements an auto-refreshing mechanism that integrates right into Views 2 or 3.