Using panels on view modes in Drupal 7

Ever since Display Suite came out, people always thought it was a competitor for Panels, which really isn't the case. I'm not going into that debate, both me and merlinofchaos know the facts. I've got better news instead. Apart from the fact that Panel layouts are already available through the Field UI, the Panel editor can now be used as well. That's right, if you are a Panels/Page manager user, you can now use that interface to manage the layout of any view mode of any entity in your Drupal 7 installation. Drupal display managemement just got slick!

The code is available in the 7.x-1.x version of Display suite as a submodule called Panel view modes. This is a call for testers to play around with the initial implementation to make sure this works well. Post features, bugs into the issue queue. Make sure you have the latest dev versions installed of CTools, Panels and Display Suite and post as much debug information and/or steps to reproduce for any problem you might find.

In the meantime, you can drool over the screencast, the real magic starts around 1:35 :)

Using ctools content as a field with Display Suite in Field UI

Display Suite has the ability to create custom fields, either through code or via the UI. Those fields can hold custom content or even PHP code. It is somewhat limited since one field can only have one type of content, unless your field has some crazy PHP code which is not easy to maintain. Those days are over now. You want to add custom content, a node, the logo or any other type on the Field UI screens? The upcoming release - 7.x-1.2 - comes with a new field called ctools field, which can hold any sort of content that is available through ctools' plugin system and which is configurable on the "Manage display" screens per entity, bundle and view mode. Think as of Panels, but in Field UI. And they are of course all exportable. This may all sound a bit cryptic to you, so I've recorded a screencast showing you how this works. Be amazed and watch out for the upcoming release of Display Suite somewhere next week!

Configuring fields with Display Suite for Drupal 7

The 7.x-1.1 release of Display Suite comes with a couple of new exciting features:

  • Fivestar
  • More hooks and better views extendibility
  • Ability to hide the page title on full node view
  • Custom field templates via the UI

The last feature is better known as the cure for divitis feature for the field system. Or you can also call it semantic fields. The possibilities to theme entities through the Field UI have now become endless. I'll explain those changes with code and screenshots, which should convince you how powerfull and easy Display Suite can be for your website. And best of all, this is all exportable!

Fun with entities and Field UI: Views displays

Drupal 7 introduced entities. It's such a great concept, I'm able to easily port Views displays - part of Display suite - to Drupal 7. It is now part of the main package, bundled in a sub module called Display suite Extras, which also includes the 'region to block' and 'switch view mode on a per node basis' features. More goodies, less code, even more power. But back to Views, entities and overriding templates.

For those who don't know exactly what I'm talking about, a quick summary. In the Drupal 6 version of Views displays, you're able to select a single display of a view and rearrange the template variables so you don't have to override the views-view.tpl.php template file. It uses the drag and drop screen that Display suite comes with, but for D7 we decided to use the manage display screens that Field UI provides. This is great because it supports all entities, so any entity that is fieldable use the same forms in which we simply inject our extra regions. However, Views is not an entity, but in comes hook_entity_info to the rescue!

Drupal 8: an agile proposal

Drupal 7 is out. Even before the release, the community already started thinking what should happen for Drupal 8, we're just too excited to keep on working! Keeping track of which bugs, tasks and feature requests should be developed is gathered from a lot of sources and eventually - not always - created as an issue in the Drupal Core issue queue, and by looking at the size, we already have a lot of work, which are mostly still tasks/bugs/follow ups which didn't make it to Drupal 7.

New features will obviously come up: proposals and discussions are found on blogs, groups.d.o and Community initiatives. Brainstorm sessions happen at Drupalcons, IRC, local gatherings of Drupal enthousiasts or even surveys. Tracking all this activity and the current work is really hard, probably nearly impossible for every single person on this planet. Also, issues marked as critical give a false sense to me sometimes since the spectrum of things to fix is simply to wide and not focused on making sure a single piece of code is 100% A-OK. You can bookmark several URL's which lists issues based on tags (performance, theme, favorite-of-dries ..), components (node module, etc), priorities (major, critical) and so on. Simply too much to handle for one person.

Topics 

drupal, planet, agile, kanban

Pages

Subscribe to realize.be RSS