The last few weeks have seen an intense flurry of work on the Panels suite of modules. Today I've rolled releases of the Panels 3.7, CTools 1.7, Panels Everywhere 1.1 and a tiny bugfix release for Tinsel 1.1. This has created a massive chunk of new features that we're hoping will push Panels even more into the mainstream by seriously extending the power available to site builders, particularly in terms of giving site administrators better options for doing their jobs without having to worry about details they've taken care of.

First, I'd like to thank iO1 for sponsoring my time, and Chapter Three for sponsoring Sam's time for this work. This is just the the first round of a lot of great work that we have in mind, and we expect more great things to come out of this and after this.

Download links:

• CTools 1.7
• Panels 3.7
• Panels Everywhere 1.1
• Tinsel

(And now, on with the excited babbling!)

In Place Editing

The first, obvious feature is the new In Place Editor that Sam Boyer begin_of_the_skype_highlighting     end_of_the_skype_highlighting begin_of_the_skype_highlighting     end_of_the_skype_highlighting worked on and showed off at at Drupalcon San Francisco. Put simply, In Place Editing means that when you create a panel page or a panel node, you can select an option which allows privileged users to edit the panel content without going to a back-end UI! These users can click on a "Customize this page" link and a simplified drag and drop UI will put itself into place, allowing users to add, edit and remove content. More advanced options such as styling and caching will still need to be handled via the back-end UI.

In the future, this will continue to be extended, allowing for the possibility of multiple in place editors that have more or fewer features, and finer control of exactly who can access this.

Stylizer

The last release of Panels had the stylizer, which to be honest was released before I was ready due to the need to get a security release out and having no easy way to release just a security fix. (I am hopeful that drupal.org processes will change to allow this with the git migration).

The stylizer is more or less color.module on steroids, but allowing you to set up colored styles for panes or panel regions. It uses the concept of a "base style", of which Panels currently ships with two (and really, really, desperately I want more, there should be a good half dozen). These let you control foreground and background color, font and border information. It can do CSS manipulation as well as image processing.

As part of this release, the entire UI was moved completely to CTools. While at the moment only Panels currently implements stylizer styles, the move means that non-Panels systems can make use of the stylizer back end for whatever nefarious purposes they desire. This means skinr hopefully can eventually use it, or someone could write a style manager for blocks that overries theme('block') and lets non-Panels websites style their blocks more freely.

One note: There are planned future changes to the style base system, so anyone who wants to run off and create new style bases should talk to me! For one, I'd really love to just ship with more, so there's no need to create them in a module right now, and for two...I have not yet documented how to build styles.

Improved flexible layout

I've made some very serious improvements to the flexible layout:

• The actual HTML weight has been reduced somewhat. It still produces inner and outer divs for every region, but it will not produce left/middle/right divs when not needed, and it will not produce column/row wrappers when there is only one column or row, since these are not needed.
• The "Canvas settings" now contains a number of interesting items:
  • Canvas width -- can now be a fixed width.
  • General class -- does not need to be tied to the display ID (which could change due to exporting).
  • Column/region/row classes -- no longer needs to be panels-flexible-row but can be whatever you pick.
  • Column/region/row separation -- control how much padding is between columns and regions.
  • Disable the 100% -> 99% scaling for IE6. If you don't care about IE6 users this can be handy.
• Flexible layouts can now be saved for re-use, and managed in a separate interface. This means you can create the flexible layouts you need while developing panels and re-use them as necessary. Change the layout once and it changes everywhere.

Sadly, flexible still has issues in Garland because of a max-width on Garland's body class. The only fix, so far, is to increase that max width manually.

More things exportable

Amitaibu helped me develop a new generic Export UI framework, meaning that you can now create a fully functional list/edit/export/import/delete/clone user interface -- with searching, enabling and disabling -- in a relatively small amount of code. Doing so made it much easier to make more parts of the system exportable. I mentioned above that flexible layouts and stylizer styles can be exported, but you can also create and export custom rulesets and custom content. These are both very handy when you have complex rulesets or complex pieces of content you, as a site builder, wish to provide to a site (content) administrator without overwhelming them with all of the options Panels has.

Seriously improved views integration

We spent some time improving the Views integration. Panels should now support Views 3, which is nice.

But what's really cool is that there is now a "View context". What this means is that instead of simply putting a view in a single pane, you can load a view as a context. This is similar to loading a node as a context, where you can then display parts of the node in one region and parts in another. With a view context, you can display row #1 in the top region, and then rows 2, 4, 6, 8 in the left region and rows 3, 5, 7, 9 in the right region. You can put the pager in the bottom region, and put the header/footer where you think they should go as well.

But wait! There's more -- you can also control which fields get displayed. For example, in the above view, you could create two different 'body' fields in the view. One is trimmed to 2,000 characters, and the other is trimmed to 500. The first 3 rows could use the bigger body field, and the rest of the rows could use the smaller body field. You could do similar tricks using offset in the past, but this will run the view only once, reducing database load.

In addition, when creating view content panes (which I highly recommend as the only other way you should be getting your views into your panels), in the 'Allow settings' part of the display (in the Views UI) you can select that the pane config can control which fields to display, and you can also have it use the exposed form as pane configuration. If you do this, the exposed form will not actually be exposed to the user.

This is another feature that is targeted specifically at site builders wanting to give the right amount of flexibility to content administrators. You give them a set of fields they can choose from, and the right set of filters, and they can narrow it down when they add the widget to their panel.

Panels Everywhere

Panels Everywhere received one major boost in all of this. Panel pages can now directly select which Site Template to use. For those who haven't used Panels Everywhere, the general idea is that you use it to replace your block administration with a panel.

Traditionally, you have page.tpl.php with regions and use the clunky block UI to add blocks to regions, and then use block visibility rules to make blocks appear on a page.

With Panels Everywhere, you create a series of site templates -- these are layouts that contain all of the blocks, including a special "Page content" pane where the inner content of the page would be. You use selection rules to determine which site template to use. However, in complicated sites, the list of rules can get annoying. If you are using these templates to turn your site into sections, it can be convenient to simply say that a given panel page belongs to a given section and skip the rules entirely.

Under the hood -- changes that will interest developers

We made a lot of changes that are only of interest to developers, but I consider them exciting and wish to mention them here anyway.

Export UI

The new Export UI tool is a plugin with an OO based structure. You define the plugin which creates all of the normal menu items for you, and forwards all of these items to methods on the object. If you do nothing at all except create the plugin and tell it about your export.inc enabled schema, you will have a complete UI that can list, edit, export, delete, clone, enable and disable. Now, the edit won't do much because it does not know much about your object, so the first thing you'll need to do is create the edit form. The listing functions can be easily overridden.

When things get complicated, as they often do, the export.inc UI also supports the CTools multi-step wizard, meaning with only a little bit of effort you can use multi-step forms to edit your objects. The best thing I can suggest is to check out mini panels, which were retooled to use this UI. This saved about 400 lines of code in Mini Panels, plus added new features to the Mini Panels UI that only previously existed in the Page Manager UI.

This system is actually documented in the advanced help for CTools.

Plugins can have children

Content type plugins have always been able to have children, which is to say that one plugin can actually provide many. (For example, block.inc provides all of the blocks in your system, and view.inc provides all of the views in your system). However, the method it used to do that is clunky, and as the system has evolved it turned out to be easy to just add it to the core system. Now plugin types can declare that they support plugins having children, and then plugins that do only need to implement 'get child' and 'get children' callbacks. How to achieve this is documented in the advanced help, and looking at the custom access rulesets module is an excellent example on how a real plugin accomplishes this.

Super easy auto submitting forms

The Page Manager UI has always had this nifty auto-submit on the search bar, making it so you do not need to actually click the apply button to search. This got generalized into a tool. All that needs to be done is to ctools_include('auto-submit') and then apply the proper class to your form. CTools takes care of the rest.

export.inc got new magic so that exportables can use it.

In an effort to make sure export.inc integration is generally useful, we added a new piece of code that will let it get its keys and fields from joined tables. This effort was ultimately to allow exportables.module to integrate with it (and thus get the free integration with features.module this provides). This means that many core objects such as vocabularies and input filters will soon be freely exportable just like views.

export.inc got new magic for CRUD functions

Almost all exportables can be now interacted with via ctools_export_crud_* functions! Previously, developers adding export.inc integration to their objects needed to create their own library of CRUD functions. Now, however, all they need to do is utilize functions like ctools_export_crud_load('table', $key) and voila, their object will be loaded to their specifications. The 'export' section of the schema can provide callbacks, so even complicated multi-level nested objects can utilize these CRUD functions and reasonably expect to work.

CSS caching works with private filesystems

It is such a small thing, but it is worth mentioning that I did figure out how to get CSS caching to work with private filesystems. It has to go around drupal_add_css() so cached CSS on private filesystems cannot aggregate and may miss some other niceties, but it should now basically work.

AJAX Improvements

These actually went out mostly in CTools 1.6, and were another unfortunate consequence of the security release. The AJAX framework got an upgrade, allowing it to automatically transmit CSS and javascript files/settings during AJAX operations, dramatically opening up some of the possibilities during AJAX. Unfortunately, javascript aggregation (and some javascript extensions) were not completely compatible with this. And there may still be more issues with things like jquery updates but as near as I can tell, we've conquered most of them.

An appeal

I'd love it if some of the more enterprising users out there could make a 5 minute screencast (or two) of some of the new features. In particular, Stylizer, some of the new exportable stuff, and the new Views integration and the IPE will shine by being walked through quickly.