Developer tools

Drupal integration for DropzoneJS - an open source library that provides drag’n’drop file uploads with image prev

TBD

"Let thy menu be responsive!"

The Responsive Navigation module integrates the responsive-nav.js plugin into Drupal.

Alter forms via Context reaction.

A front-end, friendly alternative to writing form alters directly in custom module code, though you should use Features. Set various form values, attributes, and element access based on any Context condition available via core or contrib context plugins. This is useful for hidden field defaults, labels, or required status; but there are plenty of other reasons you might want contextual form alterations depending on the area of your site, user roles, etc. It's recommended that you save such things to Features so these configs are not being pulled from the database.

See the readme for some examples.

Just imagine these juicy tid bits...

1. Change button text in the login block based on content type of the page.
2. Preset a registration profile field (via formblock) based on an entity field value of the page.
3. Within advanced search options, force specific content type based on site section.

The aim of this module is to greatly reduce the load to the site's database by using "virtualized" fields instead of "real" FAPI fields.

"Virtualized fields" will be written in serialized manner to the database thus only consuming one single field data table and hereby greatly reducing the number of joins, subqueries and/or subsequent queries. In order to do so, this module provides a javascript-driven interface at the entity edit form. On the frontend, a field formatter will make sure all values are made accessible like they would if they came out of the database "the usual way".

Actual development state:
The data structure administration interface now should be likely ready-to-use. It may be the case that some additional settings will find their way into the interface, but this will not affect the functionality itself.

The entity edit forms are now populated with a proper interface for the field structure defined. Form validation of the fields as well as re-populating the form with previously entered data is already achieved and working. The data is properly stored to and retrieved from the database now! Yay!

There are already some working field types: plain text fields, text areas, node-, user- and term-reference fields are all functional and working!

This is an experiment for exploring possibilities to integrate the third party PHP mock object framework mockery into DrupalWebTestCase. The goal is to provide an easy to use API for testing drupal hooks invoked during DrupalWebTestCase::drupalGet in a stub module.