3 ms·

>purchasing its custom fields plugin was perhaps my first online transaction. Wow. That was a long time ago! Custom fields are standard these days, albeit limi

>purchasing its custom fields plugin was perhaps my first online transaction. Wow. That was a long time ago! Custom fields are standard these days, albeit limited to articles and 10 maximum, though there are plans to extend to unlimited custom fields in core.

Tomte 6y ago
Are there plans to give them some type? As of now they are simply strings, as far as I understand. Having a date picker for date customs fields etc. would be great. Of course, if you give us that, we will always ask for more, until you have implemented half of Kirby (https://getkirby.com/docs/guide/blueprints/introduction https://getkirby.com/docs/guide/blueprints/introduction). :-)
- petecooper 6y ago
  >Are there plans to give them some type? As of now they are simply strings, as far as I understand. They are strings. I don't know of any plans to extend the core beyond that, though speaking for myself it sounds like plugin territory. >Having a date picker for date customs fields etc. would be great. A valid case. The argument for x feature is sometimes a tricky one, as a lot of things fall into plugin territory until a critical mass of people want it, and then it's considered for core. Unfortunately, many Textpattern plugin authors have moved on to other projects, and some often-used plugins end up being orphaned, adopted and repurposed for current releases. It's a somewhat tricky situation – have a feature spun out to a plugin, sites become reliant on said plugin, plugin author moves on, and the community ends up fixing the plugin for current versions. There's no animosity at all, as far as I know, it's just not an ideal scenario. Thankfully many (most?) plugins are open sourced with appropriate licences.
- stefblokedawson 6y ago
  > Are there plans to give them some type? Yes! The next custom fields implementation is, as far as I'm aware, one of a kind in that it a) uses the 'best' field type to store the data under the hood in the database (int for numerical data, datetime for dates, and so forth), and b) will permit you to output any html component to support that data type at input time. So, yes, a date picker for dates if you like. All the built-in data wrangling is customisable by plugins so they can override/extend data storage and offer different input methods as needed. Though we do have to finish that bit of code yet! The branch is still lurking in our repo, awaiting final tweaks for prime time.

Tomte 6y ago

Are there plans to give them some type? As of now they are simply strings, as far as I understand. Having a date picker for date customs fields etc. would be great. Of course, if you give us that, we will always ask for more, until you have implemented half of Kirby (https://getkirby.com/docs/guide/blueprints/introduction https://getkirby.com/docs/guide/blueprints/introduction). :-)

petecooper 6y ago
>Are there plans to give them some type? As of now they are simply strings, as far as I understand. They are strings. I don't know of any plans to extend the core beyond that, though speaking for myself it sounds like plugin territory. >Having a date picker for date customs fields etc. would be great. A valid case. The argument for x feature is sometimes a tricky one, as a lot of things fall into plugin territory until a critical mass of people want it, and then it's considered for core. Unfortunately, many Textpattern plugin authors have moved on to other projects, and some often-used plugins end up being orphaned, adopted and repurposed for current releases. It's a somewhat tricky situation – have a feature spun out to a plugin, sites become reliant on said plugin, plugin author moves on, and the community ends up fixing the plugin for current versions. There's no animosity at all, as far as I know, it's just not an ideal scenario. Thankfully many (most?) plugins are open sourced with appropriate licences.
stefblokedawson 6y ago
> Are there plans to give them some type? Yes! The next custom fields implementation is, as far as I'm aware, one of a kind in that it a) uses the 'best' field type to store the data under the hood in the database (int for numerical data, datetime for dates, and so forth), and b) will permit you to output any html component to support that data type at input time. So, yes, a date picker for dates if you like. All the built-in data wrangling is customisable by plugins so they can override/extend data storage and offer different input methods as needed. Though we do have to finish that bit of code yet! The branch is still lurking in our repo, awaiting final tweaks for prime time.