Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
#73 Today 08:50:16
Re: [RFC] TXP5 Custom Fields Management
etc wrote #340890:
Are labels/translations necessary at all? IIRC, we don’t have them for sections, categories and so on, and nobody complains. It’s a nightmare to maintain.
I would argue that yes, you need to seriously consider it if authors are to choose between “type” of articles… Just as sections and categories should be translatable. In a multi-lingual poli-polar world, it just makes sense.
I vaguely remember, in the early days of Textpattern, raising the idea (forum ? or in a email conversation with Dean maybe ?) but was told that given the architecture / code it was difficult. But if you are overhauling much and many things for Textpattern.next, it must be considered. See also Stef’s comment above.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
phiw13 on Codeberg
Offline
#74 Today 09:11:17
Re: [RFC] TXP5 Custom Fields Management
Bloke wrote #340891:
I was mistakenly thinking it was for the content types themselves.
Not quite mistakenly, sorry, currently Write link is attached to the entity 1 (article), just to mimic txp4 behaviour. But we are going to refactor it somehow, if I read you right.
But if we decide to allow core types to be removed or altered, that’s a different scenario and I then think the keys / names may be a better hook.
Maybe we should clarify what is meant by ‘types’ here. One can very well delete or rename default entities (cfs collections), so names are not any better than ids. But one can not do it with core tables, their names/ids are immutable, but I prefer ids to, say, txp_image.id.
Well we allow people to fire up the Write panel with a set of fields associated with an entity(?). Or does the new fieldsets table handle the linking between content type and CFs?
Entities table just defines the collection name/label and attaches it to a core/plugin table, like txp_image, that will store content. Many entities can be attached to a table, so you can define articles/images etc of different types.
Fieldsets table attaches fields to entities. Both are content agnostic. The linking with content is done in registry table, which attaches content units (article, image, …) to their entities.
Anyway – whether the entity or the fieldset defines how the Write panel differs, it may still be beneficial to put a mechanism in place to allow people to expose them as direct access links from a menu. It saves three clicks via the Articles panel.
I have actually experimented with it (needs refactoring core menu construction), can push. But more I think of it, more the rah_wrach way looks natural: chose the structure first, then just write.
We don’t at the moment. But we will when the multilingual interface is eventually rolled out. Just trying to get ahead of the curve.
Vaste programme :-) I need to grok it first, but if you see how to manage labels, be my guest. I’d just push the latest changes (this evening?), to avoid merging conflicts.
Offline
#75 Today 09:19:36
Re: [RFC] TXP5 Custom Fields Management
phiw13 wrote #340893:
I would argue that yes, you need to seriously consider it if authors are to choose between “type” of articles… Just as sections and categories should be translatable. In a multi-lingual poli-polar world, it just makes sense.
Who would translate these strings? Site admins are not always polyglots, and letting authors edit fields/entities/sections/etc is (currently) error-prone. We’d need to find a way to separate editing language strings from other definitions.
I vaguely remember, in the early days of Textpattern, raising the idea (forum ? or in a email conversation with Dean maybe ?) but was told that given the architecture / code it was difficult. But if you are overhauling much and many things for Textpattern.next, it must be considered. See also Stef’s comment above.
La plus belle fille du monde ne peut donner que ce qu’elle a :-) But we’ll do our best.
Offline
#76 Today 09:39:47
Re: [RFC] TXP5 Custom Fields Management
etc wrote #340894:
Not quite mistakenly, sorry, currently
Writelink is attached to the entity 1 (article), just to mimic txp4 behaviour.
Okay, yeah. As you say, if entities are renamed we’re in the same boat, so IDs are fine. I’d rather adopt the convention that we have a bunch of core base types/entities/whatever that you can extend or add to.
But we are going to refactor it somehow, if I read you right.
Not sure. Depends if it’s worth it, given…
more I think of it, more the
rah_wrachway looks natural: chose the structure first, then just write
… I agree with this. Very few people sit down and think “I’m going to write an article now… but I don’t know what it’s about. I’ll decide later.” Choosing the “type” up-front adds one step to everyone’s Just Write experience but simplifies the process. Sidesteps complicated Ajax logic. And, perhaps advantageously, gives a nice splash screen we can build on if necessary. Want to add a delta field just for this article? Do it at content selection time.
Maybe we should clarify what is meant by ‘types’ here.
Yes! We need to be clear about naming conventions and stuff. A content type is not an entity and not a fieldset, but they’re related. That’s what we need to cement.
if you see how to manage labels, be my guest.
Hehe. You make a good point to phiw13. Defining strings for use on the admin side is not the same thing as writing content for public consumption.
We could be militant. Forget the title. No point using gTxt() on it if it’s going to be fixed in the current admin-side language. We could make the type keys English with first letter capitalised for niceness, or just put up with the types being all lower case in English throughout the back-end interface.
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