Pages: Custom data fields

[HeyJoel]

You should be able to add custom data fields to pages using models defined in the same way that we do for custom entities and page block types. The example given in feedback was being able to turn off footer design elements on a per-page basis.

Ideally we would be able to define multipe models, which would allow multiple plugins to expand on the Page module. An example of this would be an SEO plugin that added a range of extra SEO data fields, or the existing SiteMap plugin which could have used this feature to encapsulate the ShowInSiteMap property.

Discussion: Should the current SEO/SiteMap flag be moved out into a plugin? Although some SEO fields are fairly standard these days, it's always difficult to keep up with best practices and a more flexible approach would better cater for different requirements or changing recommondations. May relate to #10 (Revise Page Metadata).

[dumboster]

Hello, Do you think there is a way to add custom properties via a hijacked way as long as it is not integrated in pages ? I need this for SEO. Thanks

[HeyJoel]

There's not a lot I can suggest at the moment, you can either re-purpose the existing fields or manage the data separately in some custom way (separate to Cofoundry) - the difficulty with that will be displaying that in an editor friendly way.

One other possibility is creating a page region with a special meta data page block. I've not done it before, but it could work, although again the editing experience might not be so great as the region would not be attached to a UI element.. although you could use the class the visual editor attaches to the page to conditionally apply a style to the region in edit mode.

[dumboster]

Ok, thanks for your response. I'll try to use this.

[mcockrellsana]

Joel,

I know this is an old issue, but i'm trying to achieve the possibility of allowing a customizable modal that loads on page start up. However as you know, since the modal is "Detached" from the dom, the editing functionality stops working (being able to see the highlighted region and use the "edit" feature of the page block). Saw your suggestion here about the class that is used on the html element in edit mode. 2 issues - one, it would be easier if I had a way to determine if I was in edit mode within the view itself and conditionally output things. two, it appears that when i include calls for jquery document.ready in a script tag within the block view, it doesn't fire in edit mode ever (but maybe this is just a weird issue on my end and i could move the script out of the block itself).

I do wish there was a way to set editable data points on page templates, but if i can use a page block and determine edit mode, i can easily skirt around this issue

[HeyJoel]

For page templates there are properties on the IPageViewModel:

@model IPageViewModel
@inject ICofoundryTemplateHelper<IPageViewModel> Cofoundry

@{ 
    // A simple flag for edit mode
    var isEditing = Model.IsPageEditMode;

    // More detail about the specific state of the visual editor
    var visualEditorMode = Model.PageRoutingHelper.VisualEditorMode;
}

For page blocks you can inherit from IPageBlockWithParentPageData in your model which will inject the same page data and properties.

Lastly, you can inject the IVisualEditorStateService anywhere in your app to get the current visual editor state (see entity versioning docs).