Umbraco 4.11 breaks 301 UrlTracker - no file extensions are logged as NotFound
Umbraco 4.11 cuts the file extension of requests when logging NotFound errors into the log table. This seems to be the reason for the 301UrlTracker to fail resolving URLs previously defined, or even newly generated redirects when renaming web pages.
We have done an upgrade to 4.11. Everything works fine, except UrlTracker. Umbraco drops the .aspx file extension from requests, and as the 301UrlTracker needs exactly the URLs defined, it fails to match the request against redirect definitions.
Can this new feature be turned off???
I have done some investigation and found the right request information (with .aspx) in the IIS log. The umbracoLog table displays the wrong URL (without .aspx).
When I rename an existing document, an invalid redirect URL is generated (expects .aspx, but does never get this file extension through Umbraco).
I'm affraid it's related to this bug whic is fixed in 6.0 http://issues.umbraco.org/issue/U4-1411 . I don't think it's fixed in the 4.x codebase also. Maybe you can re-open the issue for the 4,x codebase?
thank you for confirmation of this behaviour. I thought it might have been caused by a non-perfect upgrade to the newest version of U4.
I have created a work-around for this behaviour, which works with manually entered redirects, as well as with automatically created redirects caused by a node rename.
Solution:
-- ================================================
-- Insert Trigger for infocaster301
--
-- This trigger fixes Umbraco behavior of
-- version 4.10 and newer - where file extensions
-- are stripped from the request, also .aspx
--
-- For every .aspx link, another link without
-- .aspx extension is generated
-- ================================================
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
-- =============================================
-- Author: isiCore GmbH, Maxemilian Hilbrand
-- Support: [email protected]
-- Website: http://www.isicore.de
-- Create date: 15.01.2013
-- Description: Workaround for Umbraco cut of file extensions on aspx files
-- =============================================
CREATE TRIGGER [dbo].infocaster301Duplicate
ON [dbo].[infocaster301]
AFTER INSERT
AS
BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON;
DECLARE @NodeId int, @OldUrl nvarchar(400),
@IsCustom [bit], @IsRegex bit,
@Message nvarchar(400), @Inserted datetime;
DECLARE NewURLs CURSOR FOR SELECT * FROM INSERTED;
OPEN NewURLs
FETCH NEXT FROM NewURLs INTO @NodeId, @OldUrl, @IsCustom, @IsRegex, @Message, @Inserted
WHILE @@FETCH_STATUS = 0
BEGIN
IF(@OldUrl like '%.aspx')
BEGIN
DECLARE @ReplacementUrl nvarchar(400);
SET @ReplacementUrl = SUBSTRING(@OldUrl, 1, LEN(@OldUrl) - 5);
IF NOT EXISTS(SELECT * FROM infocaster301 where OldUrl like @ReplacementUrl)
INSERT INTO infocaster301([NodeId], [OldUrl], [IsCustom], [IsRegex], [Message], [Inserted])
VALUES(@NodeId, @ReplacementUrl, @IsCustom, @IsRegex, @Message, @Inserted);
END
FETCH NEXT FROM NewURLs INTO @NodeId, @OldUrl, @IsCustom, @IsRegex, @Message, @Inserted;
END
CLOSE NewURLs
DEALLOCATE NewURLs
END
GO
Umbraco 4.11 breaks 301 UrlTracker - no file extensions are logged as NotFound
Umbraco 4.11 cuts the file extension of requests when logging NotFound errors into the log table. This seems to be the reason for the 301UrlTracker to fail resolving URLs previously defined, or even newly generated redirects when renaming web pages.
We have done an upgrade to 4.11. Everything works fine, except UrlTracker. Umbraco drops the .aspx file extension from requests, and as the 301UrlTracker needs exactly the URLs defined, it fails to match the request against redirect definitions.
Can this new feature be turned off???
I have done some investigation and found the right request information (with .aspx) in the IIS log. The umbracoLog table displays the wrong URL (without .aspx).
When I rename an existing document, an invalid redirect URL is generated (expects .aspx, but does never get this file extension through Umbraco).
Any ideas?
I'm affraid it's related to this bug whic is fixed in 6.0 http://issues.umbraco.org/issue/U4-1411 . I don't think it's fixed in the 4.x codebase also. Maybe you can re-open the issue for the 4,x codebase?
Cheers,
Richard
Richard
thank you for confirmation of this behaviour. I thought it might have been caused by a non-perfect upgrade to the newest version of U4.
I have created a work-around for this behaviour, which works with manually entered redirects, as well as with automatically created redirects caused by a node rename.
Solution:
Best regards
Max
is working on a reply...