Any Menu Path currently stores the affected mlids in a Drupal variable. This can be exported with Features, but the mlids won't necessarily match on the target site. This has the unfortunate effect of causing exported menu links to flat-out not show up on target sites.

I propose that we store menu items that are affected by Any Menu Path the same way that Features exports menu items so that these two things match up regardless of the site (a sort of pseudo-machine name).

One thing I'm unsure of is what happens if two identical menu items are exported with Features. Will the identifier be the same for both? I assume not, but I'll test this. I think this solution will work well enough for now. (Update: Features can't export two identical menu links. That is not our problem, but since that's how it's working, that is what I'll code against; we don't have to worry about multiple items with the same title AND path right now.)

Ultimately, we should implement CTools exportables, use a database table, and implement something like hook_features_pipe_alter to automatically include relevant Any Menu Path configurations when menu items are going to be exported (and vice-versa).

But that is not the goal of my patch here.

CommentFileSizeAuthor
#3 any_menu_path_2283991_features_3.patch10.36 KBwizonesolutions

Comments

wizonesolutions’s picture

wizonesolutions
he/him
Primary language English
Location Norway
commented

OK, I know why menu items sometimes disappear.

When Features tries to save the link to the database, it's changing external back to 0 — even if it's exported as 1. In that case, reverting fails. I'm assuming there's a validation check that is failing and that we need to hook into.

They are not really gone; changing external to 1 in the menu_links table works around the problem. This will need to be part of our update hook.

Coming back to this tomorrow.

wizonesolutions’s picture

wizonesolutions
he/him
Primary language English
Location Norway
commented
Issue summary: View changes
wizonesolutions’s picture

wizonesolutions
he/him
Primary language English
Location Norway
commented
Status: Active » Needs review
StatusFileSize
new any_menu_path_2283991_features_3.patch10.36 KB

Alright! I figured out a decent approach for this.

  • I haven't messed with how most of the code works. Instead, I've simply created wrapper functions for loading and saving Any Menu Path menus.
  • The save function converts them into Features-friendly identifiers if Features is on and new enough.
  • The load function does the opposite.
  • Nothing's new if Features is not enabled.
  • When Features is enabled/disabled, the variable is updated automatically (exception: a bug in Drush might cause this not to happen, see https://github.com/drush-ops/drush/issues/681). To make sure the module works correctly even then, I convert any identifiers back to mlids when the load function is called.
  • When the module is disabled/enabled, it will fix the variable if necessary (in case the state of Features changed while it was off and its hooks weren't running).

Going to test it some more, but here is the patch.