Make "Landing Page" into node + Panelizer (rather than a Page Manager page)

Here is a patch that implements this. I haven't done a ton of testing on it yet, though.

Some TODO for my existing patch:

1. We need to consider pathauto for Landing Pages.. My current patch doesn't mess with it and it uses the same pattern as for Content Pages. Not sure yet if this is OK or needs to be changed.
2. We should put some sort of help/messaging on the node edit page for Landing Pages explaining that it only has the metadata, and you need to go to the View page and use "Customize this page" to change it's content.

@populist: Thanks for the feedback! Since you originally implemented the current Landing Pages, it's great to hear your thoughts about their pro's. :-)

To respond to them individually:

• Ability to be cleanly exported with features

I think anyone who is working with Features, has the skills to use the Page Manager directly. What I usually say when I'm explaining Panopoly to people, is that we try to improve the UX/UI and remove Drupalisms for users and site managers. Unfortunately, site builders will still have to deal with some Drupalisms and complexity.

So, I'm personally fine with saying that you have to use Page Manager if you're going to create a Page for export in Features.

• Different functionality than the "Content Page"

I think this is satisfied by this patch! There is no body field and so you get a creation form that basically the exact same fields as is on the current "Landing Page" creation form. In the current iteration of this patch, it's still using the node edit styling for Title and Permalink, but we could turn that off and really make it look exactly like the current "Landing page" creation form.

• Does not show up in search
• Does not show up in content lists

Hrm. These are very good points that I think we need to consider!

I've actually talked to a number of Panopoly users who wish that landing pages showed up in search! We'll need to make sure that this is configurable for both use-cases.

I don't see any reason why we'd want "Landing pages" to appear in content lists (outside of the admin "Content" page). But since most content lists are Views, we could just make sure to configure our content list views to exclude "Landing pages"!

But I think solutions to both those points could be added to my patch. :-)

For reference, here is a screenshot of the "Create Landing Page" form that you get with the current iteration of this patch (it includes the normal node edit styling):

And here is the "Create Landing Page" form for Open Berkeley, which I did a little differently (without the normal node edit styling):

Hopefully, that'll make this discussion a little more concrete. :-)

Just a note to myself about a change that needs to be made to this patch: We need to add the new permissions in a hook_update_N() function.

Sure! I've put a TODO section at the end of the issue summary.

Matt (@populist) and I discussed this yesterday, and he's approved the approach we're persuing here, that is: replacing Landing Page with a proper content type. So, now it's just a matter of finishing the patch! :-)

I'm not sure about 1.12, but it will be finished and merged into Panopoly relatively soon! I'd say if not 1.12, then 1.13.

Support issue which demonstrates why this issue is important: #2353893: Where are the Landing page list and options?

@cboyden: It might be possible, however, myself and @populist agreed that it isn't necessary to provide a conversion. Users who have existing page manager pages can continue to administer them the way they always have, before the switch to implementing "Landing pages" as nodes.

Alright! I tested out the latest patch, and updated the TODO in the issue summary with the things that are still unfinished. I think we're super close! Thanks for all your work on this, @caschbre. :-)

Specifically, here the things I think we still need to do to get this committed:

• Let's remove the 'node-edit' id that makes the page styled like the other node edit pages and make it look closer to the existing, simpler "Landing page" add form. Namely, the super small "Permalink" field should be normal sized, because it's more important on landing pages than content pages, and the fields should look less like the header to a form that's got nothing on it. :-) Here's where the setting is: /admin/structure/pages/nojs/operation/node_edit/handlers/node_edit_panel_context_landing_page/layout
• The new pathauto variable for panopoly_landing_page needs to be set in hook_update_N(), otherwise it won't get set for existing sites. This is because it's in defaultconfig which is only processed on module enable.
• Let's not configure pathauto settings for panopoly_page in this issue. In short, I'll just say that I don't want the automatic alias for panopoly_pages to appear at the top-level by default, whereas that's what I do want to happen with panopoly_landing_pages (so that's fine). But let's have that discussion on another issue and just remove the those settings from this patch.
• The help text looks great! But it's a little confusing when you're first creating node, because you can't view the page yet, it doesn't exist. Here's what it looks like in the patch:
  

  A Landing Page contains only metadata (e.g. title, path, menu option, etc.) by default. To add content to a landing page, first view the page and then click the "Customize this page" button.

  Maybe something like this would make sense in both contexts (new and existing):

  Here you can set the Landing Page's metadata, for example the title, path and menu options. To add content to the page, first save this form and then click the "Customize this page" button.

• We need to update existing the Behat tests so they don't break, and to add new tests for new functionality (for example, for pathauto - in the past the path was a required field).

I've backed down on the points about restricting what's displayed in a "Content list" and in the search results for now. I do think this is something we'll likely have to address in the future, though.

Usually you don't want landing pages to appear in content listings or search results, because they are things like the home page, the "Contact us" page, a special deal page for Google Adwords, etc.

Currently, you might use a "Content list" widget to display recently posted content (by not putting ANY restrictions on content type - it's a single select box), but after this patch is committed, your new landing pages will start to appear there as well, which could be undesirable. Here's a follow-up issue: #2431009: Make it easy to exclude content types from the "Content list" widget

The same goes for search results - showing the homepage could be confusing (because it contains a "teaser" of the content you actually want to see) and usually pointless since users have no trouble finding the homepage (whereas search is there to help users find a peice of content they're having trouble finding). This is, of course, changable in search_api, but we should provide a way to change it without causing the Feature to become overridden. Here's a follow-up issue: #2431011: Make it easy to exclude content types from search results WITHOUT overriding the Feature

Anyway, that covers my review of the existing patch and everything required to get this committed. However, I also think that @adamsro's idea would be super cool:

Would it possibly be a good idea to have an option to hide the node title of a landing page on the node edit screen (as opposed going to panelizer full-page-override content settings)? I typically want to do something more custom for a landing pages header section.

I think it'd be great to have checkbox or magic string (like "") that would update the Panelizer configuration for the current node and hide the page title.

Another cool feature would be "Make site homepage" checkbox, so users don't have to make the landing page and then navigate to the "Site information" form to make it the front page.

But I think those are "nice to have" features because it's something the current Landing Page functionality doesn't have, so it's not a regression. We can make a Feature request for it later if we don't handle it in this issue.

Anyway, to summarize: we're super close! Let's get this finished up and committed! :-)

Awesome, thanks! I haven't had a chance to do any manual review, but I sent the patches to Travis-CI for automated testing:

https://travis-ci.org/panopoly/panopoly/builds/53098488

The last test run failed because of #2447475: YouTube test fails on Chrome 41. But everything else otherwise passed!

Running through the tests again just in case:

https://travis-ci.org/panopoly/panopoly/builds/53462386

Thanks, @caschbre! All of the remaining TODO is addressed!

I made a couple minor changes to the help text, changed the renderer for the Landing Page edit variant to "standard", and cleaned up the .install file a little bit. A new patch (with an interdiff) is attached.

I'm going to run this through Travis-CI one more time (with the upgrade tests) and if it passes I think this is ready to commit!

EDIT: Here's the Travis-CI build: https://travis-ci.org/panopoly/panopoly/builds/53654324

Tested passed! Committed, finally! Huzzah! :-)

Thanks to @caschbre and @mglaman, for continuing to push this forward!

In case anyone else find this useful, I recently made a function for a client project to convert from Page Manager pages to Landing Page nodes:

https://gist.github.com/dsnopek/20dd0fec4fbc4a4e6ca8

It doesn't work in all cases - there's lots of Page Manager features that won't work on Landing Page nodes, so it just has to skip them.

If you do give it a try, try it on a testing site (with your production data) before trying it on production AND MAKE BACKUPS!

I make no guarantees that the above code will work in all cases or won't accidentally delete something that it shouldn't.