menu link shows as overridden: options identifier showing in default, not in overrides

@YesCT, I'm facing the same issue. Wonder how you fixed that.

Is this related to #927566: Add link title to menu link identifiers to make them more unique.?

This patch should fix the issue.

@MustangGB, no, it's not the same.

Same problem here, patch worked perfectly. After two+ years, ready for commit?

thanks Claudiu for this patch, great stuff.

and thanks to rclemings for the review.

and thanks to everyone else.

I don't see how this patch/commit would solve the problem described in the issue summary.
With or without the patch, I was not able to reproduce the original problem.

The main change seems to be this:

• Before this change, the identifier stored in the db in $menu_link['options']['identifier'] was updated each time a modified menu link was exported.
• After this change, the identifier stored in the db, once it exists, is no longer updated.
  However, the generated feature still contains the updated identifier.

Bugs / Misbehavior before this change

Without the commit, I did see the following misbehavior:

Steps:

• Create and export menu link. Commit the feature in git.
• Modify menu link title or path.
• Export again (drush fu -y my_ft_menu). Commit in git.
• Revert the last git commit, to restore the previous version of the feature.
• Revert the feature (drush fr -y my_ft_menu).

Expected:

• Link is restored.

Actual:

• A new link is created.
  The reason is that the stored link now has a different identifier than the exported link.

The commit fixes this misbehavior in some cases, but not all.

Bugs / Misbehavior after this change

Since the commit, I see the following misbehavior:

Steps:

• Create and export menu link. Commit the feature in git.
• Modify menu link title or path.
• Export again (drush fu -y my_ft_menu). Commit in git.
• Modify the menu link title or path, again. (different value than before)
• Export again (drush fu -y my_ft_menu). Show diff.

Expected:

• Second export does nothing.

Actual:

• Second export removes the link from the feature.

Conclusion: Revert this

This commit is not yet part of any stable release.

Given the choice between a known existing bug and a newly introduced regression, I would choose the former, as the path of least surprise.
We should revert this to minimize disruption in the upcoming release.

Future: How to do this properly?

We need to make a choice:
Should the "identifier" remain fixed, once it was created?
Or should it be updated each time the menu link data (title, path) changes?

I would say it is pointless now: Everybody who needs a proper menu links export solution should use Features Menu UUID instead.

Follow-up: #3162809: Revert change on menu_links identifier logic from #2385853