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

Future Feature Requests #140

Open
2 of 3 tasks
budparr opened this issue Aug 19, 2016 · 12 comments
Open
2 of 3 tasks

Future Feature Requests #140

budparr opened this issue Aug 19, 2016 · 12 comments
Labels

Comments

@budparr
Copy link

budparr commented Aug 19, 2016

I realize it's pretty early yet, so lumping these advanced features here together just to get them out there because I think they're some of the more important things to have. These three are all related in that they reduce the potential for errors.

  • Autogenerate filename from title if not given #224 - Create slug automatically from title. Right now the affordance for a slug is to show an example, but the example is misleading because it looks like the title is in, and at first glance you don't notice it's not even the right date. This is a bigger deal for posts where a user then needs to remember the date format, but would be useful all around, as I've observed a lot of non-technical users and creating valid file names is a real problem for them (the most popular mistake is forgetting to add the extension, go figure).

  • Allow for default fields #165 - Allow for default fields. A site owner should be allowed to set up fields in the config file, or elsewhere, which creates consistency and ease of use for content creators:
    Here are examples for how others handle this: Prose.io:, Cloudcannon, Siteleaf.

  • Allow a field to automatically reference an item from another collection. If you have collection A and collection B, then one should be able to create a field in collection A that allows a user to reference an item or items in collection a via a drop-down list. This helps maintain the integrity of data. For instance, One editor inputs author: tom jones but another inputs author: thom jones

Here are examples for how others handle this: Cloudcannon (scroll to select), Siteleaf.

@benbalter
Copy link
Contributor

Allow for default fields. A site owner should be allowed to set up fields in the config file, or elsewhere, which creates consistency and ease of use for content creators:

Are you suggesting, for example, I could have the following in my config:

jekyll_admin:
  default_fields:
    - title
    - description

And then when creating a new post, those fields would be initialized, but empty, by default?

Create slug automatically from title.

That's a great idea. Would you mind opening a dedicated issue for that?

Allow a field to automatically reference an item from another collection.

Are you suggesting the Jekyll Admin would provide basically an auto complete / list of options, but that the data would ultimately be stored as the resulting string? Or that it was actually stored as a reference?

@budparr
Copy link
Author

budparr commented Aug 22, 2016

Are you suggesting the Jekyll Admin would provide basically an auto complete / list of options, but that the data would ultimately be stored as the resulting string? Or that it was actually stored as a reference?

I think auto complete is a good description, and yes, the data would ultimately be stored as the resulting string.

If I have collection with people who are authors:

bill-thornton.md  
tom-masters.md
rick-jones.md

And another collection or posts that has a field author I'd like that author field to autocomplete with the names of people in the author collection.

The field would still result in something like this in front matter:
author: bill-thornton

but presented to the user inputing content as a drop-down list of the titlesof the entries in the author collection.

Here's a screenshot from Siteleaf's documentation, which accomplishes this:
meta-collection

The purpose of this proposal is to reduce errors by eliminating the requirement that a content creator remember the entries and their slugs when creating a relationship between entries.

@benbalter
Copy link
Contributor

It sounds like then, an autocomplete feature would likely need two data sources:

  1. Pre-defined choices in config (e.g., colors, sizes, etc.)
  2. Pre-defined relationship in config (e.g, authors, products, posts)

@budparr
Copy link
Author

budparr commented Aug 22, 2016

Yes, though, for the pre-defined relationship, both Siteleaf and Cloudcannon use field naming conventions rather than configuration.

I realize the scope of those projects may be different, and here, the consistency of having everything in a config file may be simplest.

@benbalter
Copy link
Contributor

Yes, though, for the pre-defined relationship, both Siteleaf and Cloudcannon use field naming conventions rather than configuration.

Can you explain a bit more?

@budparr
Copy link
Author

budparr commented Aug 22, 2016

If you have a key called author in a collection, it will automatically reference the collection _authors if it exists.

@benbalter
Copy link
Contributor

@parkr would say that that violates Jekyll's no magic philosophy because it's an instance of Jekyll trying to be too clever since the user didn't explicitly ask us to do that.

@budparr
Copy link
Author

budparr commented Aug 22, 2016

Perhaps. I don't think conventions like author mapping to authors is too terribly clever, but I do think that once you have a config file, everything should go there. Long way of saying you're right.

@mertkahyaoglu
Copy link
Member

BTW, first feature implemented by #224

@jekyllbot
Copy link

This issue has been automatically marked as stale because it has not been commented on for at least two months.

The resources of the Jekyll team are limited, and so we are asking for your help.

If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.

If this is a feature request, please consider whether it can be accomplished in another way. If it cannot, please elaborate on why it is core to this project and why you feel more than 80% of users would find this beneficial.

This issue will automatically be closed in two months if no further activity occurs. Thank you for all your contributions.

@parkr
Copy link
Member

parkr commented May 10, 2017

If you add the pinned label, then @jekyllbot will not close this issue :)

@mertkahyaoglu
Copy link
Member

Oh. Thanks for the tip @parkr 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants