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.
One of the technologies that made a lasting impression on me, as a young programmer, was Microsoft OLE. To give my own applications the ability to embed documents created in other applications, and vice-versa, was mind-blowing!
I've been maintaining a growing amount of modules over the years. I am starting to document my observations, habits and challenges, in the hope they'd be useful to other Drupal coders.
I devote time and energy to the development of a module. Since I consider myself a software craftsman, each module is a creation of mine - an artifact to which I try to imbue functional and aesthetic values.
Now that Twitter 1.1 and Feeds are buddies, time to move to other data sources. Next up: Facebook. Using trusty Feeds and friends, I was able to ingest my own Facebook home feed. Here's how to replicate this:
For the impatient, attached is a feature that should get you set up quickly.
Update: This post now contains a feature that you can import in D7 to see the Twitter feed in action.
The new Twitter 1.1 API kicked in recently, which meant a new cycle of maintenance for anyone consuming their data programmatically. My own Feeds + Views demo site streams #drupal, using Feeds and complementary modules.
I created a bare-bones content filter to add musical notation to Drupal content, using the VexFlow / VexTab music engraving library. Here's a little sample, also showing my fork of the original library to handle basic Arabic musical notation (quarter tones and special scales):
Feel free to fiddle with the music snippet above.
Last week, I described a technique to query and display nodes in all available translations. This worked well enough, but a performance-minded reader pointed out that the query generated by Views (that includes N self-joins for N enabled languages) would not scale to a large number of nodes.
My usual approach when implementing new ideas is to ensure the logic works first, and only handle optimization when needed. It's a strategy that has worked well for me in the past.
Here's a little puzzle: display a table of nodes, each row containing the same content in all available translations.
How would you do it? Stumped, I asked that question on Stack Overflow a few years ago, but never received a satisfactory reply.
Then, a couple of days ago, someone asked me if I had solved it. I hadn't thought of that puzzle since then, but I would have felt bad answering no. So, with 3 years of i18n work under my belt, I decided to give it another go.