The Panels In-Place Editor was a fantastic piece of functionality added to the Panels library, funded by Chapter Three (thanks!!!) and implemented almost entirely by Sam Boyer. This feature allows users to designate Panels of various types as editable in-place. This means that users with privileges are given a button at the bottom of the page which allows them to dynamically add, remove and rearrange content on that page. It's much more limited than the typical back end editor, but is much more usable by content managers who are focusing highly on the content.

What most people don't know is that this feature actually went in incomplete. I've had grand plans to finish this, but it's a biggish project and I've simply never had the time to do it.

What I mean by incomplete is that the underlying framework of this feature actually involves a process internally known as a 'rendering pipeline' (or just 'pipeline'). This pipeline contains a number of rendering possibilities and it chooses one based on available information. If you've used Page Manager extensively, you've seen this before. It's called a Variant, and it lets you pick the page that's actually displayed based upon selection criteria. Typically this involves things like user access, or node type, or taxonomy term type, or other, less-used items such as user language.

In most places you can put a panel, if you have the Panels IPE module there is a radio selector that lets you pick the standard renderer, or the IPE renderer. In reality, both of these are pipeline selectors. The standard renderer always selects the standard renderer and therefore it's the simplest version. However, the IPE renderer actually has two possibilities. In code terms the flow of what this does looks something like this.

if (user_access('use panels ipe')) {
  else {

But the system is far more capable than that. Underneath, something that doesn't happen, but easily could is that we could add another pipeline. Let's call this, "Super IPE". Here is some total pseudocode:

if (user_has_role('administrator')) {
    return array(
'type' => 'ipe',
'options' => array(
'can change style' => TRUE,
'can unlock panes' => TRUE,
'can change layout' => TRUE,
'can add panes' => TRUE,
'can remove panes' => TRUE
  else if (
user_access('use panels ipe')) {
  else {

If the above existed, our radio could then offer three choices:

  • Super IPE
  • IPE
  • Standard

In other words, we can actually have different levels of IPE. Except for the part where we don't have a UI to actually set this up, and the IPE itself doesn't actually know how to interpret these options. You could add as many of them as you like and select the appropriate when to use when creating the panel. In theory we could probably do some kind of context selection as well, though that's not baked in there yet.

But that's the easy part!

What we don't have, still, is the UI to do this. The UI is a relatively complex thing to do. What I really want to do is to take the tabbed operation sets used in the Page Manager UI and abstract that, so I can make more complicated, multi-form, multi-wizard UIs just by plugging in what the operations will be and link them to forms. And theme the result, but apply a standard theme so that we can still do the basics without getting too fussed about that.

Then we need to build the UI for pipelines. Pipelines are already exportable objects, so we simply need to attach the Export UI, build the variant selection mechanism. Then we need to modify Panels IPE to actually have an options form and support the options. I need to figure out what actually should be optional and use a good system for setting defaults. There's a lot of really interesting potential options here.

  • Available layouts.
  • Available content.
  • Possibly different content selectors.
  • Theming keywords, kind of like how Views has alternate templates just for a particular view.
  • Pane locking -- have some panes "locked" and not movable without increased permissions.

There's probably more I haven't thought of. Some of these features exist now, some of them would take some implementation.

In addition, once in place, we could also create pipelines for the backend system as well. It uses the same essential mechanism. It would then be possible for site builders to customize the editing experience very granularly.

This isn't a small project, but it's an exciting one, and would make a great expansion to the already existing functionality. Both Sam Boyer and I would love to get funding so we can take this system to the next step. Some projects I'm on will already have me working on parts of this. Being able to do even more would be a big win for everyone!

I'm still working on the best way to fund this. I'm thinking about kickstarter, or just taking pledges and billing people through my company, or what. Both have their ups and downs. Who has good ideas on that front?


That sounds awesome. I would definitely contribute to your work by funding it through kickstarter or something similar.

Nice, I'm in.

Some thought:
- People don't really have mental image about the funding amount needed, but always like to have all the functions. So making somekind of sponsor / contribute suggestion, e.g. kickstarter, would help. I read research somewhere about this. People who willing to support, won't do $1 contribute if they know you need 500 contributor average of $20 ;) (and frankly ... it's Panel, $1 don't make anyone feel proud much)
- This look interesting. Somekind of this would be easy to understand.

Yeah, I haven't worked out how much funding I think it needs right now yet. Want to talk to Sam about it and get his opinion but of course it's Drupalcon right now, so he's not available. :)

Hi Earl!

At DrupalCon Chicago a whole bunch of people tried to start planning a better infrastructure for coordinating community initiatives, including with funding. Barry Madore of Advantage Labs is at DrupalCon London one of those continuing the work.

The idea is to be Kickstarter-like but better adapted for Free Software and interested parties finding each other over time, allowing more flexibility with revisions to the amounts needed and the deliverables planned, and potentially more integrated with other community resources in terms of credit for supporting.

I think Kickstarter would work for you in this case but i'd be honored if you would be one of the pilot projects of this initiative, which would accept tax-deductible donations directed to open source development. A lot of details have to be worked out but the


benjamin, agaric

This functionality is based on the work I did for the Payment API (which is itself a good candidate for crowd sourced funding!). It's more than a what-if, there's working code already in use. I think that making a funding model like this available to Drupal developers would be a huge win. I know very well how hard it is to make the headspace to do biggish projects while still making ends meet, and I would really like to see good developers doing important work without having to depend on the largesse of an employer or client.

The big questions on an initiative like this surround governance and overall organization, but honestly, having a project that generates resources for someone as well known as yourself would be a huge benefit for a by-Drupal-for-Drupal crowdsourcing effort.

Thanks, this functionality will help us for our next project.

Add new comment