KenticoDevTrev
commented
9 months ago Hey Keith!
So Page templates with a GUID codename are the "Ad-hoc" templates. During the migration processes, they are outlined in the "This page has a page template of 2c588837-970a-4483-bf4a-04f156065a85, what should it be changed to?" in the JSON Conversions, they probably thought the guids were errors and ignored them.
They can update the database in the CMS_Document table to add in a proper and existing page template code name to fix the issue (keeping in mind versioning may cause issues until the versions are cleared or the published version has that change).
That should fix things.
On Tue, Nov 28, 2023 at 11:09 AM Keith Hammond @.***> wrote:
Hello, Trevor. This is Keith from Kentico consulting.
One of our clients is running into an issue, and we would like some clarification on what the next steps are, or if anything might have been missed.
It looks like they have successfully migrated and upgraded without issue. No major errors that are breaking the Admin site. All applications are functional and page data is accessible.
The only issue they are facing now is that their pages are throwing the following error when starting up the front-end site:
- Page template with identifier "2c588837-970a-4483-bf4a-04f156065a85" is not registered in the application.
- Kentico.PageBuilder.Web.Mvc.PageTemplates.TemplateResult.ExecuteResultInternal(ActionContext context)
Where the GUID identifier comes from the CMS_Document table. I am assuming this is expected behavior if the rest of the migration performed well, or at the very worst, a setting or two was missed in the process.
If it is expected behavior, then what are the next steps? Do they need to begin developing custom templates for these pages (plus anything else)? MY assumption is yes based on your wording here https://github.com/KenticoDevTrev/KX12To13Converter#usage---page-converter: "The Page Converter system allows you to map Portal Engine Identities/Properties into your newly developed Page Builder Templates / Sections / Widgets." Anything you can clarify will be a great help. Thank you.
— Reply to this email directly, view it on GitHub https://github.com/KenticoDevTrev/KX12To13Converter/issues/13, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALIDDU5AIHYEUOAAHGAH5LLYGYLGJAVCNFSM6AAAAAA76DC4NCVHI2DSMVQWIX3LMV43ASLTON2WKOZSGAYTIOJRGQZDONY . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Hello, Trevor. This is Keith from Kentico consulting.
One of our clients is running into an issue, and we would like some clarification on what the next steps are, or if anything might have been missed.
It looks like they have successfully migrated and upgraded without issue. No major errors that are breaking the Admin site. All applications are functional and page data is accessible.
The only issue they are facing now is that their pages are throwing the following error when starting up the front-end site:
Where the GUID identifier comes from the CMS_Document table. I am assuming this is expected behavior if the rest of the migration performed well, or at the very worst, a setting or two was missed in the process.
If it is expected behavior, then what are the next steps? Do they need to begin developing custom templates for these pages (plus anything else)? MY assumption is yes based on your wording here: "The Page Converter system allows you to map Portal Engine Identities/Properties into your newly developed Page Builder Templates / Sections / Widgets." Anything you can clarify will be a great help. Thank you.