Errors on non-interactive install with drush site-install

This 'breaks' Panopoly installation also in Aegir. While it seems to be mostly cosmetic problem, because the site is installed, the task is marked as broken because there are these errors reported.

Hrm. I install via Aegir but not the latest version. However, if it's breaking newer Aegir's then this is important! Adding to the sprint board - we can try and tackle this at the July 11th sprint.

While I'm not sure if this makes any difference, the BOA specific Aegir setup is based on Drush 7.0-rc2, Provision 3.x and Hostmaster 2.x

Just adding in that we are finding watchdog completely swamped with these log messages: 10 pages of entries within a couple of hours:

Menu block ctools-main-menu-1 is set to use parent menu link main-menu:main-menu:0 but the menu link was not loadable or does not exist.

This is on latest Panopoly distro through Pantheon, nothing weirdly patched and no Aegir to blame. All Panopoly_* modules are ON except for Magic and Example Content.

So, I did a little more testing. I think this is either (a) a menu_block bug or (b) a problem in our Panelizer default for "Content Page", because I see the warning appearing in watchdog everytime I visit an "Content Page". It's probably importing the data in panopoly_demo that's making it appear during install.

Here are two patches: one for panopoly_pages, and a corresponding one for panopoly_test. Let me know if it's better to somehow combine them into one?

If you use the menu_block configuration form to select a parent menu item, then the select list value is in the form [menu-name:menu-link-id], such as main-menu:1123. If you select a top-level menu item that has no menu link ID, then the select list value is in the form [menu-name:0].

Either way, in the submit function menu_block_menu_tree_content_type_edit_form_submit(), the select list value is exploded on the colon, and only the mlid integer is stored as the parent_mlid. But in the panopoly_pages Feature, the parent_mlid was being stored as the full string main-menu:0, which the function menu_tree_block_data() will reject and log the reported messages.

So I updated the Feature and the test to store only the mlid integer (0) part of the link.

@jfrederick is my hero! :-)

Doing two patches like this is perfect. You even named them correctly for our script that runs patches on Travis to pick them up! And here is the Travis build:

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

It'll do the install relatively early on in the process.

However, these changes worked for me locally when viewing a "Content Page" that wasn't customized per-node. Unfortunately, if the user customized the page, the menu block settings will be saved in the database, so the error will keep happening. Which means this'll need a hook_update_N(). :-/

We've done update functions that changes the settings for every instance of a particular type of pane before, for example, panopoly_widgets_update_7012(). Using that as an example, this should be relatively easy to write.

Anyway, thanks again for figuring this out!

Here's a new panopoly_pages patch with an update hook! It works in my limited testing locally, but I'd love some additional review/testing.

We don't need to worry about an update hook for panopoly_test, because it's just used for running the automated tests - there will be no real user data using those content types.

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

The patch in #12 worked in my testing!

Thanks! Committed. :-)