planet drupal

As a followup on A pinch of Symfony for D8MI? why do we need to squash?

After some more squash and push -f attempts regarding pull request for Symfony I get the hang of it.

But chx said in squash is bad as we loose history on the development process.

So how should we do this on d.o when git phase 3 lands? Those discussion seems to got to a halt.

We all know Drupal and Symfony do have multilingual support (i18n, l10n, pluralization). But do they match? Or do they equally well? How does one test this? This is what I did.

I wanted to add tests for Symfonfy's PluralizationRules as there were none and I wanted to have support for PluralForms loading Drupals *.po files clean and simple. How hard can it be?!?

These tests should cover:

While still working on D8MI Let Symfony Translation component handle language messages I needed to code for Symfony to on the Translation component.

So how does that work writing and testing Symfony code?

One of the goals of Drupal 8 Multilingual Inititive is to refactor Gettext file handling by a component. The first effort was Make gettext .po generation its own abstracted functionality by Gábor Hojtsy, Sutharsan, fubhy, sun and clemens.tolboom

While I (clemens.tolboom) was working on that issue I skimmed over the Translation component delivered by Symfony to see whether we could match their architecture (why reinvent components?) or even take over their components.

Can you tell the field display weights of all your entities with one command? Or edit a node through the command-line?

Watch the video on http://www.youtube.com/watch?v=cVGZzWjdDh8 and get convinced you want to know more of these entity internals.

Following along the git migration and project cannot be grepped anymore I brewed the following code.

It assumes the gits are already cloned and placed is one common directory.

After running the script all repositories with a $major == 7 branch are set into the highest version.

I'm puzzling how to 'empty' the non $major compatible repos.

The fun part is now doing analysis on the tree

which shows some new dependency types

Sooo ... I've finally upgraded my own site. I thought it would be easy. A simple drupal site only using images. And yes I'm not reading READMEs that often. I trust drush somehow to handle this for me. But drush only sooth the 'pain'.

This blog contains my bash script which does some staging from production onto my laptop where I update the site to the latest D6 then upgrade to D7. The script is generic enough to adapt for other upgrades.

On http://drupal.org/node/686938 people are reporting a lot sloppy reports of error lines. The issue is about

But what are the names of the failing indexes?

jQuery has a nice grep so lets use it.

Make sure you have your drush aliases file setup properly. Below a snippet from my b2b.aliases.drushrc.php

Now we can run