Content Types

MattLeeMattLee Member
edited May 2017 in Product Wishlist

Hi,

I've been trying Kentico Cloud to host the content of my website. It is simple and easy to manage. While I was entering content, I have few suggestions on Content Types

  1. Regex validation on the content type field
  2. Default value to a field
  3. Drop down content elements

Cheers,
Matt

Tagged:

Comments

  • JanL@kentico.com[email protected] Czech RepublicMember, Administrator, Kentico Staff admin

    Hi Matt,

    Great! Thanks for your ideas!

    I know that for developers these ideas may seem self-explanatory, but still, we would love to hear some detailed examples of how you'd use these. Would you share such examples with us? It might bring some other ideas and it could shape up our understanding of your requirements a lot.

    As for the 3) Drop down content elements, these are already deployed to the product as Taxonomy fields.

    Will Taxonomy fields serve your scenario? If not, just tell us.

    Thanks

    Jan

    1. Default value to a field

    I would like to expand on this a bit, specifically on the default value.

    I have a requirement to provide some flexibility to the setup of the header, footer, and some other chrome pieces of the site. Focusing on the header, I have added a content type for Header, added an entry of this type, then I added a Modular Content to the page limited to this type and limited to exactly one value.

    It is rare that a user will select a variant of the header but I have a requirement to make it possible. I would like the Modular content field for Header in the content type for a Page to include a default value of the most common selection. This saves time for the user as they are not required to make the selection for every new content item, and encourages them to make the suggested selection. But still allows them the flexibility of selecting a variant. This scenario will apply to several fields compounding the time savings by adding a default.

    Other than header or footer, this would also be used to select navigation or menu content. I have considered using taxonomy selections to set the navigation but that would require a lookup of taxonomy to content ID at the front end unless the taxonomy entries were allowed a custom property per entry.

  • liamgoldfinchliamgoldfinch Member
    edited June 2017
    1. Regex validation on the content type field

    I think this is a good idea. Limiting input to be a valid email address/telephone number is one of the most obvious examples I would say. Like making an "Office" content type for a business office would have location fields which would probably want some regex validation.

  • Plus one for 1 for:

    Regex validation on the content type field

    I would suggest also that some standard regex's are available to select from as well as entering custom values

  • petrs@kentico.com[email protected] Eindhoven, NLMember, Administrator, Kentico Staff admin

    @stewartJohnston Regarding the default headers, you could set them in the code or if there is some flexibility required from the content editor's perspective, you could introduce some naming conventions.

    Example: if a header is not explicitly specified, the code would retrieve a predefined one or a one defined by a naming convention.

    Wouldn't that work for your scenario?

  • Our current setup has the headers as blocks in the CMS and are currently selected by content organization within the site.

    I was looking to allow for a default but allow the content editor to select the header block associated with the page block. Now I am thinking that either taxonomy or site map path could be a good source to select the header since that would still allow for the editor to have some influence in the selection.

  • leelee Member ✭✭

    In relation to...

    1. Default value to a field

    I'm building a site that contains a blog. On the blog I want to have a "Published Date" that might be different to the created date and might be set in the future.

    If set in the future I can filter it out in my queries to the API but in most cases the Published Date will be the date that the content is actually published.

    It would be helpful if for DateTime fields in particular there were settings to choose a default value such as...

    1. Default to created datetime - if left empty when first saved would populate on save.
    2. Default to published datetime - if empty on publish would populate on publish
    3. Default to last edited datetime - would populate on every save

    I'm actually surprised that Kentico Cloud doesn't have a "Published date" already.

  • JanL@kentico.com[email protected] Czech RepublicMember, Administrator, Kentico Staff admin

    Hi @LeeConlin

    1. Default to created datetime - if left empty when first saved would populate on save.
    2. Default to published datetime - if empty on publish would populate on publish
    3. Default to last edited datetime - would populate on every save

    I'm actually surprised that Kentico Cloud doesn't have a "Published date" already.

    Good idea. I'll dig through our ideation database to see if there was such one previously. I can imagine someone might want to set up the date fields as custom content elements and populate the values via the Write API
    instead.

    But, this might be a good idea to automate things a bit more. Let's see what the database has. I'll also discuss it slightly with our product owners.

  • petrs@kentico.com[email protected] Eindhoven, NLMember, Administrator, Kentico Staff admin

    @LeeConlin You can achieve some of the scenarios by leaving the date element not required and handling the null values in the code.

    E.g.

    if (published_date == null) 
    {
      return last_modified;
    } 
    else 
    {
      return published_date;
    }
    
  • leelee Member ✭✭
    edited July 2017

    In all honesty the three most important date_time's to have on any content item are:

    1. last_modified
    2. created
    3. published (could be set to future)

    You might also want to have additional options for date_times for each step of workflow too, since these could be used with the write-api later.

Sign In or Register to comment.