This issue is to discuss a couple policy questions about Panopoly 2.x for Drupal 8, and also to plan out the goals and objectives to get us to the first 2.0 stable release!

@populist and @dsnopek discussed this and came up with the following proposal! However, this is open for discussion and change.

What will be included in Panopoly 2.0?

We decided that we won't aim for 100% feature parity with 1.0 in order to release 2.0 (but eventual feature parity in later releases will definitely be a goal!), instead the key feature to have working in the in-place page editing, which means:

  1. Panels IPE: Being able to click "Customize this page" and "Change layout" and open the IPE like in Drupal 7
  2. Creating new blocks in the IPE: In Drupal 7, this was done by Fieldable Panels Panes. In Drupal 8, custom blocks are already fieldable entities - we just need to be able to create new instances of them from the IPE!
  3. Panelizer: To take over rendering of nodes, provide defaults for the content type and make per-node customizations
  4. Radix Layouts: Our library of layouts, which is actually already ported to Drupal 8! See Radix Layouts 8.x-3.0-rc1.
  5. Panopoly Widgets: Excluding all the widgets that depend on external dependencies which don't have Drupal 8 ports yet (like the Map and Table widget)
  6. Migrations for the stuff that exists - Some migration classes for moving a site from Panopoly 1.x to Panopoly 2.x. However, since there won't be 100% feature parity immediately, this will only be for the stuff that exists. If you're migrating a site, you'll need to wait until everything you need exists in Drupal 8! See: #2736629: Implement basics of panopoly_migrate for migrating from Panopoly 1.x to 2.x
  7. Panopoly Demo: We can't release a Panopoly 2.0 that doesn't have demo data! See: #2732417: Port Panopoly Demo to Drupal 8!

Of course, we'll port some of the basics that exist in core, like the image styles in Panopoly Images, content types in Panopoly Pages, maybe a default WYSIWYG configuration in Panopoly WYSIWYG, etc.

But anything beyond the bullet points above is optional, and can wait until after 2.0. Patches are always welcome! :-)

As the Drupal 8 eco-system comes together, we'll continue adding more missing features after 2.0 (in 2.1, 2.2, etc), and will eventually reach 100% feature parity with Panopoly 1.x.

We believe that this approach will allow us to provide a Drupal 8 version quickly, so that contributors can start using it and improving it, while allowing us to maintain the level of stability and security that you have come to expect from Panopoly.

What will -alphaX, -betaX and -rcX mean?


The -alpha cycle will be about experimenting and laying the groundwork for Panopoly 2.0!

These versions are meant for contributors who want to help make Panopoly 2.0 a reality, and shouldn't be used on production websites.

The -alpha releases will be missing features and there won't be an -alpha to -alpha upgrade path.


We'll switch to -beta when we have all the features mentioned above that we're targeting for Panopoly 2.0 (see the list above), and we're ready to start providing -beta to -beta upgrades.

These versions are meant for early adopters who are OK with bugs, and don't need to migrate from Panopoly 1.x.

At this point, you could start using it for new Drupal 8 sites!


When we have the bugs to an acceptable level and migration classes for upgrading from Panopoly 1.x (if you don't need any of the missing features), we'll start making -rc releases.

These versions are meant for regular site builders and developers to try out Panopoly, not just early adopters, so we can iron out any critical problems before the 2.0 release.

Once we're reasonable happy that we have a stable -rc release, we'll release 2.0 (which will hopefully be nearly identical to the last -rc).

Specific changes/goals for the 2.0 release

The first Panopoly release was made in March of 2012. At the time, it was really the first "base distribution" ever made! A lot of decisions were made without knowing exactly what the consequences would be.

However, in the 3 years since then, we've learned a TON from the experience of users and contributors using Panopoly to do some amazing things, many of which would never have occurred to us in the beginning. :-)

Based on that experience, we'd like to pursue the following specific changes/goal for Panopoly 2.0:

  1. Eliminate "concentrations of code" in Panopoly, and move them out into contrib. During Panopoly 1.x, we've spent a disproportionately large amount of time maintaining the few concentrations of code in Panopoly. We'd prefer to move those out into to contrib to be maintained by a wider community, and limit Panopoly's code to pulling in, configuring and integrating contrib modules. Specifically, here are some examples:
    1. Panopoly Magic: The primary job of Panopoly Magic is to provide live previews of Panels widgets. In Drupal 8, Panels widgets are blocks, and this functionality could be useful even on a site without Panels! Rather than porting Panopoly Magic to Drupal 8, we'd like to implement this "block preview" functionality within CTools in Drupal 8.
    2. Spotlight widget: The Spotlight widget was intended to be the "simplest slider that could possibly" work, with the idea that if you wanted a real slider, you'd use something from contrib. However, a lot more people used it than expected, and we spent a considerable amount of time fixing bugs in it. Rather than porting it to Panopoly 2.0 as part of Panopoly Widgets, we'd like to have an external app (ex. maybe panopoly_slider?) that uses contrib modules to build a real slider. Ideally, this would be maintained primarily by the community, rather than the core Panopoly developers.
    3. Content Item widget: The "Content Item" widget is a clever Views widget that provides better usability than the CTools "Existing content" widget. It was simple to create using Views, but it turned out that there were a number of subtle edge cases that meant we had to implement several Views hooks for it to work correctly. Looking back, it would have been easier to implement in custom code OR to improve the usability of the "Existing content" widget from CTools. Rather than porting this, it'd be great to just make the CTools widget usable from the beginning!
  2. Put media support in a new Panopoly Media module: In Panopoly 1.x, we have media support in Panopoly Widgets. Media ended up seeping into several other places making for some weird dependencies, but it'd be hard to move without breaking the upgrade promises we made for Panopoly 1.x. For Panopoly 2.x, let's put media in a new Panopoly Media module!
  3. Break Panopoly Widgets into more modules: A common complaint in Panopoly 1.x, is that some users don't want all the widgets included in Panopoly Widgets. While it's possible to disable any individual widget, you're stuck with any modules that widget might depend on which led to several users forking Panopoly Widgets. In Panopoly 2.x, the main panopoly_widgets module will only contain those widgets which have no additional dependencies - if an additional dependency is necessary, it will go in a seperate module. For example, this means that the "Map" widget, which depends on simple_gmap would be in a panopoly_widgets_map module by itself. (The media widgets will move to the Panopoly Media module.)
  4. Break panopoly_search into panopoly_search_solr and panopoly_search_db: For the same reasons as with Panopoly widgets, many people have been unhappy that Panopoly 1.x always includes support for both DB and SOLR search, but their site may only use one or the other. In Panopoly 2.x, let's split these into two sub-modules of the main panopoly_search module!
  5. Drop respondjs: No more IE8 support in Drupal 8! :-)
  6. Include some tours to help site managers get started: Drupal 8 includes the new "tour" module which allows providing interactive walk-throughs, however, Drupal 8 doesn't really provide any tours itself. To help demystify both Drupal and Panels, let's create some really great ones for Panopoly 2.x!


  1. Open Panopoly issues for each of the features in "What will be included in Panopoly 2.0" above and make this issue their parent issue
  2. Open issues in all the contrib projects for what needs to be implemented their to make that happen, and link to those issues from the relevant Panopoly issue
  3. Start implementing!


dsnopek created an issue. See original summary.

dsnopek’s picture

Issue summary: View changes
Francewhoa’s picture

Hi all :) Related question in that ticket

dsnopek’s picture

Issue summary: View changes

Remove CTools issue - it was the core issue, not the IPE one, and that functionality is in the IPE already.

dsnopek’s picture

Issue summary: View changes

Added a point about panopoly_demo.

dsnopek’s picture

Issue summary: View changes

In fact, added a whole issue for panopoly_demo: #2549709: [meta] Panopoly 2.x for Drupal 8 battle plan

We need to get out of "code slush mode" and start creating issues for new code!

dsnopek’s picture

Issue summary: View changes
kattekrab’s picture

Hey - I was lookign around for an update on where panopoly for D8 might be at.

Any chance you could give us a quick update on how things are going?

dsnopek’s picture

Unfortunately, not much has changed since the 2.0-alpha3 release back in May. I had a client to sponsor my work on this, but their priorities have changed. :-/ I'd really love to work on it (as I'm sure the other co-maintainers would too!) but it's hard to fit it in.

That said, 2.0-alpha3 did make good progress against some of the points up in the issue summary! Point 1, 3, 4, 5 and 7 have existing implementations, but they are of varying degrees of completeness. I started work on point 6 (back in June) and I think there's a patch in the IPE queue for point 2.

So, we're not actually that far from switching to -beta, we just need to get back to hacking on it. :-)

dsnopek’s picture

Issue summary: View changes

Put correct issue for porting panopoly_demo in the issue summary: #2732417: Port Panopoly Demo to Drupal 8!

dsnopek’s picture

Issue summary: View changes

Points 1, 2, 3, 4 and 7 are done enough to take off this list!

For point 5, there's still #2729249: Implement "Content item" and "Content list" widgets in Drupal 8

Point 6 still has lots to do

And we've added a few smallish child issues that don't represent big points, that should still get done before 2.0

kattekrab’s picture

Awesome @dsnopek - that sounds like great progress indeed! :-)

dsnopek’s picture

I've had an idea for an alternate way (or additional way? it doesn't really prevent the original plan) to approach the Panopoly port to Drupal 8!


One of the problems with Panopoly in Drupal 8, is that traditionally Panopoly took best practices and well established approaches/modules and assembled them into a coherent whole - however, in Drupal 8, even 2 years after release, best practices are still evolving and it's a little up in the air what the established approaches/modules will be. Panels in Drupal 8 exists and (I say this with love - I wrote a lot of the code in it) kinda still sucks :-) - it needs a lot more work, just more human hours to invest in finishing it. But also, core is encroaching on what Panels and Display Suite and Panelizer did in D7, and it's unclear where exactly that's going to land: will it completely replace Panels/DS/Panelizer and then contrib will extend what's in core? Or will there still be a place for Panels/DS/Panelizer?

However, in working with Drupal 8, there's lots of places that I think Panopoly could contribute! There's still some pretty serious bugs or omissions in core that are being worked on, but still aren't fixed despite being known for a long time. For example:

There's also some things that are very difficult to configure right, like Media or WYSIWYG.

My idea:

So... Instead of trying to make a minimally viable whole, what if we instead focused on making some maximally viable feature modules?

If we made a really, really great panopoly_media module that setup Media in a way that was a good default that also corrected the most glaring existing bugs, that would be useful to people building Drupal 8 sites right now, without (hopefully) betting on an approach or best practice that won't pan out.

The ones I'm mostly thinking about are:

  • panopoly_images
  • panopoly_media
  • panopoly_wysiwyg
  • panoploy_widgets

Those don't depend on Panels, and represent some stuff that could use better defaults and some bug fixes.

I've already started using the first 3 in other projects, actually. And even though they don't have that much functionality currently, it's still nicer to use them than having to recreate their configuration on each site.

candelas’s picture

Panopoly Widgets: Excluding all the widgets that depend on external dependencies which don't have Drupal 8 ports yet (like the Map and Table widget)

Just in case it's useful to you:

Interesting for migrating media

dsnopek’s picture

@candelas: Great, thanks! It sounds like there aren't any dependencies we're blocked on :-)

kainio’s picture

First I want to thank you guys for creating and maintaining this project, I tried the D7.X of this module in panteon, Ilike it, but I am interested in the D8 port, can some one tell me when a beta version will be available?
I am willing to create an educational distribution based on panopoly.

dsnopek’s picture

Hi @Kaino! Unfortunately, there's no clear deadline. I think it's more likely we'll have some pretty good components that are "beta quality", before we have a complete distro it is.