Fixes issue with macro rendering in an RTE when GUIDs are used for backoffice document routes

[AndyButland]

Prerequisites

• I have added steps to test this contribution in the description below

Fixes: #16129

Description

Seems we do support backoffice routes using GUIDs in Umbraco 13, so this fixes an issue reported when making use of this with macro rendering. I've amended the request to accept either a GUID or an integer when looking up the content the macros is rendering on.

To Test:

• Add a macro in an RTE that renders in the backoffice (e.g. using the simple Partial View Macro File below).
• Amend the URL of the backoffice page that renders the document for editing, amending the integer ID with the page's GUID.
• Make sure the macro renders and no error is thrown.

@inherits Umbraco.Cms.Web.Common.Macros.PartialViewMacroPage

<p>Test Macro Rendering</p>

[bjarnef]

@AndyButland would it be better to have Guid.TryParse first.. if page id is Guid there is no reason trying parsing to int.

if (Guid.TryParse(pageId, out Guid pageIdAsGuid))
{
    return umbracoContext.Content?.GetById(true, pageIdAsGuid);
} 

if (int.TryParse(pageId, NumberStyles.Integer, CultureInfo.InvariantCulture, out int pageIdAsInt))
{
    return umbracoContext.Content?.GetById(true, pageIdAsInt);
}

I guess int is mainly for legacy/fallback.

[AndyButland]

Actually int is the expected case. For 13 back-office routes use integers.

[bjarnef]

Yes, and it will continue to that as well, but it pageId is already Guid it won't try parsing to int.

But I see your point as most backoffice routes in v13 are using int id, besides linking in custom extension or packages e.g.

[bjarnef]

It also never fully supported Guid in v13 😅
#15289