Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: [RFC] TXP5 Custom Fields Management
etc wrote #340667:
whether this should be related to URLs in core is an open question. I’d rather investigate introducing custom URL schemes.
Yes, I avoid linking URLs to the structure of a publication, usually setting the /title-only URL pattern.
Now I am faced with the question of how to adapt Textpattern for multilingual publishing. Could CF be of any help in this matter?
While there are still few versions of foreign-language webpages, I intend to keep them in the same database, the same domain, but create separate sections and categories for each language and link them together manually.
Offline
Re: [RFC] TXP5 Custom Fields Management
TXP5 Custom fields look to be shaping up nicely (pesky details notwithstanding). Go you good things…
Offline
Re: [RFC] TXP5 Custom Fields Management
Vienuolis wrote #340671:
Now I am faced with the question of how to adapt Textpattern for multilingual publishing. Could CF be of any help in this matter?
Not really. Although CF names / titles are differentiated, with titles stored in txp_lang, it’s not ideal because instances of articles are tied to things like feed times and Posted.
However, you could create a content type for English and one for Lithuanian, with different fields in each set, and write the content twice. Once in each “type”. Then, with some custom URL sprinkling, you could make it appear multilingual.
Theres a detailed plan for true multilinguality that Jools, myself and colak cooked up earlier this year. It’s a bold plan and it’s not easy, but it’s definitely doable and, along with UCF, puts us firmly on the map of capable and uber-performant content management systems.
Nobody else has approached stuff like we have, with the benefit of hindsight at seeing what a hash other CMS’ have made, and learning from their mistakes.
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] TXP5 Custom Fields Management
giz wrote #340672:
TXP5 Custom fields look to be shaping up nicely (pesky details notwithstanding). Go you good things…
Thanks. Yeah, see my comment above about learning from other failed attempts. That’s the beauty of taking the time over stuff to do it with content at the forefront. Everyone else has approached it by storing everything as varchar, which is slow and frightfully inefficient. I’ve put an absolute f-tonne of work into the under-the-hood management so we can store things efficiently, natively. That makes searches faster and more flexible without horrible casting kludges, and keeps the footprint down, which aids performance.
Oleg has just taken this a step further by abstracting my initial work to push content types and flexibility to the next level. It’s all looking very exciting…
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] TXP5 Custom Fields Management
Bloke wrote #340668:
Sticking with a pre-defined structure (where the definition is configured by the user) is preferable, imo.
I totally agree, but what if ad hoc exceptions are not so exceptional? Whence this poll.
Tying stuff to sections by default is not something I’d be keen to employ, because there are so many ways to implement it, that many people won’t be happy.
Me neither, also because not all content types (e.g. images) have sections.
Alternatively, we have the opportunity to switch things around a bit.
Like it!
If you want to create a post about a different content type, you go back to the main Write panel, choose the section/content type/etc from the splash screen and click Next to begin writing.
I like less this one, since you’d have to choose both the section and the content type, which is error-prone. Couldn’t we provide a core tying mechanism such that the choice of the section optionally suggests the content type on the splash screen? Yep, looks pluginish, but I suspect it would be a popular plugin.
Offline
Re: [RFC] TXP5 Custom Fields Management
Bloke wrote #340675:
Oleg has just taken this a step further by abstracting my initial work to push content types and flexibility to the next level. It’s all looking very exciting…
True, I have spent much more time on adapting txp tags, and am still astonished to see them (mostly) working. Anyone who has time for testing is more than welcome.
Offline
Re: [RFC] TXP5 Custom Fields Management
Offline
Re: [RFC] TXP5 Custom Fields Management
etc wrote #340677:
I like less this one, since you’d have to choose both the section and the content type, which is error-prone.
No no, sorry I wasn’t clear. I meant it’s a two step process:
One: choose the type of content you want to write in, which (through the magic of configuration when you set up the CF set, perhaps) is tied to a URL scheme and section.
Two: tap Next to bring up the Write panel as we know and love it, but without the Section selector (because it’s already predefined).
Maybe the New Article button on the Write panel is one of those combo selector thingies that offers you a drop-down:
- New Article in this content type (default)
- New Article in another content type (which takes you back to the content type selection step).
- Or (if there aren’t too many content types, perhaps?) the drop-down could house them all and jump straight to the Write panel with that content type selected, offering you its fields, ready to accept content.
‘Duplicate’ would work as it does now, within the content type and its associated section.
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] TXP5 Custom Fields Management
P.S. it doesn’t have to be a physical two-step process. It could just be a content type selector drop-down when you click New Article (from Content> Articles) or land on the Write panel. And as soon as you pick it, the Write panel draws itself for the content type you’ve chosen and it’s off to the races you go.
Last edited by Bloke (2025-09-26 18:37:13)
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] TXP5 Custom Fields Management
Bloke wrote #340680:
One: choose the type of content you want to write in, which (through the magic of configuration when you set up the CF set, perhaps) is tied to a URL scheme and section.
I don’t like the content type implying the section. Most of your articles might be of a plain article content type, like in txp4, but from different sections. Other way is ok.
Maybe the New Article button on the Write panel is one of those combo selector thingies that offers you a drop-down:
IIRC, we have dumped this button in 4.9, to save space :-) We will see for the interface, currently you can choose the content type via New article feature on the article list pane.
Offline
Re: [RFC] TXP5 Custom Fields Management
etc wrote #340682:
I don’t like the content type implying the section.
So switch it round. Choose section as step one. Then either allow a choice of all content types, or a preset, filtered list if admins want to exert more control over what content types their authors can slot into that section. And if it’s one-to-one, well, no need to choose the content type.
The point is, if choosing a section during article creation causes implementation headaches, let’s redesign the workflow to remove the problem.
IIRC, we have dumped this button in 4.9, to save space :-)
Yeah. Don’t care if it doesn’t make a comeback. Twas only an idea. If people are happy to use the menu bar to make a new article, that’s fine.
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] TXP5 Custom Fields Management
I wonder whether someone is aware of this exhibit of prior art, which I consider very up to the task of object oriented content classes?
Offline