Fatal error with unclean edit path

Makes sense to me. Benedikt?

Hm, we could use the provided patch for a quick fix, but I'm wondering whether there's actually something else going wrong... as far as I can see $edit_item (hence also $original_item) is always set in the following lines of code:

         do {
            $edit_item = &$items[implode('/', $edit_path_parts)];
            array_pop($edit_path_parts);
          }
          while (!empty($edit_item['type']) && $edit_item['type'] == MENU_DEFAULT_LOCAL_TASK);

The only case I see where this wouldn't be the case is if the respective menu item for the edit path doesn't exist. IMO that is something that should be taken care of during _entity_translation_validate_path_schemes()...

@miro_dietiker: I'm curious about the path/menu-item causing the error... could you try to find out the runtime values of $scheme, $edit_path_parts, and possibly $items for the item causing problems?

Is this related to #1818500: different edit path than entity module?

If that missing "path wildcard" is the issue i don't see why entity_translation tries to query for "%sharemessage".

Well, that's just the default value; we need something to work with, so if you don't specify it then we try to guess it; core uses wildcards like %node or %user, so we use %[entity-type] as the default pattern.

So does adding a path wildcard solve this issue?

If yes, attached patch should help with avoiding the fatal error.

Setting NR.

I've been able to reproduce this, but #7 does not seem to fix the issue. To see the fatal just change the taxonomy base path from taxonomy/term/%taxonomy_term to taxonomy/term/%term. I think it's correct that this path passes validation because it's compatible with the actual one. The % replacement was introduced exactly to handle situations where the menu loader has been replaced but the router path structure remains the same. For instance when Views takes over the taxonomy/term/% path. We should make sure this works again as it's a regression wrt alpha2, I think.

tagging

I tried this with Views replacing taxonomy listings + a bougs base path ('taxonomy/term/%term') and things didn't break, except that the menu loader didn't exist and yielded to another fatal, but that's the expected behavior.

I'm still not quite sure what the views-taxonomy thing actually means; I'll try to reproduce and confirm the patch now.

Also, it's a slightly different issue, but I'm still thinking that the stricter path wildcard validation (patch #5) also makes sense, because we need the path wildcard in the path in order to be able to determine the position of the entity id (we have code like $entity_position = array_search($wildcard, $path)).

Actually Views doesn't break because it replaces only the base/view path, but if it replaced also the edit path we would have the same fatal reprted in the OP.

Actually this is not a regression since replacing taxonomy listings with Views is still working. I'd like to release beta1 with this one fixed, but I won't consider this a blocker.

Any news here?

Here's a new patch based on the previous two.

I added the code from patch #7, because the way hook_menu_alter() is written at the moment, the existence of a matching wildcard is definitely required -- if we want to change that, we also need to adjust respective bits in hook_menu_alter().

+++ b/entity_translation.module
@@ -412,8 +419,8 @@ function entity_translation_menu_alter(&$items) {
+          $edit_path = $scheme['real edit path'];

I changed this back to 'edit path'. Mainly for consistency as we use the "non real" path for the other menu items as well; if there's a reason to use the real one instead we should probably document it and add some tests.

I also moved a few things around in the validation function in an attempt to make it easier to read through and understand (and to remove some duplicate code); added some comments as well.

Attached patch should still solve the issue of the OP, and also keep things working with the views-taxonomy listing.

Thanks!

@miro_dietiker:

Can you confirm the issue is fixed?

The bug is still there :(

I applied the patch, renamed the taxonomy base path from taxonomy/term/%taxonomy_term to taxonomy/term/%term and cleared the caches. Boom.

Hm, there was a typo in a variable name. Also cleaned up some whitespace.

Looks good, fixes the issue and works with Views replacing taxonomy listings!

Committed and pushed, thanks!

Er, wrong issue?

Posted #22-#23 in #1672710-28: published source node appears as not published in the translate tab. Back to fixed.