This project is a Drush plugin that can generate inheritance and interface implementation graphs from a directory of PHP files and its subdirectories, including a Drupal installation.
It does not load code from the current Drupal / Drush installation but uses the Grammar Parser on top of PHP built-in tokenizer to parse the set of files.
Note: Do NOT use. Everything in this sandbox was contributed to the Pre project
A collection of tools to increase frontend performance on a Drupal site.
The OData Server module exposes entities, like nodes and users, through the OData Producer Library for PHP. Properties and core fields are supported, and the module can be configured to limit the bundles, properties, and fields that are exposed through the server. Hooks are provided for developers to add support for their custom field modules. Most of the read-only conventions of the OData specification are supported.
Sponsored by R2integrated.
Note: As of 15-01-2014, this module appears to no longer be supported. If you are interested in taking this module over, please reply to the issue.
Xtools helps developing and testing other modules. It offers several dynamic code analysis tools:
Drush is a very nice framework for building CLI tools. But it's not a proper ecosystem until it has a todo app.
@Todo is intended to provide developers and administrators with a lightweight task-recording tool that can replace burying @todos in your code. Those can sometimes be useful to inform others of future intent, but are a pain to actually track your own actions.
With new or tiny projects, I often find myself putting high-level notes in an issue tracker somewhere but jotting down more detailed action items in a hard to manage scratch space... @Todo provides cleaner structure and is easily there for me on the command-line when I want to drop a quick thought into the queue.
Again, it is not intended to compete with a real issue tracker. Feature requests oriented at making @Todo scale to more users or more issues will likely be rejected.
Warning : This module abuses EntityFieldQuery to return data from your database. It does not work with entities or any modules that build on them.
This module provides a no-hassle means to remove the most visible instances of the Druplicon from a site, replacing them with a less intrusive alternative. The goal is to reduce the amount of boilerplate configuration (or theming) sitebuilders must do at the beginning of a project to make it presentable to clients.
As of Drupal 7, the Field API and the Entity concepts open up a world of possibilities for detailed, bespoke cms design.
Almost all the "atomic" components are now implemented as Fieldable EntityTypes:
This is a small module to help developers create and destroy custom menu's. It fills a small gap in Drupal 6.
The functions menu_save and menu_load are available in Drupal 7 for this purpose.
There are currently only three functions available:
this is an attempt to merge Fserver and Appserver into a more convenient package. probably an app available on my appserver pointing here...
Thanks to Eugen Mayer, who forced the progress of Features server (fserver),
