umco / umbraco-inner-content Goto Github PK

Could Inner Content leverage the use of Content Templates (aka Blueprints) for content selection?

The use-case would be to pre-configure a content block, then let it be selectable from the Content Type picker overlay. We could attempt to re-use Umbraco's UI here?

This is open to community feedback.

When the ContentTypes are displayed in the selection overlay, they are in alphabetical order by name.

They should be displayed in the order they are sorted in the DataType's PreValue config.

When working with a large number of components it would helpful to be able to categorize them into groups and also search/filter them in the create overlay. I wouldn't mind working on a PR if this is something you'd consider.

If i add style="width: 700px;" to innercontent.overlay,html on the second umb-overlay Then its works.

Would be handy if the width of the editor could be set in a config somewhere.

Right now the base InnerContentPropertyValueEditorWrapper still expects the developer to unwrap the JSON and parse everything that isn't an Inner Content object. We could probably simplify this a little by letting it handle ANY JSON and detecting when it hits an Inner Content object to run the conversion.

This should be fine for most people who don't need to do any extra processing on their JSON model. For those that need to, they will implement as it's currently setup. Either way, this will add flexibility.

This a placeholder issue to outline our intentions for Inner Content support on Umbraco v8.

Thoughts on supporting v8...

• I posted some of my initial thoughts on Twitter.
• We are curious of how v8's Infinite Editing feature could be leveraged.
• We are curious of how NuCache could support the use of "real nodes".
• We are curious of how content tabs would be displayed?
• Are there any extra considerations for how variant's split-view would work?

From a historical perspective...

• It is important to recall the history of this package library, keeping in mind that Inner Content (or more specifically Stacked Content) evolved from iterations of several packages, e.g. WidgetGrid, Mortar, Doc Type Grid Editor and Nested Content.
• Inner Content was not invented before Umbraco v7.0 had been released.
• Let's not rush to force support for Umbraco v8.0.

I'm wondering whether we should prefix the InnerContent specific properties with an underscore?

This would avoid any potential clashes with Umbraco property-alias names.

e.g. ContentTypeAliasPropertyKey = "_contentTypeAlias"

😏 maybe a double underscore might look better?

Would there be any technical reasons to not do this? e.g. would Angular work okay with this?

@mattbrailsford - No biggie if you don't like the idea 😃

When a stacked content item is copied it gets added to Local Storage, but is never removed. Since local storage does not expire this leads to a confusing UX. An editor may come back to editing a page days or weeks after copying a stacked content and still see the paste button, which leads to confusion.

I would propose either:

1. Clear the copied item after it is pasted for the first time. If the user wanted more than one copy they would need to recopy.

2. Only keep the copied item around for the current Umbraco session.

3. A clear copied button. Could be more confusing since it doesn't mimic any other copy/paste experience.

Any thoughts? I'd be happy to do a PR.

Currently configured to use NC logo so we could do with it's own unique logo

I can't be sure if this is an Inner Content issue not (not sure how to test).

I have a simple property editor with two fields. For example, model.value.text and model.value.element. I make edits in the overlay and discard/cancel the changes and save. When I come back to the node, I see the "discarded" changes were saved.

Any ideas?

Using a property alias such as "icon" can burn users, see Our Umbraco forum post for an example.

As of v1.1.1 (time of writing), we have the following...

private static bool IsSystemPropertyKey(string propKey)
{
    return propKey == "name"
        || propKey == "children"
        || propKey == "key"
        || propKey == "icon"
        || propKey == InnerContentConstants.ContentTypeGuidPropertyKey
        || propKey == InnerContentConstants.ContentTypeAliasPropertyKey;
}

ref: https://github.com/umco/umbraco-inner-content/blob/1.1.1/src/Our.Umbraco.InnerContent/PropertyEditors/InnerContentPropertyValueEditorWrapper.cs#L235-L243

The insert content overlay is cumbersome and difficult to navigate for editors when there are a large number of components. Something more robust than the item picker is needed. It could be that the entire UX of the insert content overlay needs to be rethought (as the issue exist within , but at the very least search filtering and component grouping would be helpful.

Rather than using a dropdown, we could do similar to how the DocType "Allow children" permission UI works. Use the overlay directive to display a doctype picker.

https://github.com/umco/umbraco-inner-content/blob/develop/src/Our.Umbraco.InnerContent/Web/UI/App_Plugins/InnerContent/views/innercontent.doctypepicker.html#L20

This is purely a cosmetic / consistent UI idea.

Internal note:

Once v1.1.0 is out, we'll need to update the Courier resolver and Deploy connector...

• https://github.com/umbraco/Umbraco.Deploy.Contrib/blob/dev/src/Umbraco.Deploy.Contrib.Connectors/ValueConnectors/InnerContentConnector.cs
• https://github.com/umbraco/Umbraco.Courier.Contrib/blob/dev/src/Umbraco.Courier.Contrib.Resolvers/PropertyDataResolvers/InnerContentPropertyDataResolver.cs

We'll need to add in check to see if the icContentTypeGuid or icContentTypeAlias is available and perform the deployment logic accordingly.

To support Umbraco's load-balancing scenarios, we should hook into the cache refresher events rather than DataType's saved event.

We made the same change on Nested Content: umco/umbraco-nested-content@fc5086b

Let's explore if we can have cursory validation on mandatory fields within Inner Content.

This would only be for client-side validation - server-side would open a can-of-worms!

Hi there,

I'm trying to add a new Data Type in Umbraco with the property editor Stacked content. When selecting "stacked content" i get the following error message.

Request error: The URL returned a 404 (not found):
/~/umbraco/backoffice/InnerContent/InnerContentApi/GetAllContentTypes

I tried uninstall Our.Umbraco.InnerContent and Our.Umbraco.StackedContent, and the reinstall them again with the same results...

Can someone please help me fix this issue?

Thanks in advance

Also, setting the position="center" to the "umb-overlay" directive makes the modal larger.

It could be a good workaround for #9?

NOTE: Logging here, so I don't forget about this in future.
This is not yet an actionable task.

I've hit an edge-case with Stacked Content, where I have existing Content blocks in the stack, then later I decide to remove specific ContentType from the Stacked Content data-type configuration.

The existing Content block is still in the stack, but when I click to edit it, there is a JS console error.

The error comes from Inner Content not being able to find the corresponding ContentType for that block, see here:

https://github.com/umco/umbraco-inner-content/blob/1.1.0/src/Our.Umbraco.InnerContent/Web/UI/App_Plugins/InnerContent/js/innercontent.controllers.js#L114-L117

The practical developer says "just delete those blocks" ... but I'm wondering if we should do something nicer? Either to display a warning/notification, or let the Content block still be editable?

We can detect in the JS if the ContentType is not available after this line:

https://github.com/umco/umbraco-inner-content/blob/1.1.0/src/Our.Umbraco.InnerContent/Web/UI/App_Plugins/InnerContent/js/innercontent.controllers.js#L229

So that package devs can reference the InnerContent DLL in their packages without having the App_Plugin folder restore

In my test I created a Stacked Content Data-Type, lets call it "Configuration".
In this Stacked Content you can create a Inner-Nodes that does not have any properties. Example: "Gather News articles", which is just a node with no properties. Cause that Node-Alias is giving the necessary data to the template.
When transferring this setup between environments, courier fails.

This can of course be fixed by just adding a Label to the empty Doc-Type.

Hope the issue makes sense, thanks.