Widgets added to custom pages will 404 on attachments called by GetExecutedFileUrl

In v11 we set up custom pages in a plugin using INavigable.RegisterUrls.

We added widgets to the pages by setting DefaultPageXml in PageDefinitionOptions.

Here's a sample showing how it works.

using System;
using Telligent.Evolution.Extensibility.Urls.Version1;

namespace My.CustomPages
{
    public class CustomPages : INavigable
	{
		public string Name => "My Custom Pages";
		public string Description => "My Custom Pages";
		public void Initialize() { }

        void INavigable.RegisterUrls(IUrlController controller)
        {
            // Second parameter must be unique amongst all other pages
            // Third parameter is the URL to put the custom page on
            // Fourth is the human-readable page title.. this might be visible in the Manage -> Custom Pages panel, but isn't visible to the users

            AddWidgetToPage(controller, "test", "testing/test", "e14 Test Page", "519acc1a-728b-487c-8ec1-31f3be501be3");
        }

        // Small helper to cut down on the clutter above
        void AddWidgetToPage(IUrlController controller, string InternalPageName, string URL, string PageName, string WidgetGUID)
        {
            controller.AddPage(InternalPageName, URL, null, null, PageName, GetSinglePageWidgetDefinition(InternalPageName, WidgetGUID));
        }

        // Helper method that simplifies adding a single widget to a custom page
        PageDefinitionOptions GetSinglePageWidgetDefinition(string InternalPageName, string WidgetGUID)
        {
            return new PageDefinitionOptions
            {
                HasApplicationContext = false,
                SetCustomPageOutput = (context, outputController) => { },
                ParseContext = (context) => { },
                Validate = (context, accessController) => { },
                DefaultPageXml = GetSinglePageWidgetFragment(InternalPageName, WidgetGUID)
            };
        }

        // Return a standard XML fragment that represents a single widget on a page
        string GetSinglePageWidgetFragment(string InternalPageName, string WidgetGUID)
        {
            WidgetGUID = WidgetGUID.Replace("-", "");

            return $@"<contentFragmentPage pageName=""{InternalPageName}"" isCustom=""false"" layout=""Content"">
                    <regions>
                      <region regionName=""Content"" >
                        <contentFragments>
                          <contentFragment type=""Telligent.Evolution.ScriptedContentFragments.ScriptedContentFragment, Telligent.Evolution.Platform::{WidgetGUID}"" showHeader=""False"" cssClassAddition=""no-wrapper with-spacing responsive-1"" isLocked=""False"" configuration="""" />
                        </contentFragments>
                      </region>
                    </regions>
                    <contentFragmentTabs />
                  </contentFragmentPage>";
        }
    }
}

After upgrading to v12, the widget is still being rendered into the page correctly, but if the widget has an action in it which calls one of the widget attachments via ajax call, it now fails with a 404, and will popup a message saying 'Scripted Extension Could Not Be Found' (similar to this post).

jQuery.telligent.evolution.post({
    url: '$core_v2_encoding.JavascriptEncode($core_v2_widget.GetExecutedFileUrl('mywidget.vm'))',
	data: $("#form").serialize()
})

Nothing is output to Exceptions.

If I put this same widget onto a Group or custom page added via the front end UI, it works fine (so it's not a bug in the widget itself).

Has something changed in the C# that needs me to set something so that these widget attachments are accessible from this type of custom page?



added ajax call example
[edited by: Matt at 9:32 AM (GMT 0) on Thu, Sep 29 2022]
Parents
  • In the end, I raised this as a support case & am glad I did.

    We had a great response from PD & guidance on the fix for this. Basically it was "occurring due to using a mixed case pageName in the page definition's XML. All of the platform's page defaults use all lowercase, hyphen-separated, names". So it was quite a straight forward change to pageName to get all of this working again Hugging

Reply
  • In the end, I raised this as a support case & am glad I did.

    We had a great response from PD & guidance on the fix for this. Basically it was "occurring due to using a mixed case pageName in the page definition's XML. All of the platform's page defaults use all lowercase, hyphen-separated, names". So it was quite a straight forward change to pageName to get all of this working again Hugging

Children