Panopoly is mapping out solutions to a lot of key problems. Making Open Oureach at compatible with - or even based on - Panoply would have major pluses:

  • Access a bunch of great functionality not yet in OO, like responsive layouts and image styles, faceted search, and Solr integration.
  • Get a lot more flexibility in site design.
  • Free up OO development time to focus on nonprofit-specific problems rather than general distro ones.
  • Provide continuity for site admins using other Pantheon-based distros.

There are also of course some potential barriers to consider:

  • How to handle block placement? This is probably the biggest question. Currently we're using Context. Yes, we can switch to Panels, but there are several holes. Panels doesn't do site-wide block placement, which we have several instances of, and doesn't handle block placement in theme regions. A couple of related issues here: #1557842: Allow Feature module exports to add Panes to Existing Panels, #1642308: Define best practices for block placement in Panopoly-based distros or sites. Also relevant is the interesting code by sun in #680064: Control theme regions.
  • We're already into release candidates for OO. Switching now to Panopoly would be a major swerve and introduce a lot of instability, plus unexpected changes for existing OO sites.
  • Panopoly would increase the base footprint of Open Outreach. Would it push OO beyond what many shared hosts provide?
  • What to do with overlapping functionality? Luckily there isn't a lot. One however is debut_wysiwyg and panopoly_wysiwyg. If we were to switch from the former to the latter we'd need, at least, an update to migrate existing content's text formats.
  • More short-term work focused on general distro issues and detracting from some pressing OO-specific ones like CRM integration.

Work is underway mainly in the Debut issue queue, see #1886972: [meta] Convert Debut features to Panopoly.

Comments

populist’s picture

I think that there is a lot of potential for a distribution like Panopoly to serve as a foundation distribution for a lot of other distributions, including Open Outreach. There has been a lot of activity on the Panopoly project in the last couple of months and there is a driving goal to get an RC out by Drupalcon Munich and a stable 1.0 release out by BADCamp. There is also a newly created issue #1713516: Provide Documentation on How to Use Panopoly as a Base Distribution to capture the technical work to get things integrated, but here are some feedback around your barriers and some other thoughts:

General Thoughts

The actual technical work required to get Panopoly serving as a base distribution is actually relatively light. There are some modules that need to be included and some duplicate functionality to consolidate, but Panopoly doesn't really force the site down any one path of development (i.e. its possible to use context/spaces as a way to drive most of the sites pages and only use Panopoly's power for a few key pages). That being said, its better to integrate with more of Panopoly's magic (i.e. use layouts, integrate with views, etc) but that can be incrementally and optionally done. This is also something I personally want to see happen and would be happy to help assist + test + integrate.

Specific Thoughts

How to handle block placement? - This is probably the $64,000 question around all of this and I have seen a lot of different ways to solve this. The easiest solution is to realize that most sites have relatively modest needs around the sidebar and it would be easy enough with the proper page library #1713506: Create a Master Panels Page Administration Pane to make the process "if you want to change the sidebar, just change all the pages. This obviously wont scale, but might be easy enough. The more elegant solution would be to leverage the power of mini panels #1713524: Mini Panels + the Sidebar Problem to create different "sidebars" that can be placed through the IPE and generally administered from an admin/dashboard/sidebars page.

We're already into release candidates for OO - This is certainly going to be a judgement call for what you want to do and a lot will depend how many people are running your stuff, but there are two ways we could deal with this. The first is to incrementally upgrade to Panopoly by switching a couple of the most visibile features (WYSIWYG, Search) + adding the right modules + switching over the main landing pages with the rest of the pages coming soon. The second is to create a 2.x branch of the distribution that has Panopoly support and assume to do a switch in the future.

Panopoly would increase the base footprint of Open Outreach. - This is also a concern of mine and I have done some work recently to "slim down" the distribution. There are a lot of modules that were not needed (certainly not by default) and those have been removed. There is also some conditional work that can be done to limit how much memory + footprint they have.

What to do with overlapping functionality? - This is the easy one. Just pick the best parts of all overlapping functionality and we can merge them together. There would need to be a text format upgrade path, but thats pretty easy to write.

More short-term work focused on general distro issues and detracting from some pressing OO-specific ones - This is worth talking about but there are some huge wins to basing off Panopoly that will continue to have solid support on Pantheon's end and will work hard for a D8 upgrade path.

populist’s picture

Here is the newly created documentation for how to implement Panopoly as a sub-profile - http://drupal.org/node/1651128

sonicthoughts’s picture

This looks very promising and can avoid a lot of duplicated efforts! My vote!

nedjo’s picture

@populist: thanks for the thoughtful and detailed comments. I'm interested in pursuing this although likely I won't have development resources for this for awhile as I'm focused on CRM integration.

nedjo’s picture

I've created a new panopoly_compatible branch on Open Outreach and applied an initial few patches.

populist’s picture

Just wanted to drop in here to see if there might be renewed interest in going a Panopoly route. With Open Atrium going Panopoly (http://www.agileapproach.com/blog-entry/moving-forward-open-atrium-20) this could be a good way to work together on some Apps/distribution magic. Happy to do the legwork to make sure Panopoly works for you, but I realize it takes time to architect a distro and its not possible in D7 maybe we can chat about it for D8.

sylus’s picture

Woot Open Atrium going Panopoly! That is amazing news. ^_^

sonicthoughts’s picture

I thought as per http://drupal.org/node/1664956#comment-6461556 there is already a distro in progress. definitely has my vote.

nedjo’s picture

Yes, I want to push ahead with this work (though I'm travelling in Ecuador for the next two months and a bit so won't likely get a lot done till after that...).

I started in on a new branch and the changes to the Open Outreach install profile look to be pretty simple. The main question we need to decide is what to do about the use of Context in the current Debut features/apps.

I don't want to start maintaining different branches of each feature. I'd love some input or ideas here as to how best to do this. The options I'm seeing seem to be:

  • Remove Context and replace with Panopoly-style panels. (For this I'd need to look into what Panopoly does with other Context-controlled stuff like breadcrumbs and active menu items.)
  • Make Context optional--implement some sort of switch so that a given site can use either Context or Panels as its primary layout mechanism. This would be complex to implement but would support existing sites that might have already customized contexts.
joelcollinsdc’s picture

@nedjo, we are facing a similar tough question (page layout options) with a panopoly based distro. The question to me doens't seem to be as much panels verusus context but rather how much of the page is panels-controlled (i.e. is the "content" area) versus how much is theme controlled? For instance, openacademy leaves the header/footer to the theme and everything else is the content area. The biggest disadvantage to this approach seems to be the ability to set things site-wide (such as a sidebar navigation 'block'). The biggest advantage of this approach is the unified layout experience for an editor.

I'd love to hear more around what people are deciding in these areas. With more and more things moving panopoly-based (atrium), standards are bound to bubble up.

nedjo’s picture

@joelcollinsdc: see #1557842: Allow Feature module exports to add Panes to Existing Panels for relevant discussion and ideas.

niccolox’s picture

The openatrium 2 panoply port has addressed this context issue. See the phase2 blog

mariomaric’s picture

@niccolo: Are you talking about this blog post?

http://www.agileapproach.com/blog-entry/moving-forward-open-atrium-20

nedjo’s picture

The post is this one: http://www.agileapproach.com/blog-entry/open-atrium-20-code-sprint-pantheon

and specifically this issue, #305289: Integration with Panels module, which would allow Context to control panel pane display.

As part of the planned transition to Panopoly, I've been talking with populist about migtrating many or most of the existing Debut apps to Panopoly (e.g., debut_blog > panopoly_blog). Panopoly achieves the basic aims we began with in Debut--to provide base features that can readily be used either stand-alone or incorporated into multiple distributions. Debut features are already abstracted and should be relatively easy to convert, adding in some Panopoly specifics.

mariomaric’s picture

Thx nedjo for link, unfortunately and strangely it's not in my Drupal planet feed, so I missed it.

Migrating Debut apps to Panopoly are great news and I believe will be HUGE benefit to all folks going the Drupal distributions path. :)

Cheers!

niccolox’s picture

yes nedjo, that's them

Context (Module) and Panels [#305289 Integration with Panels module]
Many people have considered Panels and Context (Module) to be two completely different (and opposing) methods to perform site building and layout. But I've always thought they could co-exist and found this old #305289 issue talking about integration. Panels and Context both have their own "access rules" or "conditions" that can be used to control whether "panes" or "blocks/boxes" are displayed. And while these two sets of condition rules overlap a great deal, there are still some contrib modules that set a particular Context condition that would be nice to use to control Panels panes. Turned out to be pretty easy to write a new CTools access plugin that fires whenever a specified Context is true. The plugin simply shows a list of all Contexts defined in the Context UI and allows you to select which ones you want to use. If any of the selected Contexts are set, then the CTools access plugin returns True to select the Panels pane using that selection rule. It's a limited use-case, but now you can use the Context module to control which panes are displayed on your page within Panels.

nedjo’s picture

Opened #1886972: [meta] Convert Debut features to Panopoly for detailed planning of what it would take to move to Panopoly.

rerooting’s picture

We are already underway with something of this sort, would be glad to share in the effort! Once the features we are developing are ready for wider collaboration I will be sharing them. Expect to see some stuff in the next few weeks! We are using Radix + Panopoly, FYI.

niccolox’s picture

Am interested in this rerooting. My last site was Panopoly / Radix and previous to that Open Outreach

sonicthoughts’s picture

We are very excited about the prospect of migrating to Panopoly! The dilemma we face, however is that for current and new projects we want we are a bit reluctant to use OO because we do not want to waste effort down obsolete pass. Do you have some suggestions on how we should proceed? Would it be best to work off the Panopoly branch or use the RC and migrate? Any insight into timing and migration path? Of course there are no promises but if some idea of a timeline it would also be very helpful.

niccolox’s picture

Open Outreach is based on a very stable Dev Seed stack Blocks/Context/Features and also has a rich set of Debut * Features

Open Outreach has "86.79% of what you need"TM in a website and so saves loads of time and money

Panopoly has awesome potential and is great if you are an intermediate to advanced developer / site builder and are prepared to work through a bunch of issues

I just spent a couple of weeks working with Panopoly rc3 and its fun, but I missed all the OO Debut features, I built an OO based website for a non-profit group in a couple of afternoons

Panopoly just doesnt have those features, yet

sonicthoughts’s picture

Sure niccolo I get that - but my concern is not getting a site up and running, but keeping it maintained with reasonable TCO (Total Cost of Ownership.) over a 1-3 year period. Low TCO is what is great about Drupal and OO! what happens if in 2 months Panopoly is more stable and becomes the dominant platform. Now we have customizations based on the current distribution. Will we retrofit to take advantange of new enhancements? That becomes another (potentially expensive) project. Perhaps we should fight the bugs with the Panopoly branch now and save costs later. Just trying to get some direction and timelines...and assume others may have the same concerns....

niccolox’s picture

Oo is rc9. Panopoly rc3. Big gap

rerooting’s picture

How are folks finding Panopoly not stable? Have already launched half a dozen projects using panopoly, and it maintains very nicely. Was already using a similar stack/approach as is with panels, panelizer, fieldable panels panes. The only problem I've really run into is that I usually have to disable default content immediately or it causes some widget issues.

What I'm confused about is how building out OO's debut features will be more difficult with panopoly. I've already built staff directories, event calendars, document libraries, og-based collaboration spaces, map directories, drupal commerce stores, etc on top of panopoly. I'm even building a drupal native CRM using panopoly already! If anything, I'm finding the panels approach is much more seamless than using Omega, Delta, Context, blocks, etc. The best part about building distributions with panopoly is that it takes care of the most annoying parts of maintaining a distribution as is!

joelcollinsdc’s picture

FWIW, I recently attempted to build a panopoly-based distro, and unfortunately was unsuccessful. I found that I was spending more time trying to work around some weird oddity that was added based on a panopoly decision than I was actually working on my own distro's custom needs. I started removing (replacing, really) their modules with my own features-based versions of them until there wasn't much left...

Also, developing for sub-distributions isn't fun, not only do you have to balance drupal module changes you have to also manage changes to the parent distro as well.

http://drupal.org/project/issues/search/panopoly?text=&assigned=&submitt...

rerooting’s picture

Thanks for sharing your issues, looks like most of them have been fixed! It seems you had most of your issues earlier on with Panopoly, I have developed two distributions since december and haven't had as much difficulty as it seems you've had!

I don't agree with some of the approaches Panopoly takes either, but that's not a huge problem! For example, I despise the simple gmap module. Thus, in one of my distributions I disabled the widget and replaced it with a proper addressfield/geofield/geocoder implementation in a custom fieldable panel pane widget. I see it as a path forward, one with great promise!

Regardless of whether you think Panopoly is the right choice, as someone who used to swear up and down against panels, I don't see how anyone would want to use anything but after using panelizer and views content panes! My life has gotten so much easier since, hahaha!

nedjo’s picture

@joelcollinsdc, @niccolo, @rerooting, @sonicthoughts: thanks for sharing your experience and insights here. Definitely there are tradeoffs with building off of a base distribution. But there are big advantages too and strong strategic and practical reasons that continuing to build and maintain everything on our own is not sustainable.

I'm eager to dig in but, as usual, have to clear away other tasks first. I've created the Open Outreach 2.x branch and did the first rough sketching in of a Panopoly blog feature, http://drupal.org/sandbox/nedjo/1914610. I'm hoping to free up time to dig into this work within two weeks.

Re eventual migration from 1.x to 2.x, I'm thinking initially at least of a migration module with a fairly simple set of rules components plus views bulk operations to get the content migrated over.

Anyone who may be available to pitch into the Open Outreach 2.x work, please comment here or ping me via my contact form. Thanks!

niccolox’s picture

Am in. Have personal projects and soon professional projects on OO and Panopoly

niccolox’s picture

Am in. Have personal projects and soon professional projects on OO and Panopoly

nedjo’s picture

Title: Make Open Outreach Panopoly-compatible or Panopoly-based » Make Open Outreach Panopoly-based
Version: 7.x-1.x-dev » 7.x-2.x-dev

I've decided to do this work at least initially in 2.x branches of the Debut features rather than creating a bunch of new projects.

niccolox’s picture

Kit compliance viva

pmackay’s picture

I'd be interested in any thoughts on whether it would be worth developing any further modules for OO 1.x. Is the intention to focus all dev effort on a 2.x port to Panopoly or is there any rationale for further enhancing the 1.x distro at the same time, on the basis that it is a bit more lightweight, or based on Context layout, etc?

nedjo’s picture

I started to dig into a Paonoply based version in Open Outreach 2.x, but I'm increasingly unsure it's the right direction.

Compared to Open Outreach, Panopoly is heavily built, which may serve larger organizations but is unlikely to work for, e.g., typical shared hosting.

I hit a bug with jquery_update, https://drupal.org/node/1448490, and was reminded that trying to keep up with even more modules and their dependencies would be a headache. For example, none of the Open Outreach 1.x modules uses jquery_update, and likely we'd hit problems there.

Beyond that, there's the questions of Drupal's direction as a whole. It seems increasingly unclear how viable Drupal 8 is going to be for the organizations Open Outreach is for--small, low resourced, community based groups. I wrote about this in a recent blog post about Backdrop and Drupal 8.

So I'm focusing attention elsewhere.

niccolox’s picture

Pantheon already host Backdrop (and btw ergonlogic has a hack for Backdrop Aegir hosting)

personally, I've also cooled off Panopoly, its over engineered and too tightly bound and the ANTI Blocks/Context design pattern means its heading for some serious issues with Context in Core of D8

my guess is that Backdrop will become Panopoly, or they will converge

one thing Panopoly has been great for is to demo how powerful Panels UX has become, and think it would be a nice and simple update if the Panels UX was strengthened a bit in Open Outreach

so, the big question, what is the future of Panopoly if its architecture doesnt fit D8? will it go to Backdrop?

the Drupal vendor distribution ecosystem is fragmenting even more now with Backdrop.

Dustin@PI’s picture

A couple of things:

(1) I think that Drupal 8 will be great for small orgs. I work at a medium size org that has 5 people in software mostly working on D7, but for the charity that I volunteer at (with 0 employees) ... we are going with D8, because the combination of field-able blocks, Views in core and Twig means that we can do a simple brochure site with a Blog and Event list without touching a single line of PHP code, just a bunch of twig files (this is assuming that there's a Beta by December, if not we might have to change our plans).

(2) "Context" in core, i.e. the new Context API is more like a cross between Panels' context plugins (which is what Panoply uses) and Rule's context conditions then like the "Context Module" (at least from the perspective of creating a context plugin).

(3) the Spark project (and some of the parts that made it into D8) were inspired by Panoply.

I am not saying that Panoply is the best path for Open Outreach--it is very big, but I would not use the D8 architectural direction as a reason against it. D8 will mean many changes for Panoply, but many of them will be removing code and features that are now in core.

niccolox’s picture

thanks for explaining all of that

I'm actually really interested in D8 and want to work with it ASAP

I like the fact that its using Symfony2, Twig, Guzzle etc

I'd really like to see D8 dev released and usable and we could just move on

regarding OO and Backdrop, I thought that OO might be a candidate for Backdrop, but frankly, I dont trust Backdrop as a viable product, nate and jen are wonderful people but for Backdrop to succeed it needs resources and I suspect there are big Drupal shops behind it, and pushing it as a way to gain market-share for their own products and services

pretty quickly Backdrop will become incompatible with Drupal 8 and unless there are big players, or a genuine ground swell of support, I cant see it working as a viable product

Backdrop might drag on D8 for a while, but once D8 is released and stabilizes Backdrop will just fade away (or somehow be unforked)

thats my futures speculation for the evening, good night

sonicthoughts’s picture

Backdrop so far has raised about $6K which is 13% of what it needs to kick off. I don't think there is much viability here yet. Most likely the threat of fork will influence D8+.

niccolox’s picture

I was at badcamp and gave a talk exact same time as backdrop had a forking drupal session. There is huge sympathy for the economic rationale for backdrop but also real interest in tech aspects of d8. I would like to see a d8 standard distro of the standard of open outreach or wordpress...

niccolox’s picture

Issue summary: View changes

Link to #1886972.

nedjo’s picture

Version: 7.x-2.x-dev » 7.x-1.x-dev
Issue summary: View changes
Status: Active » Closed (won't fix)

Not a current priority.