drupal

Overriding the Facet API breadcrumbs

Facet API for Drupal is an amazing module that enables you to easily create and manage faceted search interfaces. The UI is fantastic and easy and it works perfectly together with either Search API or Apache Solr. It also changes the breadcrumb as soon as you start filtering further, which in many (probably most) occasions, is a nice default behavior. But not every project wants these kind of breadcrumbs. In a project we tried first to override the breadcrumb with hook_breadcrumb_alter(), but as we have a lot of search pages, the code was getting ridiculously ugly.

So we looked at where exactly Facet API is changing the breadcrumbs. This happens in a method called setBreadcrumb in a url processor class. So, we need to create our own processor and override the default behavior. First of all, we need to let Facet API know we have our own url processor:

<?php
/**
* Implements hook_facetapi_url_processors().
*/
function yourmodule_facetapi_url_processors() {
  return array(
   
'standard' => array(
     
'handler' => array(
       
'label' => t('Your module URL processor'),
       
'class' => 'FacetApiYourClass',
      ),
    ),
  );
}
?>

We are doing something wrong here: the standard key is also used in facetapi_facetapi_url_processors(), so we should use another name, because we are now overriding the default class. The trick is to extend on that class so the other methods will still do the heavy lifting. Oh module_invoke_all, we sometimes love your merge behavior (although technically here it's a CTools plugin, but the result is the same for both).

<?php
class FacetApiYourClass extends FacetapiUrlProcessorStandard {
  public function
setBreadcrumb() {
   
// Keep default behavior.
 
}
}
?>

If this class is not defined in your .module, make sure you add it to the .info file so the registry picks it up.

That's it. Again, this post should probably also be tagged with 'You're doing it wrong', but it works perfectly for our current use case.

Exporting, reverting, disabling and enabling any exportable with ctools and drush

With the newest release of ctools, a new command was made available for drush to export all objects to code with one simple command to a module. Instead of having to copy and paste all code via the bulk export module to your custom module, a simple drush command now saves you a lot of time. But it doesn't stop there. Damian 'damiankloip' Lee started a sandbox to add more powerful funtionality and this has now been merged in the 7.x branch which will be available in the (soon) next release of ctools. An initial patch to select the exportables by hand has also been committed, but could need some more love on the UX side. Apart from that, the goodies that are in already, should make any developer extremely happy and opens up new possibilities in so many ways. So what commands can you use now and what do they do ?

  • drush ctools-export-disable: disable one or more exportables
  • drush ctools-export-enable: enable one or more exportables
  • drush ctools-export-revert: revert one or more exportables
  • drush ctools-export-info: get an overview of all possible exportables
  • drush ctools-export-view: view one or more exportables
  • drush ctools-export: export all exportables to a module

Excited yet ? We are, so we made a screencast, we're pretty sure you'll love it. Damian and I are planning more things for the future, so anyone who wants to help can post issues to the sandbox. Once they're done, we can commit these easily now Damian has access. Let's make ctools drush extremely powerful!

Topics 

drupal, ctools, export, planet

Posting images from Android to Drupal

I've blogged about this topic almost more than 3 years ago how I used a couple of drupal modules to send mails with images from my iPhone which automatically got posted to my site. But times change. I now own a Nexus One and one of my goals for 2012 is to write at least one decent mobile application. I experimented with Titanium first, but decided to go native for a couple of reasons, performance and size of app being the main reasons.

While I already have an official go for an application I can develop, I started with a simple use case to learn android application development: uploading images to my personal blog saving a new node. Especially the java part is as good as new to me, so starting simple is always the best advice. After 3 hours of Drupal hacking and a lot more Java reading and debugging, my first application is happily working on my own phone and I have cute Druplicon on my desktop.

The code is freely available (see below) consisting of 2 parts.

The Android part

The application is build at SDK version 10, so it should work on any Android 2.3 or higher. It might possibly work on lower versions as well. After installation of the application and the first run on your telephone, you will need to login. The app authenticates with a Drupal user and only stores the endpoint URL and the session cookie. The session cookie is send when uploading an image so we know exactly who's uploading. Besides selecting from the app, you can also go to your Image gallery, select an image and use the Share menu to drop the image to the application.

The layout of the application as the code is relatively simple, it probably doesn't follow the best practices of Java programming, so be gentle in case you start reviewing, I'm still learning :)

The Drupal part

The Drupal module - D7 only - is simple as well, but was less hard to develop. While I could 've used a combination of services and other modules, I decided to write a simple module with a single menu callback that accepts a request that can either authenticate a user or create a node with title, image and other keys. Once enabled, you need to go to 'admin/config/media/drupapp' and start configure following items:

  • The endpoint. Defaults to 'drupapp', but you can change this to your likings.
  • The image field name: this will immediately select the content type that will be used to save the node.
  • Published status: default status, handy if you want to review after upload.
  • Debug option: log the complete $_POST variable through watchdog for testing purposes.

You will need to grant permission on the permissions page as well. Best practice is to create a new role which only has the "upload images via app" permission, and that role does not necessarily need a permission to create nodes.

Combine the 2 technologies and you get Drupoid. What's in name right ? You can browse, fork and/or download the code at http://github.com/swentel/Drupoid. Feel free to modify it to your own needs. The app in its current version will never be made available on the Android market as it's really a personal project. But it might serve as a nice start example for your own adventures in mobile application land.

You can also see some pictures from the screens at http://realize.be/mobile or an installation guide at http://www.slideshare.net/yoroy/drupoid.

Overriding any Drupal path with Page manager in a few clicks

By default it's not possible to override existing paths with Page manager, the excellent module that is bundled in the CTools project. The Page manager existing pages module now allows you to do that. Technically, this module defines one abstract task and one content type plugin, so menu items can be overridden and the original page callback can be called through the content type plugin. This project comes with one default existing page, which is 'node', the default Drupal frontpage.

Basically, you are now able to override any Drupal path in your installation and create variants for it. The module comes with one default existing page (although new ones might be added in future). Default contexts for entities is possible as well. I've created a screencast so you can see the module in action at http://www.youtube.com/watch?v=W-4g01WjwI4.

Daniel "dereine" Wehner has written a blog post about it at http://blog.erdfisch.de/2012/01/override-all-existing-pages-panels with some excellent screenshots!

Managing any form with Renderable elements, Field group and Display suite

Little than a week ago, I committed Renderable elements which enables you to register any piece of build in your Drupal 7 installation and manage that through Field UI. It will make additional fields available of existing entities on the manage forms/display screens or you can for example register the contact form, webform or (let's go crazy) the exposed filter form of a view and rearrange the fields with Field UI. Essentialy, the idea is that you can rip out all elements which are nested, also those inside the vertical tab on the node edit form for instance.

How it works

Currently, only forms are supported, support for any kind of other non entity display is coming soon. Once you enable the module, you can go to admin/config/system/rel/config and enable the registration link on top of forms. Now go to any form in your installation and you'll see a 'Manage form display' link on top. Clicking on the link will make the form available to manage. An overview can be found at admin/config/system/rel. In case you're registering a non entity form, this build will be inserted as a bundle into a new entity that's exposed by the module. This way, we can profit from hook_field_extra_fields to register any kind of element. Tricky ? Sure. Cool, oh yeah!

Any kind of custom registration is exportable thanks to CTools as well.

The power

The idea from the module came after the initial proof of concepts while working on forms support for Display suite. Soon after, an issue appeared as well in the Field group issue queue to make field groups available in other contexts than entities and the ability to rip out the elements that are nested inside vertical tabs. Of course, anything can be done with form alter, but our goal was to make this possible through Field UI. Now, we don't want to force people Field group and/or DS, so we decided to create a separate project, which also means there are no dependencies. If offers a lot benefits and the possibilities you have now are huge:

  1. Install this as a stand alone module and it will make any element on the form available like the Save/Preview/Delete button, vertical tabs etc.
  2. Install Field group and you can take control of existing field groups or add new ones on say the contact form.
  3. Install Display suite and you can now select a template file to manage the layout of registered forms, like webform etc.

Both modules (rel and ds_forms) still need cleanup, but also a lot of testing, so please test as much edge cases as you can and report back into the issue queue!

This might all seem a bit cryptic, so, we've recorded a screencast showing you the power of Renderable elements together with Field group and Display suite on node, contact, webform and views exposed filter forms.

Pages

Subscribe to RSS - drupal

You are here