@xtech86 The is a known issue that should be fixed with 3.7 please try the last Nightly of 3.7 from here: https://developer.joomla.org/nightly-builds.html

and enable the modern and remove id option for com_content. (you can find that in the options of com_content)

Thanks @zero-24, I'm already testing 3.7 out :-) Just couldn't see anything relating to J3.6 when searching previous issues.

--Update--
However, tests with J3.7 are not great, they still resolve them all to the homepage and should instead produce a 404.

To be sure did you enable the option in com_content to use modern routing and remove the ID?

However, tests with J3.7 are not great, they still resolve them all to the homepage and should instead produce a 404.

That sounds like an issue with either htaccess or the template - please test with the defaults

@zero-24 yes exactly

@brianteeman I'm afraid not, disabling the new router indeed returns a Joomla! 404 as per normal.

@zero-24 @brianteeman Issue is present on my install tested again just now. See below video:

https://www.dropbox.com/s/4by0jqu9qcm1rat/Joomla%213.7_sef_error.mov?dl=0

@hackwar can you take a look here?

There is no code in the new router right now, that throws a 404 for such URLs. Throwing a 404 is not as easy as it sounds, since you would have to decide when a 404 should be thrown and where. Should we throw it in the component router? But what about plugins that process the URL after the component router? Should we throw it in the application router, right at the end? (You could write a small plugin that adds its own router rule and does that) should it throw a 404 only when there are path elements left or when there are unknown query elements? The later is another issue, since there is no way for us to know which query elements would be valid or not.

@Hackwar But then you are at square one in terms of the original issue I was having. You are still forcing the user to 1 page and not changing the URL. Thus this becomes an SEO nightmare again, since you will be having duplicate content on multiple pages as far as Search Engines are concerned, only this is much worse since you are saying the homepage exists for all these urls.

If we can route to the homepage, surely we can issue a 404?

I'm not familiar with the code structure of the SEF router, but I think this needs to be addressed.

We are not routing to the homepage. We are falling back on the default menu item (=homepage). As I wrote, you can easily create a plugin that implements the behavior that you are looking for, but since we need to be backwards compatible, we simply can not role that out to all sites out there. Developers write crap and such a change would break lots and lots of sites. The code would look something like this:

class plgSystemThrow404 extends JPlugin
{
    public function onAfterInitialise()
    {
        $app = JFactory::getApplication();
        if (!$app->isSite()) return;
        $app->getRouter()->attachParseRule(array($this, 'throw404'), JRouter::PROCESS_AFTER);
    }

    public function throw404(&$router, &$uri)
    {
        if ($uri->getPath() != '' && $uri->getPath() != 'index.php')
        {
            throw new Exception(404, 'Not found');
        }
    }
}

This is just from the top of my head and not tested.

Thanks @Hackwar I fully appreciate that. But with such a version jump to me it seems crazy to still allow the new structure which needs to be switched on anyways. If it falls back to the homepage I don't understand why we can't fallback to a 404 instead?

The routing works kinda like this:
1. Take the default menu item and set it as the current request
2. Run the URL through the different steps and whenever we parse a date from the URL, we store it in the current request, overwriting the data from the default menu item one by one.

Now, proper routing code would parse something from the path-part of the URL and remove it and add the parsed data as query elements, but as I wrote, developers are stupid, lots and lots and lots of people don't do that and thus in the end we might have a perfectly valid URL still with a populated path. If we throw a 404 now, you are preventing people from reaching those parts of your site. It is simply something that has to be done on a per-site-basis.

Since the discussion seems to have walked its course and the solution has been stated here and in other issues, can we close this one?

@zero-24 this can probably be closed as we have another bigger Issue regarding the inability of the new router to create a 404