drupal

So you want to build a module that provides some fields and instances for an entity type. Let's start with a quick summary to get in context.

As you should know, fields in drupal are thingies that exist on its own, though they're useless if not attached to entities. Fields are tied to entities through instances. So to attach a field to a node or any other type of entity, it's needed to create instances. In this way, an instance is identified by the field name it instantiates and the entity type - bundle tuple it is tied to.

In Drupal's admin UI, creating fields and instances is overlapped: when you create a field, you're also creating an instance. On the other hand, when you're reusing an existing field, you're just creating a new instance of it.

Last but not least, part of the configuration you can see in the UI pertains to the field definition, and part to the field instance. So field configuration is the same for all of its instances, and instance configuration is specific and not shared by other instances.

Estoy desarrollando una distribución Drupal. Ahora mismo ando exportando grupos de configuración a features y me encuentro con un problema que he afrontado ya varias veces sin haber encontrado (hasta ahora) una solución satisfactoria.

Uso el módulo context para gestionar la disposición de los bloques. En algunos bloques necesito que el título no se muestre, y context no proporciona una manera de hacer esto (panels si), por lo que recurro a la interfaz administrativa de bloques y neutralizo el título poniendo <none>. Quizás haya maneras de hacerlo con algún módulo que extienda context, pero por lo que he buscado y preguntado no existe otra opción.

El problema con el que me encuentro es que al exportar la configuración de context a código, el override del título del bloque no se exporta....

Some months back I was in the need to know if a Drupal site was hacked how much code had been modified in a given Drupal site. It was not straightforward to install a copy of the site out of the box (it had hardcoded absolute paths in custom modules among other annoying things).

Hay varias maneras de gestionar las actualizaciones menores de drupal (de la versión 6.1 a la 6.2, ...). El flujo canónico sería[1]:

Notición: se acaba de resolver Install profiles should be modules with full access to the Drupal API and all it entails(.install files, dependencies, update_x).

Esto facilita muchísimo el escribir perfiles de instalación e incrementa enormemente su utilidad.

La extensión readline para php no está en Debian (ni en Ubuntu) por problemas de licencia. Entre tantos bugreports, blogposts y opiniones varias he encontrado esta frase: «Licensing issues. Readline is GPL, and we can't link with GPL libraries without violating their license.»

ACTUALIZACIÓN: hace unas semanas que estos comandos han pasado a formar parte del core de drush. Han entrado junto a una reorganización de los comandos "pm" (package-manager) que hasta entonces sólo gestionaban módulos. Esta es la equivalencia entre los antiguos comandos "theme" y los nuevos cambios introducidos en drush 3.x:

La aparición de drush 2.0 ha sido un subidón. Muchos estamos que lo flipamos con drush y reorientamos nuestra forma de trabajar con drupal para irnos a la línea de comandos para hacer lo que drush nos permita más rápido, mucho más rápido: descargar módulos, habilitarlos, limpiar la caché, darle al cron, crear nuevas instancias de drupal, etc etc.

Como muchas saben, Druplicon es el bot que está en varios de los canales de Drupal en el IRC de Freenode. Como era de imaginar, el bot es un módulo de drupal. Se lo curra Morbus Iff, que tiene un sitio web que me gusta bastante.