Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define singleton objects #2358

Closed
tinganho opened this issue Mar 3, 2016 · 16 comments

Comments

Projects
None yet
@tinganho
Copy link

commented Mar 3, 2016

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.

rosegardenlandingpage 0 5x

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

This comment has been minimized.

Copy link
Contributor

commented Mar 3, 2016

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

@tinganho

This comment has been minimized.

Copy link
Author

commented Mar 3, 2016

@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

This comment has been minimized.

Copy link
Contributor

commented Mar 3, 2016

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

@tinganho

This comment has been minimized.

Copy link
Author

commented Mar 3, 2016

nocreate is also a "hacky" solution.

@VinayaSathyanarayana

This comment has been minimized.

Copy link

commented Mar 4, 2016

I support this feature to be included

@kadosh1000

This comment has been minimized.

Copy link

commented Mar 30, 2016

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

This comment has been minimized.

Copy link

commented Apr 3, 2016

+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 mxstbr removed the new feature label Apr 29, 2016

@mxstbr

This comment has been minimized.

Copy link
Member

commented Apr 29, 2016

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!

@mxstbr mxstbr closed this Apr 29, 2016

@r3wt

This comment has been minimized.

Copy link

commented May 6, 2016

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

This comment has been minimized.

Copy link
Member

commented May 8, 2016

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

This comment has been minimized.

Copy link

commented Apr 5, 2017

Any changes?

@DanPen

This comment has been minimized.

Copy link

commented Jun 7, 2017

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

@n-lavrenko

This comment has been minimized.

Copy link

commented Jun 8, 2017

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

This comment has been minimized.

Copy link

commented Aug 14, 2017

any updates on this feature?

@flzozaya

This comment has been minimized.

Copy link

commented Feb 18, 2018

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

@gorillatron

This comment has been minimized.

Copy link

commented Mar 1, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.