Can I hook into the output of the panels_editor_renderer plugin?

Thanks for your reply. Subclassing seems like an interesting approach, but I guess it would mean monitoring and testing panels updates very closely. My use case is derived from a small content type plugin that acts as a modifier to the rendering of panes beneath it (all it really does is adding classes based on its settings). I'm thinking about the effort to enable the backend to visually represent the effects of the modifiers on the edit page. I figured out two degrees of adaptions (added as a concept sketch to the ticket under 2 and 3). The first one (modifying the markup of the editor containers) would only bring small benefits. I'm not sure if this bares any relation to interfere with as deep as the render layer of the panels editor interface. The second one would definitely yield a great deal of usability; but I guess there are quite a lot of things that could go wrong and maintenance could become a burden.

I'll dig into hook_ctools_plugin_post_alter() and look at the code of the panels standard renderer as well as contrib modules that provide their own display render plugins.

Okay, just a little brainstorming... If I get it right the markup for the panels editor main wrapper is assembled in the render() method of the panels_editor_renderer class. When I dump $this I see that we know a lot about the regions and their region styles at this point. In terms of architecture, would it be a problem if during the bootstrap there was a possibility to hook into the phase when all information that is known at the render() stage is available (but before render() does it's job)?

This hook enables module developers to check the styles for each region. If a region or panel style matches something intended by the module developer (in this case the region has the style grid_container) the module developer could access the Drupal.settings object and register alternative behavior for the JS rendering of that particular region's panel-portlet logic (display_editor.js?). Maybe a mixin or just a callback that is triggered right after the default panels editor has done it's work.

That way a content type plugin that implements that hook could also alter behavior in the backend. When I think about my use case there is no need for an additional data model – if there was a way to make the adapted sorting logic communicate new pane order to the already existing panels logic.

-----

When you were thinking about the container layer – have you had an idea where to put it (in terms of configuartion/workflow)? Should this be something that is added over the panels editor interface, like »click region gear > add content > containers > container« or at the same level as regions and layouts are defined? (Although the latter sounds a bit inflexible)

-----

Short update: haven't had the time to dive into this so far. I hope for the weekend to come to try some of the hints given so far.