Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: RFC: Textpattern 5 ideas & feature requests
I like the idea, but it still makes me think that (in txp 5+) we should find a way to treat articles/files/images/etc as some assets via a common mechanism. Configurable custom fields open new possibilities.
Offline
Re: RFC: Textpattern 5 ideas & feature requests
I’m open to the possibility of treating things as “Txp content” and unifying ways to store and interrogate them.
As long as we broadly maintain the separation of content and its presentation, we should store and manipulate content to inject into templates in the smallest, most efficient, and maintainable footprint we can.
Quite how we do that when some such assets (e.g. articles) “own” or are associated with other assets that can be shared across multiple other assets isn’t clear to me. If they’re all the same “thing” (object) under the hood, it smacks of table hell to link such objects in meaningful ways.
But as you say, unlimited custom fields unlock a lot of potential to strip back content to be “base” objects that have immutable properties (e.g. id, name, lang, created, modified, expires, and type) and then every other attribute that makes up the object of that “type” is a custom field: title, body, excerpt, caption, dimensions, section, access count, category(ies), tags, physical disk assets (file or href?), meta description, slug (URL), yahde yahde.
Corner cases currently include Section which is solely tied to articles. Would we extend it and make it an immutable property so that every asset of every type was accessible via a URL? It’s currently baked in as a template<=>content link, with overrides, but only for articles, which makes things difficult.
Physical asset handling is also not common to all content types and requires specific manipulation outside of database storage. So that needs careful thought of where such data is stored, updated, and managed.
If you have any thoughts on how this might work in practice, feel free to chuck it here or in a Google doc or something so we can figure out if it’s something we can achieve.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: RFC: Textpattern 5 ideas & feature requests
jakob wrote #337828:
Expiry dates for files like we have for articles.
That would certainly be useful for all kind of things that in some way are tied to a time limit.
Bloke wrote #337829:
We’d need […]
- a pref, similar to what exist for articles (“publish, publish expired articles?“), default “no”, which sends a 410. For files the “yes” would mean: available in the
file_downloadas disabled (?) - a multi-edit options to batch process a number of files. I had once asked this possibility for articles. see this issue.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Re: RFC: Textpattern 5 ideas & feature requests
We’ll see if the bulk article expiry can be snuck into 4.9.0. Might need a new string but it’s probably an easy win otherwise. Completely forgot about it, sorry.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: RFC: Textpattern 5 ideas & feature requests
Well, if file expiry dates (+ bulk edit option) can be snuck into 4.9, I’d be an even happier TXP user :-)
The idea of a common mechanism for various / extendable content types I’d also love to see in the next version. I fake this in various more or less successful ways up to now and having an official mechanism for it would be great.
TXP Builders – finely-crafted code, design and txp
Offline
Re: RFC: Textpattern 5 ideas & feature requests
Meanwhile, would it help to introduce a <txp:output_file /> tag, to output files via, say, articles? When encountered, it would just trigger file download:
<!-- in some article form -->
<txp:if_expired>
Too late, sorry.
<txp:else />
<!-- set appropriate headers if needed -->
<txp:output_file id='<txp:custom_field name="fileid" />' />
<txp:if_expired>Looks fairly easy to do.
Offline
Re: RFC: Textpattern 5 ideas & feature requests
Yes! Please! Do we think output_file is an appropriate tag name? I’m thinking what if we could harness it in future to output images or playback videos or allow plugins to trigger downloadable content in response to a third party payment, etc.
Would <txp:output> be more flexible? Perhaps with a type attribute to differentiate (default=“file” or even context dependent somehow?) Or <txp:send>? Or something…?
Happy to keep it specific to files if it makes sense to consider other stuff later.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: RFC: Textpattern 5 ideas & feature requests
I would restrict it to txp ‘files’ atm. Just added type attribute to <txp:file_download /> tag:
<txp:file_download id="1,2,3" sort="RAND()" type="application/pdf">
<txp:header name="content-disposition" value="inline" />
</txp:file_download>Please test.
Offline
Re: RFC: Textpattern 5 ideas & feature requests
etc wrote #337855:
I would restrict it to txp ‘files’ atm.
Fine by me.
Just added
typeattribute to<txp:file_download />tag:
Sweet. Will test when I get a chance. Thank you for the elegant solution.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
#34 2024-09-16 01:19:53
- bashirnoori
- Member
- From: Afghanistan
- Registered: 2012-10-02
- Posts: 79
Re: RFC: Textpattern 5 ideas & feature requests
If we have different field format for custom fields like text, radio button, checkbox, dropdown … it will be great as I need sometime to manage some items/articles through custom_field.
For example, I already display article_image for all articles, some time I don’t want to show that in a specific article and now I do with custom field named is_show_article_image if the value there become 0 or NO, then it will not display in article, so for that if I prepare checkbox it will be easy to clients to understand.
Also, I have a products page which shows the product type now I manage that through custom field text, if that possible to make drop-down or radio buttons, it will be great.
Offline
Re: RFC: Textpattern 5 ideas & feature requests
Custom fields of different types is very much part of the plan. In fact, it’s coded already and, not only does it let you define the type, it stores its data in the most efficient way possible under the hood, which is something no other CMS does, as far as I’m aware.
On top of this, what you seem to be after is dependent custom fields. That’s interesting and not something I’d yet considered, beyond the fact that each can be grouped into a family. To do that requires JavaScript to toggle fields on and off, and honestly, the only ones it applies to are (single) checkbox, radio and select field types as the ‘controlling’ field.
I guess the JS code could be fairly standard, but we’d have to have some conventions in place such that the ‘controlling’ field must be opt in, i.e. it needs to always be “add such and such” not “hide such and such”. Because otherwise the logic would need to be flipped and that’s going to make it harder to manage the code.
Leave this with us and we’ll see what’s possible.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: RFC: Textpattern 5 ideas & feature requests
Bloke wrote #337867:
Custom fields of different types is very much part of the plan. In fact, it’s coded already and, not only does it let you define the type, it stores its data in the most efficient way possible under the hood, which is something no other CMS does, as far as I’m aware.
On top of this, what you seem to be after is dependent custom fields. That’s interesting and not something I’d yet considered, beyond the fact that each can be grouped into a family. To do that requires JavaScript to toggle fields on and off, and honestly, the only ones it applies to are (single) checkbox, radio and select field types as the ‘controlling’ field.
I guess the JS code could be fairly standard, but we’d have to have some conventions in place such that the ‘controlling’ field must be opt in, i.e. it needs to always be “add such and such” not “hide such and such”. Because otherwise the logic would need to be flipped and that’s going to make it harder to manage the code.
Leave this with us and we’ll see what’s possible.
yummy!!!!
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline