Update link templates of test entities

As its public directory you should have writable(777) permission. Also try to hit specific image file in browser what output it generates. Other way it might be issue of Varnish configuration on server.

Are we sure this is a bug? It seems perfectly logical to me that a single-bundle entity uses /foo/add, whereas a bundleable entity needs to use /foo/add/bar.

Example of a single-bundle entity: /user/add
Example of a bundleable entity: /node/add/page

P.S.: The comment in #2 makes zero sense here, posted on the wrong issue? :)

> Are we sure this is a bug? It seems perfectly logical to me that a single-bundle entity uses /foo/add, whereas a bundleable entity needs to use /foo/add/bar.

Agreed.

The code in DefaultHtmlRouteProvider::getAddFormRoute() says:

      // @todo: We have to check if a route contains a bundle in its path as
      //   test entities have inconsistent usage of "add-form" link templates.
      //   Fix it in https://www.drupal.org/node/2699959.
      if (($bundle_key = $entity_type->getKey('bundle')) && strpos($route->getPath(), '{' . $expected_parameter . '}') !== FALSE) {

so it sounds like the problem might be that some test entities have bundles, but incorrectly have an add form path without a bundle placeholder.

So I guess the next step is to remove the logic in DefaultHtmlRouteProvider::getAddFormRoute() and see if tests still pass. If any test entities fail, see what's wrong with their link templates.

Removing the route param check and run the tests here

This came up as a daily triage target for the Bug Smash Initiative.

We discussed this and agreed with #3 and #9 that this should not be bug. Cleaning up the test entities should probably be a task, so moving it to that.

With the addition of bundle classes in 9.3, it looks like this might no longer be limited to tests. I've got a couple of bundle classes that extend from a content entity (created by drush generate), and trying to get to my_type/add/bundle_id with them gets a 404. However, when I add a content type for my content entity the old way, in the UI, the same path gets the Add page.

The add-form link generated for my content type is
"add-form" = "/my-content/add/{my_content_type}"

Going through things with a debugger, an Add request for one of my bundle classes never gets to EntityForm::getEntityFromRouteMatch(). So bundle classes are not being handled in the same way as traditional content types.

Do a search for entity_test/add' and 'entity_test_mulrevpub/add' believe all instances have been found.

There was a test failure. I rebased and updated another link.

Additional link change seems fine.

The changes to the link templates here look good, but I'm concerned about the impact on contrib modules that are using these entity types for their tests. This can be seen by the large number of changes in the MR to add the additional type to the URL.

Can we try to revert all of those changes, and as well as fixing the add-form template, add an add-page template (using the original URL).

For instances where there's only one bundle, that will wire up \Drupal\Core\Entity\Controller\EntityController::addPage which handily redirects to the add-form template when there is only one bundle. For the vast majority of tests, there will only be one bundle because of the default value in \entity_test_entity_bundle_info

We can then assess how many tests are still broken, but I suspect it will be dramatically less. That will give us confidence that this change won't break as many contrib tests as the current approach most likely will.

@larowlan, thanks.

Made changes asked for in #35.

Awesome, passes 🎉

Feedback appears to be addressed here

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Rebase with many conflicts due to #3396166: Convert entity type discovery to PHP attributes

Rebase seems good.

Updated credits.

There's one here still using annotations that I think should be attributes?

It would be out of scope for this issue to convert an entity from annotations to attributes. That entity was added in #3310170: Use UUID as entity ID and there is a comment there suggesting that the conversion could be done as part of deprecating annotations, [#33101701-50]. That seems reasonable for a test entity.

Yes you're correct, sorry for missing that was already using annotations rather than it being added here

Committed to 11.x
As we're in RC phase for 11.1 I think this doesn't meet the requirements for backport.

Thanks all 🏆️