solidusio-contrib / solidus_content Goto Github PK

We want to allow the admin user to add the option types using the Solidus admin panel.

The steps to accomplish this feature are:

• Add the content label to the Solidus sidebar
• Show the list of the entry types
• Show the action to add a new entry type
• Add the entry type form with the name, the provider and the option type form based on the selected provider

Each entry type can be modified or deleted.

Solidus v2.11.3

Could not find "initializer.rb" in any of your source paths. Please invoke SolidusContent::Generators::InstallGenerator.source_root(PATH) with the PATH containing your templates. Currently you have no source paths.

Generate an empty (.keep) directory for Spree::SolidusContentController views.

I'll open an issue for implementing this, it's certainly an API I'd like to have in this extension

Originally posted by @elia in https://github.com/_render_node/MDI0OlB1bGxSZXF1ZXN0UmV2aWV3Q29tbWVudDQyNDM4ODk3NA==/comments/review_comment

Ref #5

A content provider should allow fetching content created with Contentful, possibly via Renderful.

Ref #5

A content provider should allow fetching content created with Prismic.

This includes:

• being able to define a default rendered for a content (with partials? a callable? renderful?)
• being able to render (with the default renderer) inside a view (e.g. <footer><%= render_solidus_content "footer" %></footer>)
• being able to access the raw data of the content from a view (e.g. <%= link_to "Contact Us", Spree::Content.find("foo").data.dig(:columns, 2, :links, 0, :url) %>)

Update this extension so that it works with Solidus 3.0 by making sure the specs pass.

Ref #5

A content provider should allow fetching content created with SolidusStaticContent.

Add the ability to link from the entry to a remote url that will allow to update the content, e.g. the edit entry page on prismic/contentful.

This will allow frontend JS code to fetch and manipulate content with systems such as React.

There are some features that are common among entry-types, among those:

• The ability to hide, publish, and preview entries, this means also having multiple entries for a single slug, all previewable, but with a single one (at most) published
• The ability to mark the entry type as a singleton (e.g. the home page), this will limit the entries to a single default slug
• The ability to have other mechanisms that will determine which entry should be presented given some characteristics such as geolocation etc. (e.g. having a metadata that store a list of countries for which the entry should be presented and fall-back to a default one for all others)

The content should be identifiable by a slug or UID and the identifier scoped to a content-group, the slug/uid can be used for fetching the content when presented as a page.

E.g. if the uid is foo it will be viewable as /c/foo with the route: get "/c/:id" => "spree/content#show"

Let's open the discussion on how or if we want to integrate or use https://github.com/nebulab/renderful here.

All contents of the same kind should be part of a single ContentGroup.

A ContentGroup will define how that kind of content is fetched (i.e. the ContentProvider) and how that content will behave, including the default renderer, if it's previewable, if it should have a single main instance etc.

A ContentGroup must exist before creating a new Content, but we'll probably provide some default ContentGroups.

Allow each content-provider to make available custom forms for entering its contents. This will allow to go full-circle and manage CMS entries directly from solidus, and ultimately fully replace solidus_static_content or create other custom admin interfaces (e.g. in react).

This includes:

• being able to select a specific (rails) layout for each content
• being able to tie a content page to any URL, with a sensible default
• being able to preview the content if given the permission

Allow to configure a content in order to fetch data from a third party.

E.g. if we want to fetch content from Contentful:

• given we already configured the Contentful credentials somewhere
• from the admin we can click to create a new content
• we can pick the content provider (in this case Contentful)
• then we're presented with a form that will ask us to fill in the content ID
• we can also choose the default renderer for that content (from a drop down)

Will be up to the provider to store in the data attribute of the content just the content ID (or other means to fetch the content on the go) or to also store the content allowing local access.
A content provider should be able to update the data section of the content whenever it's triggered.
A content provider should setup itself to receive webhooks or run regularly to update the data attribute of the content.

The default and basic content provider should allow raw editing of the data attribute (in json format).

A content provider should also connect with content created with solidus_static_content.