Duplicate content on /article/{whatever}

This is just how Drupal core works. Even without Sub-pathauto and only core installed you'd get the same behavior with node/1/doesnt-exist and node/1/pizza.

Hi,

When I tried the URL as node/1/doesntexist and node/1/pizza both are showing same node/1 content.

After that I changed node/1 path as mypage, then I tried mypage/doesntexist and mypage/pizza now it is showing page not found error.

After that I installed subpathauto module and selected 2 in "Maximum depth of sub-paths to alias". Now I found that

1) mypage/doesntexist // It is showing same content as "mypage" (which is wrong)
2) mypage/doesntexist/doesntexist1 // This one also shows same content as "mypage" (which is wrong)
3) mypage/doesntexist/doesntexist1/doesntexist2 // But here I can see page not found error (which is correct).

How to resolve this?

The depth means searching backwards from the end of the URL. Given the URL 'mypage/doesntexist/doesntexist1', the first depth is 'mypage/doesntexist' and the second depth is 'mypage' which resolves to your content as expected. This is why 'mypage/doesntexist/doesntexist1/doesntexist2 doesn't work because this would require a depth of three levels in subpathauto to work.

How I can disable this behavior?

subscribing

https://api.drupal.org/api/drupal/modules!system!system.api.php/function...

The link above may help, if you want to do some path checking.

Related to Drupal Core Issue #432384: Any non-existent URL containing a valid parent path returns 200, not 404

So, this isn't a good solution, but it is a partial solution…

Set the variable subpathauto_depth to 0. Either:
* drush vset subpathauto_depth 0
* Goto /admin/config/search/path/subpaths set "MAXIMUM DEPTH OF SUB-PATHS TO ALIAS" to 0.

Let's say you want to have a photos sub-page on your node "Cats are awesome" with associated "Galleries", one of which is "Cute cats of the week".

So, perhaps your configuration is /cats-are-awesome/galleries/cute-cats-of-the-week, but we really don't want /cats-are-awesome/galleries/fake-gallery to work. Dropping that depth will kill fake-gallery from working. Unfortunately, it doesn't fix /node/555/galleries/fake-gallery which piggies back on ugly core routing. IMHO: Add Disallow: /node/ to your robots.txt, and probably /content if SEO URLs are important to you.

Unfortunately, this is leading to other bugs on the site I'm working on, where some other devs are relying on this functionality. I'm investigating those issues, but in the mean time, I've something to share with the community.

I was also experiencing this problem. I've attached a patch with a solution that fixed it for us. I get that this is core behavior and probably not technically a problem with this module, but I didn't see a decent core patch and the SEO gods couldn't overlook it. Obviously your call on if it belongs in the module, but hopefully it'll at least help others in the same position.

Thanks for the module, Dave!

@guschilds thanks for that patch that's helpful. I've run up against a similar request from the SEO powers that be and your patch looks like it'll do the trick. Any known issues? How does it handle menu items with page callback functions that expect to be given the "extra" path parts at the end of the path as arguments?

Hey m4olivei,

Glad it helped! We haven't run into any issues since we began using the patch a few weeks ago.

I just tested menu items with wildcard arguments, such as node/%node/%, and it does not break those. This is because the patch compares $source to $item['href'], which'll both be something like node/1234/kittens. If the node/%node/% callback didn't exist, visiting node-1234-alias/kittens would result in a $source of node/1234/kittens, but $item['href'] would only be node/1234. That is why this patch works in general. Hope that made sense and helps!

This is so similar to a hook that I implemented to fix the same issue for our site that I will try the patch out to see if it works for us. I'll try out patch #12 with a list of issues I had to work through and report back when I'm done.

YAY! This fixes the issues that I ran into while implementing a hook. Since I would rather use a community supported patch, I think I'll pick this one up and run it through our QA for further test. Thanks!

Great, srclarkx! Let us know how it goes with QA and if all is well, maybe this can get moved to RTBC.

I'm testing the patch, and finding one odd issue. We have a view with a custom access plugin that isn't returning the right result with this patch. It has to do with the added call to menu_get_item. If a function in that call stack makes reference to $_GET['q'] either directly or indirectly through the use of arg() it ends up evaluating based on the aliased path coming in rather than the system path subpathauto eventually figures out, which is what we want.

I recognize it's an edge case and probably not a good idea to use $_GET['q'] or arg() in an access callback, but such as it is. More to the point, the aforementioned access plugin cached it's result, and since it was called early, before $_GET['q'] was settled, it threw the whole page out of wack. The fix was to not cache that result.

Anyway, having said all that, the patch is still looking good. Just beware of any access callback that bases logic on $_GET['q'] and is depending on subpathauto finishing it's work, b/c this patch will call earlier than expected.

The patch made it past QA and has been deployed. We saw one case where extra characters weren't caught at the end of a path. I haven't investigated. We went ahead and used the patch because it was an improvement from what we had.

Also successful report from our end, we've had this patch deployed for about 2 and a half weeks and all is well so far.

Thanks for reporting, srclarkx and m4olivei. We've also been using it for a month and our QA team hasn't found any issues. Going to mark it as RTBC.

Patch from #12 works for me too.

Patch #12 solved the problem. Thanks.