Move contact module footer link to standard install profile

<3

Lets try with this.

do we need an empty hook_post_update_n for clearing cache.
RTBC +1

Well, this is for new installs right?

#4 nope we don't need anything here. Should we add a quick test about this?

Actually there is already a test for that here: http://cgit.drupalcode.org/drupal/tree/core/profiles/standard/src/Tests/...

#6 Okay
looks good to be in.

I agree way more stuff should be in standard and not in modules. However given we're changing default behaviour it is perfectly possible that an install profile is relying on this behaviour. So at the very least we need a change record and a discussion of why this should be allowed in minor release.

Change record and explanation here: https://www.drupal.org/node/2714035

Moving back to RTBC per #6 and #9 (#9 requested for a change record that was provided on #11).

Presence or not of specific config entities shouldn't be considered part of the public API, so I think the change record is plenty here, but moving back to @alexpott

I agree with the move but the issue summary says

It has no right to do so, and means you cannot disable it later without killing the footer menu.

If I add a link to the footer and uninstall contact no menus are killed but the contact link is removed. If there is no other link then yes the menu disappears - but that is becuase it is empty - you can still add new links to it.

Committed 36a23b3 and pushed to 8.2.x. Thanks!

I've got a fatal after pulling 8.2.x today: Symfony\Component\Routing\Exception\RouteNotFoundException: Route "contact.site_page" does not exist.

It looks like Standard profile now has a de-facto dependency on Contact module. I had uninstalled it prior to pulling HEAD, but it also breaks if you uninstall Contact on a clean installation of Standard.

Verified this on a clean simplytest.me with 8.2.x, standard profile, uninstalling Contact first thing after.

Can confirm with @Les Lim that this does break core when the contact module is uninstalled.

Needs revert first and then some work and maybe some more tests.

better title hack?

Since this caused a regression and most of the other committers are not available right now I reverted this. This wasn't a broken head I don't think but was a regression. Could use some tests but is already tagged with that :)

+1 for the revert. Install profile dependencies that aren't really dependencies are really fun!

I think we should add an explicit dependency from standard to contact.

I'd rather not - there are plenty of sites that don't need a contact form or would prefer to implement a different solution.

You can't have "explicit" dependencies on modules as an install profile. It already depends on contact, but that doesn't mean that you can't remove it, which you definitely should be able to.

The correct fix is to create those menu links (all of them in that file really) as content menu links, so that users can remove them if they want to.

As mentioned above, this needs to be created as a content link, like the shortcuts in standard_install().

Do we still have this problem?
I didn't have any problem to disable the contact footer link in the Footer menu like @larowlan said in comment #24.

Is a problem that the

contact.site_page:
  title: Contact
  route_name: contact.site_page
  menu_name: footer
  enabled: 0

is adding a link to the footer menu in the standard installation?

As discussed in Bug Smash Initiative, I did some tests and didn't find any problem to disable the link as issue summary describes.

Please provide steps to reproduce. For a while I set the issue to Postponed.

I'm not sure about the not disable part, but there's still

> It belongs in the standard profile (product feature, not framework feature).

Which I agree with. This can be an annoyance for distributions that don't want that or want it somewhere else.

A patch for it.

Test fails make sense, these tests use standard so they now have an extra menu link that we have to expect.

It looks like contact module does not have test coverage for that footer link though, so nothing failed, unfortunately. Sounds like we should test that in \Drupal\Tests\standard\Functional\StandardTest.

Also, another complication, contact_help() talks about the menu link, which now is only part of the standard install profile. Not sure what to do about that.

@Berdir @paulocs
Adding test case in the standard installation profile to check whether link is present or not.

For the contact module help text update:
Does it make sense if we add a description about creating links manually if required?

Needs a reroll.

Also the change record needs updating. It's currently recommending the solution that caused us to revert.

I am working on it and provide an updated patch soon.

Looks good to me.

We still need to update the change record.

Hello, I made the change. Someone can verify that I did the correct.

@ilgnerfagundes the Cr should mention that any install profile that wants to place a contact link somewhere will need to do something like

+  // Create contact footer link.
+  $contact_link = MenuLinkContent::create([
+    'id' => 'contact',
+    'title' => t('Contact'),
+    'link' => ['uri' => 'route:contact.site_page'],
+    'menu_name' => 'footer',
+  ]);
+  $contact_link->save();

in it's hook_install() - ie. what standard does.

However this does beg the question of whether we should be making this change like this. Here are some concerns:

• If you install standard, view the front page -> there's a contact link, apply this patch, rebuild cache, view front page -> it's not there
• Any other install profile / distribution that's relying on this link will need to make the same change

I think we need to go back to the drawing board and come up with a solution that doesn't regress existing sites and code that might be relying on this. I think we need to add a hook_modules_installed implementation to the contact module. If (the menu_link_content module is being installed or the contact module is being installed and the menu_link_content module is already installed) AND we're running during a Drupal installation then we should create the menu link. We also need to provide an upgrade path for existing sites. Here we have have to determine if the footer menu exists and if menu_link_content is installed and do different things depending on the outcome. Another complexity is that we need to determine what to do with any existing menu link overrides for the contact menu link.

Cross-referencing #3219959: Update standard profile so Olivero is the default theme, looks like olivero does not have a footer menu, so this link is then not actually showing up anymore by default.

It needs more work as making the link as content is not enough, if user will uninstall contact module the menu where link is added will fail to edit, see #3324291: Menu link created by modules are not deleted on module uninstall