Keystone-classic: Define singleton objects

[tinganho]

Not everything exists in multiples. In the CMS world there exists objects that are only "singular". Everything on this page could be defined as one object called HomePage.

Right now, there is no data structure that represent a HomePage object above. I need to do an ugly hack and make it a list.

[webteckie]

@tinganho doesn't the list options label/singular help you in this case? See http://keystonejs.com/docs/database/#lists-options

[tinganho]

@webteckie I don't think so. Unrelated.

This is what I do currently:

let HomePage = new List('HomePage', {
    label: 'Home Page',
    plural: 'Home Page'
});

let fields: Fields = {
    name: { type: String, required: true, default: 'Home Page' },

    title: { type: String, required: true, initial: true },
    heroImage: { type: Types.CloudinaryImage, autoCleanup: true },

    promo1Title: { type: String, required: true, initial: true },
    promo1Description: { type: Types.Html, required: true, initial: true },
    promo1Image: { type: Types.CloudinaryImage, autoCleanup: true },

    promo2Title: { type: String, required: true, initial: true },
    promo2Description: { type: Types.Html, required: true, initial: true },
    promo2Image: { type: Types.CloudinaryImage, autoCleanup: true },

    review1Title: { type: String, required: true, initial: true },
    review1Description: { type: String, required: true, initial: true },
    review1image: { type: Types.CloudinaryImage, autoCleanup: true },

    review2Title: { type: String, required: true, initial: true },
    review2Description: { type: String, required: true, initial: true },
    review2image: { type: Types.CloudinaryImage, autoCleanup: true },

    review3Title: { type: String, required: true, initial: true },
    review3Description: { type: String, required: true, initial: true },
    review3image: { type: Types.CloudinaryImage, autoCleanup: true },
};

HomePage.add(fields);
HomePage.defaultColumns = 'title';
HomePage.register();

And I don't want a admin UI made for lists. I want an admin UI made for singletons.

[webteckie]

Use the nocreate: true option? But I think this suggestion has come up before. Would have to dig through the issues to check.

[tinganho]

nocreate is also a "hacky" solution.

[VinayaSathyanarayana]

I support this feature to be included

[kadosh1000]

A very important features, I too currently use the nocreate:true but as @tinganho sayed it's a very hacky solution. I dont want the user to go into the list and see only 1 item, but just directly move him into the item edit.

[jjhesk]

+1 there should be one singleton object that hold the configurations in the entire app that is available to the cms to access. i strongly suggest there should be a place for single object field for everything. Like all other system where there is a place to put all the options for the admin to tweak around. It should be UI friendly for the admin or specific role of people to access.

[mxstbr]

We're closing all feature requests to keep the issue tracker unpolluted. I've moved this to ProductPains, upvote it there if this is important to you: https://productpains.com/post/keystonejs/content-management-ie-singletons-like-pages!

[r3wt]

copying this here from productpains:

Of course this is necessary. These days people want highly specialized cms, with a specialized admin page for editing each page. not some 1 size fits all list option. keystone is awesome, but moving this here was unnecessary and shortsighted. currently keystone is unmatched in the speed to market department for building a custom cms. alienating developers will lead to a fork! Content managers want something as easy as possible. In conclusion, i would posit that, without singletons such possibility is not accessible in the developer in the current system without making modifications to keystone itsself, which is unsuccessful and makes keystone no better than wordpress.

[JedWatson]

I'm pretty sure I've mentioned this elsewhere, but just to leave a note here as well: This feature is high on the list of things we'll be addressing once 0.4 is released and stable.

The official implementation will be a streamlined workflow around the hacks that users have already established*, with a specific UI area to make editing singletons easy. We'll open issues relating to how that's planned to be implemented (as well as publish the designs we do for how it will work) when it's coming up for active development.

We feel the pain of not having it (I've personally needed it on a few projects) but the call has been to stabilise the new React UI and Field Type components first, which despite the delay (it was a huge amount of work) I think will be the right one in the long term. Migrating data from workaround implementations to the official solution will hopefully be quite straightforward.

* one potential major difference may be that we keep all "singleton" objects in a single MongoDB collection and offload the schema completely to Keystone Lists, rather than wrapping Mongoose Schemas under the hood. Lists have matured a lot in the last few months and I think that'll be viable, and not having a collection for each singleton is definitely preferable. Again, this will be finalised when the feature is up for development.

[oleg-demkovych]

Any changes?

[DanPen]

Commenting one year and a month later, is there any progress on this?

[n-lavrenko]

I've been decided to choose nocreate and nodelete solution.
And in view when I get a collection, I get just first element of collection.

h1.title= topContents[0].title
p.text!= topContents[0].text

[avichaishapira]

any updates on this feature?

[flzozaya]

It's now been over 1 year and 9 months since @JedWatson commented about this feature.
Is there any progress on this??

[gorillatron]

This feature is very useful when creating landingpages and more static pages with keystone. Any status update?