4.7.2 breaks all URL paths that parse to a number, like /2012/ for example.
Hello!
We just upgraded one of our 4.7.1.1 sites to 4.7.2 and have found a new "feature" with this version that has had quite an unfortunate, breaking side-effect!
It seems when you surf to any path that looks like an integer, Umbraco will actually serve you the node with that ID, not the actual node with that name (and/or umbracoUrlName)!!
For example: the page formerly located at www.example.com/2012/ is no longer accessible in Umbraco 4.7.2. Instead, we get a 404 error (presumably because there is not a node with ID #2012!) Please note that this page & path used to work just fine in 4.7.1.1.
This is a breaking change for us. Renaming the page from /2012/ to /two-thousand-twelve/ is the only solution at this point. Is there a config somewhere where we can turn off this new "feature" ??
It is also interesting to note that in 4.7.2, you can now surf to any of the published documents in your site simply by adding the ID to the end of your hostname.
etc... pulls up different pages by their NodeID. I am guessing this is what this new "feature" was intended for, but in our case, it is overriding our intentions!
It's been possible to access the nodes by writing the id in the url instead of the nodename for a very long time. When using the preview function for instance it's the node id that is being fetched instead of the nodename. So that's not someting new.
However the added # you write about in your first post could possible be a bug - I'll try to make a test tomorrow to see if I can reproduce the same issues as the one you describe above.
Untill then how about try changing this line in the //config/umbracoSettings.config file from true to false: <addTrailingSlash>true</addTrailingSlash>
This will remove the trailing slash from the url - does this help? (Remember to recycle the app pool after you have made the change).
Thank you for the reply. I tried your suggestion of setting addTrailingSlash to false (and recycled app), however the paths /2012/ and /2012 still continue to produce 404 errors.
And I did forget to mention, although you figured this out already, that we are indeed using "extensionless" URLs (on IIS 7.5 Integrated Pipeline).
P.S., since I was curious about this feature "always existing" and always surprised to keep learning new things like this about 4.7.x, I tried on another similar site we still have on 4.7.1.1 (also on IIS 7.5 integrated mode) and confirmed that this trick you mention only works when you append just the ID without a trailing slash, but it does NOT work if you do include the trailing slash. This is probably why all of our links to /2012/ have been working all along, never realizing that /2012 (without slash) never did. Interesting.
Thank you for your time, and I hope this is helpful in tracking down what may have caused this change.
Yes, it certainly would be nice to be able to customize the pattern of the path used for previewing nodes, so if there really were a NodeID #2012, we could preview it with something like /umbracoPreviewNode.aspx?id=2012 or somesuch. (Assuming that something like "umbracoPreviewNode" would be much less likely to occur in nature than "2012".)
I'm not experiencing this problem at all on my site i.e. I can browse to /2012 & /2012/ OK. I'm using directory URLs - other than that it is a standard 4.7.2 install. The only difference I can see is that my year folder is not at the root (The URL is /articles/2012). Or perhaps you have a co-incidence where you have a page with ID 2012. In which case could you delete and create another with a different ID as a hack?
The problem as described only pertains to numeric node names in the root of the site. The problem occurs with any number, not just those that happen to match an actual NodeID.
Jan mentioned above the problem is because the preview functionality is conflicting with this as a path. So ... /articles/2012/ is fine, since this doesn't conflict with preview node. But /2012/ (or any number here) does indeed not work.
The problem is the request pipeline of umbraco it starts by checking if it can parse the url to a int if it can that then it redirects u to that node id (comment from code: // If url is an integer, then asume it's the ID of the page )
i have fixed it so it will check for a umbraco path before asuming it is the nodeid. i am creating a fork as i write and will update this thread with info. So now u can have a node with name of 2012 and preview should still working (with nodeid.aspx)
If u cant wait then upgrade to 4.9.1 and drop me a mail and ill send u the kernels needed.
Talking of this 'feature' existing for some time, am I the only one concerned over clients calling with a "broken site" because they actually *want* to publish pages with numeric-only URLs? An extremely legitimate case. Fortunately this isn't something I've experienced.... yet; given enough time (and with this original post as testament) it will come and bite us on the bottom!
You can all shout "convenience!" and keep your implicit side-effect stuff, while I keep yelling "explicit!"
However much I grow fond of Umbraco I'm always purplexed every so often by some little gem of oversight (or blatant disregard).
4.7.2 breaks all URL paths that parse to a number, like /2012/ for example.
Hello!
We just upgraded one of our 4.7.1.1 sites to 4.7.2 and have found a new "feature" with this version that has had quite an unfortunate, breaking side-effect!
It seems when you surf to any path that looks like an integer, Umbraco will actually serve you the node with that ID, not the actual node with that name (and/or umbracoUrlName)!!
For example: the page formerly located at www.example.com/2012/ is no longer accessible in Umbraco 4.7.2. Instead, we get a 404 error (presumably because there is not a node with ID #2012!) Please note that this page & path used to work just fine in 4.7.1.1.
This is a breaking change for us. Renaming the page from /2012/ to /two-thousand-twelve/ is the only solution at this point. Is there a config somewhere where we can turn off this new "feature" ??
Thank you!
It is also interesting to note that in 4.7.2, you can now surf to any of the published documents in your site simply by adding the ID to the end of your hostname.
For example:
www.example.com/1012/
www.example.com/1013/
www.example.com/1014/
www.example.com/1015/
etc... pulls up different pages by their NodeID. I am guessing this is what this new "feature" was intended for, but in our case, it is overriding our intentions!
Hi Funka
It's been possible to access the nodes by writing the id in the url instead of the nodename for a very long time. When using the preview function for instance it's the node id that is being fetched instead of the nodename. So that's not someting new.
However the added # you write about in your first post could possible be a bug - I'll try to make a test tomorrow to see if I can reproduce the same issues as the one you describe above.
Untill then how about try changing this line in the //config/umbracoSettings.config file from true to false: <addTrailingSlash>true</addTrailingSlash>
This will remove the trailing slash from the url - does this help? (Remember to recycle the app pool after you have made the change).
/Jan
Hi Jan,
Thank you for the reply. I tried your suggestion of setting addTrailingSlash to false (and recycled app), however the paths /2012/ and /2012 still continue to produce 404 errors.
And I did forget to mention, although you figured this out already, that we are indeed using "extensionless" URLs (on IIS 7.5 Integrated Pipeline).
P.S., since I was curious about this feature "always existing" and always surprised to keep learning new things like this about 4.7.x, I tried on another similar site we still have on 4.7.1.1 (also on IIS 7.5 integrated mode) and confirmed that this trick you mention only works when you append just the ID without a trailing slash, but it does NOT work if you do include the trailing slash. This is probably why all of our links to /2012/ have been working all along, never realizing that /2012 (without slash) never did. Interesting.
Thank you for your time, and I hope this is helpful in tracking down what may have caused this change.
Is this being fixed? I'm working on porting over a v.5 project back to v.4 and got stuck on this :(
Yes, it certainly would be nice to be able to customize the pattern of the path used for previewing nodes, so if there really were a NodeID #2012, we could preview it with something like /umbracoPreviewNode.aspx?id=2012 or somesuch. (Assuming that something like "umbracoPreviewNode" would be much less likely to occur in nature than "2012".)
Thank you!
Yes! I'm going to have a mental breakdown if i have to downgrade even more :(.
I'm not experiencing this problem at all on my site i.e. I can browse to /2012 & /2012/ OK. I'm using directory URLs - other than that it is a standard 4.7.2 install. The only difference I can see is that my year folder is not at the root (The URL is /articles/2012). Or perhaps you have a co-incidence where you have a page with ID 2012. In which case could you delete and create another with a different ID as a hack?
Paul,
The problem as described only pertains to numeric node names in the root of the site. The problem occurs with any number, not just those that happen to match an actual NodeID.
Jan mentioned above the problem is because the preview functionality is conflicting with this as a path. So ... /articles/2012/ is fine, since this doesn't conflict with preview node. But /2012/ (or any number here) does indeed not work.
Thank you!
Does anyone know a quick fix to this?
Like Johan, I'm downgrading my v5 website and stucked with this.
Even if its a ugly fix, it's welcome!
Thanks!
Is this fixed in 4.8? If not, should i report it as a bug on codeplex (or http://issues.umbraco.org?)?
It's not fixed in 4.8. Just tested for you (though not on clean install).
Thanks Thom! I wrote an issue over at codeplex. http://umbraco.codeplex.com/workitem/30968
And the issue is now moved from codeplex to the issue tracker http://issues.umbraco.org/issue/U4-634
The problem is the request pipeline of umbraco it starts by checking if it can parse the url to a int if it can that then it redirects u to that node id (comment from code: // If url is an integer, then asume it's the ID of the page )
i have fixed it so it will check for a umbraco path before asuming it is the nodeid. i am creating a fork as i write and will update this thread with info. So now u can have a node with name of 2012 and preview should still working (with nodeid.aspx)
If u cant wait then upgrade to 4.9.1 and drop me a mail and ill send u the kernels needed.
Talking of this 'feature' existing for some time, am I the only one concerned over clients calling with a "broken site" because they actually *want* to publish pages with numeric-only URLs? An extremely legitimate case. Fortunately this isn't something I've experienced.... yet; given enough time (and with this original post as testament) it will come and bite us on the bottom!
You can all shout "convenience!" and keep your implicit side-effect stuff, while I keep yelling "explicit!"
However much I grow fond of Umbraco I'm always purplexed every so often by some little gem of oversight (or blatant disregard).
is working on a reply...