[meta] Convert Debut features to Panopoly [#1886972]

The Panopoly set of apps largely achieves the key aim of Debut: to serve as a base set of features that multiple distros as well as individual sites can be based on. While Debut is used in Open Outreach, it has not been used in other distros. For Open Outreach, we are planning to move to Panopoly, see #1664956: Make Open Outreach Panopoly-based, which will necessitate changing Debut features to work with Panopoly.

We could do so in one of two ways.

First, simply add in Panopoly compatibility to Debut features.
Upsides: easier conversion; easier to maintain alongside existing Debut features; ability to retain some Debut distinct elements and approaches; avoid confusion by creating yet more projects; might ease the upgrade process.
Downsides: distros wanting to use the resulting features would need to add two base features sets (Panopoly and Debut) as well as their own custom features; we could end up with equivalent Panopoly apps, leading to confusion and duplication.
Second, selectively move Debut apps to the Pantheon namespace as part of the conversion.
Upsides: more potential for usage outside Open Outreach.
Downsides: more work.

Plan: take first approach initially, with second as a possible future followup.

Which of the existing Debut apps lend themselves to Panopoly versions?

The general approach:

Rely on existing Panopoly features wherever possible, even if they don't do everything that Debut ones did.

Here is a draft list of existing Debut features and where/how they might be handled.

Debut features to be replaced by existing Panopoly features

Debut Article > Panopoly News
Debut Bio > Panopoly Users
Debut Highlight > Pantheon Widgets, spotlight widget
Debut Section > Pantheon Page and Pantheon Widgets sub-menu widget
Debut WYSIWYG > Panopoly WYSIWYG

Debut features to make Panopoly-compatible in new 2.x branches.

Debut Blog (#2010058: Convert Debut Blog to Panopoly)
Debut Comment (#2010070: Convert Debut Comment to Panopoly)
Debut Event (can https://drupal.org/project/panopoly_event be used?)
Debut Forum (#2010068: Convert Debut Forum to Panopoly)
Debut Location (#2010074: Convert Debut Location to Panopoly)
Debut RedHen (#2010962: Convert Debut RedHen to Panopoly)
Debut SEO (#2010076: Convert Debut SEO to Panopoly)
Debut Social (#2010078: Convert Debut Social to Panopoly)

Lower priority:

Debut Link. Need is partially covered by the Panopoly Widgets link widget.

Debut features to consider deprecating without porting

Debut Media

What needs to be added for Panopoly compatibility?

Rename field_content_image instances to field_featured_image.
Remove code in .install file that creates field_tags.
Add field_featured_categories.
Add field_featured_status.
Remove Apps integration.
Remove Context usage, replacing with Panels. Add default page and panelizer configuration modeled on Panopoly News.
Replace content type CSS with images/CSS modeled on Panopoly News.
If present, remove image style swapping in hook_field_default_fields_alter().
Convert views to use content panes instead of pages and blocks.
Add panelizer strongarm variables based on Panopoly News.
Update Debut .make.inc files and rename to .make.
Remove Debut obsolete advanced help (left over from 6.x versions).
Revisit Debut hook_menu_local_tasks_alter() usage for adding node/add/contenttype local tasks to landing pages. Is this still needed? How would it be implemented in Panopoly?
Remove Debut hook_field_default_fields_alter() implementations that swap in an image style supplied by Debut Media.

Possible follow-up steps:

Remove Apps compatible usage, replacing with Default config. Move some additional config to Default config.
Revisit Debut dependencies on Captcha. Consider removing hook_install() captcha configuration or else wrapping in a module_exists('captcha') test.
Revisit local task integration on landing pages; see documentation on "Views and local action".
Revisit content type social media integration, currently implemented through a debut setting in .info files; see documentation on "Special Debut integration".
Revisit the hook_enable() code that rebuilds features as a workaround for #1572578: Rethink the way features are enabled / disabled.

Conversion checklist

The following captures the basic conversion steps needed.

Remove obsolete advanced help

Remove a 'help' folder (if present) and all its contents.
In the .info file, remove 'advanced_help' as a dependency.

Remove context module usage

remove context include file
remove context references in .info file

Update .make file

remove self-reference to feature
remove advanced_help
ensure all versions are up to date
remove .inc extension from .make.inc file

Change field names

In *.features.field.inc, from debut_blog, copy over field_featured_categories, field_featured_image, and field_featured_status, changing 'blog' as appropriate. Also copy relevant lines from the translation strings at the bottom of the import.
In *.info, remove field_content_image and field_tags and add field_featured_categories, field_featured_image, and field_featured_status. This too can be copied and adapted from blog.
Remove tags creation from *.apps_compatible.inc.
Remove image style swapping in hook_field_default_fields_alter().

Convert views to use content panes

Consider replacing existing view with version modified from Panopoly News. Look at the Debut Blog 2.x feature for examples to work from.
Otherwise, create content pane displays and remove existing block and page displays.
In the rare case where it may be necessary to keep an existing page display - e.g., event calendar - make sure the panels page has the desired path and give the view a different one. Also ensure the view doesn't have an assigned menu item.

Create panels pages and panelizer settings

Consider adapting the panels pages in Debut Blog by copying over and renaming the *.pages_default.inc file.
Adapt the panelizer settings in Debut Blog by copying over and renaming the *.panelizer.inc file.

Update the .info file to include:

features[ctools][] = page_manager:pages_default:1
features[ctools][] = panelizer:panelizer:1
features[ctools][] = panels:pipelines:1
...
features[page_manager_pages][] = [TYPE]_articles_author
features[page_manager_pages][] = [TYPE]_home_page
features[panelizer_defaults][] = node:[TYPE]:default
features[panelizer_defaults][] = node:[TYPE]:default:default
features[panelizer_defaults][] = node:[TYPE]:default:featured
features[panelizer_defaults][] = node:[TYPE]:default:teaser

Update the hook_ctools_plugin_api() implementation in *.features.inc to include:

  list($module, $api) = func_get_args();
  if ($module == "page_manager" && $api == "pages_default") {
    return array("version" => "1");
  }
  list($module, $api) = func_get_args();
  if ($module == "panelizer" && $api == "panelizer") {
    return array("version" => "1");
  }
  list($module, $api) = func_get_args();
  if ($module == "panels" && $api == "pipelines") {
    return array("version" => "1");
  }

Copy over RSS content type

Copy over the plugins/content_types directory from debut_blog.
Rename the *_rss.inc file and the hook_CONTENT_TYPE_content_type_render() implementation

Copy over pertinent strongarm variable settings.

Add the following to the .info file:

features[variable][] = field_bundle_settings_node__[TYPE]
features[variable][] = menu_options_[TYPE]
features[variable][] = menu_parent_[TYPE]
features[variable][] = node_preview_[TYPE]
features[variable][] = node_submitted_[TYPE]
features[variable][] = panelizer_defaults_node_[TYPE]
features[variable][] = panelizer_node:[TYPE]_allowed_layouts_default
features[variable][] = panelizer_node:[TYPE]_allowed_types_default

Copy over and adapt the corresponding settings from blog.features.strongarm.inc.

Migrate CSS and/or images to Panopoly styles

If there is any CSS or images, determine if they are still needed. If so, make any adjustments needed.

Issues

Need to decide how to handle Features field export. This is now split into base fields and instances (see #1064472: separate fields from field instances). Panopoly migration is noted in #1967304: Separate field_base from field_instance in Panopoly Widgets.

Comments

Comment #1

nedjo

he/him/his

English

commented 12 January 2013 at 16:02

I'm in communication with populist about migrating selected Debut features to Pantheon. Although it'll be a bit of work, I'm excited about this prospect. I'm hoping to schedule in a sprint soon to dig into the migration. Anyone interested in pitching in, please let me know!

Comment #2

niccolox commented 13 January 2013 at 06:04

If I can I will help.

Was wondering where to start?

Debut Highlighted
Debut Blog
Debut Article

How to migrate existing OO sites?

Comment #3

sonicthoughts commented 1 February 2013 at 06:30

Migration of existing OO sites does concern me a little. Frankly we have only used about 30% of the Apps so I don't think it will be too bad, but would hate to have to spend a lot of time migrating (if avoidable.)

Although not specific to OO->Panopoly, please consider the upgrade dilemma of distros in that you may want to upgrade the modules (or core) before the next profile is released.

Thanks for a wonderful contribution.

Comment #4

nedjo

he/him/his

English

commented 1 February 2013 at 18:31

Yes, migration is definitely on my mind.

I think we could do similarly to the Commerce Kickstart distro, where a 2.x branch was developed but the 1.x branch is still maintained. So we would continue to maintain the existing Debut features alongside a 1.x branch of Open Outreach. Meanwhile, we would develop alpha and beta versions of the new Pantheon based features/apps alongside a 2.x branch of Open Outreach, without an upgrade path from 1.x to 2.x. The two branches of Open Outreach would suit different purposes, and there could still be reasons for groups to create new sites on the 1.x branch: lower overall code profile (since Pantheon adds a fair bit), simpler sites, more stability as no new features would go into the 1.x branch.

Ahead of a 2.x RC1 release, we would evaluate and decide whether to provide an Open Outreach 1.x to 2.x upgrade path, depending on factors like usage/uptake and available resources or funding. Even if we didn't provide an upgrade path, we might have migrate classes in place that would facilitate upgrading and some accompanying documentation.

So overall we would be adding features to a new Open Outreach branch but not abandoning existing 1.x and Debut users.

Comment #5

rerooting commented 2 February 2013 at 23:48

Panopoly conventions might include using fieldable panels panes when blocks or content type entities were used previously, for example.

Thus, the OpenOutreach Slider might instead be a fieldable panel pane 'Widget' as the Panopoly naming convention would ascribe, though I would suggest use of either field slideshow with field_collection (as we are usually doing with the radix theme) or a field collection which uses views_slideshow (via a field_collection_views formatter or EVA). The absence of a 'slide' content type clears up the content list, the Create Content form, etc. however the slideshow would still be readily editable inline. Additionally, more slideshows can be easily added in a way where slides are managed contextually. I've found that the spotlight widget can be a bit limiting and unreliable, especially when folks want to add more fields.

Another thing to do will be converting all the views that are pages, blocks, etc. to content panes. Each of these content panes can have exposed configurations that will be available specifically in the IPE. For example - sorts, filters, fields, display choices, even arguments! You may find that this level of flexibility can help reduce the proliferation of views that are needed for any feature, and may lead to a more lean & keen organization of views and their displays.

Comment #6

sonicthoughts commented 3 February 2013 at 06:14

From my perspective, I think:
1. tools (like classes, import/export, docs, etc.) to help migration would be of high value approaching a pure migration tool.
2. I understand the need to maintain 1.x branch, but not sure how realistic it is - personally, I'd prefer to get off the old branch and focus efforts (over reasonable time period.)
3. If starting a new site today - would you suggest RC8 or 2.x.dev ? If latter, then I would suggest quickly releasing an official dev branch, even if it has bugs, rather than send folks down the wrong path. What kind of timeframe do you have in mind?
4. Not to turn the tables, but have you any thoughts on SPARK? seems like a competitive approach, but may want to keep tabs on it.

Thanks again!

Comment #7

rerooting commented 5 February 2013 at 15:50

4. Spark is quite different actually! In fact, one could probably use some of spark's features alongside panopoly, or use panelizer heavily with spark for that matter. The fact that so many distributions are moving to panopoly is probably a good sign though!

Comment #8

niccolox commented 6 February 2013 at 23:15

regarding panopoly-based distros

what is there in the works?

Open Atrium has started
Open Outreach is planned

what else?

Comment #8.0

nedjo

he/him/his

English

commented 6 February 2013 at 23:34

Issue summary:

View changes

Sketch in details of work needed.

Comment #9

nedjo

he/him/his

English

commented 11 February 2013 at 01:29

If starting a new site today - would you suggest RC8 or 2.x.dev

Beyond some basic preparation we haven't begun work on a Panopoly compatible version of Open Outreach. So for now and for a good while to come the 1.x branch is and will be the only usable version.

Re Panopoly distros, besides plans for Open Atrium and Open Outreach, there is:

The core of the Web experience toolkit is largely forked from Panopoly.

Comment #9.0

nedjo

he/him/his

English

commented 11 February 2013 at 01:29

Issue summary:

View changes

Add in Debut Event, fix incomplete sentence.

Comment #9.1

nedjo

he/him/his

English

commented 11 February 2013 at 18:31

Issue summary:

View changes

Add a couple more items to address in migration.

Comment #10

nedjo

iurquiza commented 19 April 2013 at 01:53

Hi would like to get involved in porting some of the apps to panopoly. I am fairly new to Drupal, but I have been researching it for several months now. I tried to clone the repository listed in http://drupal.org/sandbox/nedjo/1914610, but it only contains a README.txt file. How can I check out one of the "versioned branches"?

Comment #14

rerooting commented 19 April 2013 at 16:38

Make sure you are checking out the 7.x-1.x branch!

Comment #15

iurquiza commented 25 April 2013 at 00:59

Thanks!
For others looking for instructions: http://drupal.org/project/1914610/git-instructions

Comment #16

afinnarn commented 26 April 2013 at 19:52

I'm in the same boat as @iurquiza. New to Drupal development, but I want to help non-profits more easily use Drupal.

@rerooting I'm confused on the 7.x-1.x branch mention. I see a 7.x-2.x branch for Debut Blog where I thought the changes to convert to Panopoly were going, but I'm probably wrong.

What is the 7.x-2.x branch meant for? I see it on some Debut apps but not others. Forgive me if this is a RTFM question.

Comment #17

afinnarn commented 6 May 2013 at 19:27

Regarding Debut Event conversion, I just saw this "Panopoly Event" effort: http://drupal.org/project/panopoly_event

I'm still too new to tell how close or different this event package is from the aims of Debut Event, but I thought I would mention it in case there is collaboration potential.

There's also a paid event module: http://drupal.org/project/panopoly_paid_event

Comment #18

sonicthoughts commented 6 May 2013 at 21:11

redhen uses http://drupal.org/project/registration

Comment #19

rerooting commented 6 May 2013 at 23:03

Panopoly event/paid event are features-driven implementations of the ER (registration) module and ER + registration commerce, respectively.

These both are approaches to events that allow people to register. When I do event features for distros like these, I use a layering as such : events > events w/registration > paid registrations so as to ensure minimal bloat for any implementation case. Also, the handy thing about using panels is that they could easily switch between a calendar-based and a very dynamic event listing setup, and all the panes will be there ready to go and customize. Event features with panelizer/IPE/views content panes are very powerful!

Comment #20

afinnarn commented 14 May 2013 at 22:31

For others following this, I just found a notice on the DrupalCon Portland website about a "proposed" session by @nedjo: "Open Outreach 2.x - planned for release at DrupalCon Portland - brings a lot of great flexibility and design enhancements via the Panopoly base distribution." http://portland2013.drupal.org/session/build-great-nonprofit-site-week-o...

Since it still says "proposed" at this point, I don't know if it went through as a session, but that's exciting news if 2.x will be released next week!

I'm still too much of a noob to try and tackle some of these issues I've tried so far, so I'm just going to start by testing patches and get Drupaled up from that. I'll certainly check back soon for any good news.

Also Panopoly made another candidate release at the end of April that I didn't notice until now...maybe a Panopoly 1.0 release at DrupalCon is in the works?

Comment #20.0

afinnarn commented 14 May 2013 at 22:31

Issue summary:

View changes

Add migration steps for RSS ctools content type.

Comment #21

pmackay commented 2 June 2013 at 09:59

Keen to also get involved. I've created a number of child issues for each Debut feature and added links above.

@nedjo: can you clarify why Debut RedHen would move to being Open Outreach RedHen? Why not stay as Debut RedHen?

@rerooting: about your "layering" comment above, does that imply separate content types for "event", "event with registration", "paid event"? Would they all live inside Debut/Panopoly Event?

Comment #21.0

pmackay commented 2 June 2013 at 09:59

Issue summary:

View changes

Add links to Debut feature issues.

Comment #21.1

pmackay commented 3 June 2013 at 17:16

Issue summary:

View changes

Add link to RedHen issue.

Comment #22

nedjo

he/him/his

English

commented 11 June 2013 at 20:45

Thanks @pmackay for posting issues and digging into some of the update work. I haven't had a lot of time for this in the past couple of months. The general idea is: try go get a basic Panopoly-based version of Open Outreach working, then consider options from there.

Re Debut RedHen, yes, a Panopoly compatible version should be worked on in a 2.x branch of Debut RedHen. Shouldn't require a lot of work as we don't do much beyond basic RedHen integration.

Comment #22.0

nedjo

he/him/his

English

commented 11 June 2013 at 20:45

Issue summary:

View changes

Add upgrade steps.

Comment #23

pmackay commented 14 June 2013 at 07:18

@nedjo: could you add some more detail in the checklist about what the CSS and image changes might be? Is there a reference of the Panopoly styles for this anywhere?

Comment #24

sonicthoughts commented 17 June 2013 at 15:13

Component:

Code

» Candidate Debut feature

BTW - another reason to consider this is that it could be a great tool to publicize openoutreach and drive adoption. Panopoly and related projects are on many people's radar. Including support for OR might get us some nice exposure ....

Comment #24.0

sonicthoughts commented 17 June 2013 at 15:13

Issue summary:

View changes

Add note about base/instance field exports.

Comment #25

pmackay commented 8 November 2013 at 10:29

@nedjo, given recent comments in #1664956: Make Open Outreach Panopoly-based, what are your views on this work to make the Debut modules compatible with Panopoly? I've invested quite a lot of time in helping with this migration. Partly this was to be able to reuse some of the Debut modules in OpenLocal. I'm still interested in whether they could be reused in this way. In which case it would be quite helpful to be able to create tagged releases for them at some point.

Comment #26

nedjo

he/him/his

English

commented 20 November 2013 at 00:47

@pmackay: since I'm focused on 1.x, I won't have time to contribute to maintaining Panopoly-compatible, 2.x versions of Debut features. So ahead of posting any releases we would need to determine a maintenance plan for the rest of the Drupal 7 cycle. Another question is the recommended branch, which I'll want to keep at 1.x.

Have you considered whether your OpenLocal work could be based on OpenAtrium? If I were building a Panopoly-based distro at this point, I think I'd look first at what pieces of Atrium I could build off of.

Comment #27

pmackay commented 20 November 2013 at 12:27

@nedjo: thanks for replying. Sounds like any form of Debut/Open Outreach on Panopoly is not going to move forward currently. I think it would need a greater level of interest than seems to be available.

My thinking with Atrium is that it might be more work to extract useful bits, or customise to the needs of what I'm doing, compared to basically building features. Maybe I'm wrong about that, hard to know how to get more detailed advice.

Comment #28

frederickjh

he/him

English

The Big Island of Hawai'i

commented 9 July 2014 at 15:48

It has been 8 months since the last posts on this issue saying that moving Debut Apps or Open Outreach to Panopoly is most likely not going to happen. It may be time to mark all these convert Debut Apps to Panopoly as Closed (won't fix).

Comment #29

frederickjh

he/him

English

The Big Island of Hawai'i

commented 9 July 2014 at 15:51

#1664956: Make Open Outreach Panopoly-based has already been marked as Closed (won't fix) so it make little sense to convert Debut Apps then either.

Comment #30

frederickjh

he/him

English

The Big Island of Hawai'i

commented 9 July 2014 at 15:56

Comment #31

rosemarymann commented 27 February 2015 at 00:02

Status:

Active

» Closed (won't fix)

After initial investigation, we hit a number of issues and decided not to pursue this direction.