Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: [RFC] Custom Fields: expirable?
Noted, thanks Myusername. If we can default to UNIX epoch (I started changing this yesterday) but give people the ability to override the custom field validity window, I think it offers the best of both worlds.
That’s why I love opening up discussions like this because it gets everyone thinking about neat ways of working I’d not considered. So thank you to everyone who’s contributing. Keep it coming…
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] Custom Fields: expirable?
1/ i had been thinking along similar lines as Yiannis, ref. grouping. Ideally this should be available on the custom field creation+management tab and the Write tab (or other content-type tabs (images, Files, …). Glad to hear or see this is a realistic option :-).
2/ still have a hard time wrapping my head around your concept of ‘date sensitive’ fields, though.
3/ organisation (on the Write tab, esp). On that particular tab I see the main column more as content creation oriented where as the secondary/side column is for meta data (date, organisation with the site – category/section/…, keywords, etc). If some customisation (via ‘drag&drop’?) is offered, I think it should be a/ site-wide, and then b/ per section. I see little benefit in user customisation.
BTW – will the custom field be a separate panel or a sub-tab of the preferences panel?
BTW 2 – is the Custom field branch already a little bit useable for us mere mortals to explore ?
Thanks for all your work on this.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Re: [RFC] Custom Fields: expirable?
Grouping by default on the various panels is definitely doable. The only sticking point is translations. Language management is… tricky and I’m not sure I’ve quite got it sorted yet.
Traditionally for things like Sections, we offer two fields: Name and Title. This is fine but you’re then limited to one language for the Title. At the back of my mind is that we need to move away from storing the Title in the dedicated table (such as txp_section) and move it to the txp_lang table so we can forge ahead with work on better internationalisation.
To that end, when you create a custom field (yes, on a separate panel under the Admin menu) the ‘Title’ field doesn’t put stuff in the ‘meta’ (a.k.a. custom fields) table but diverts it to txp_lang with a prefix (to avoid clashes with core field names… but I’m still thinking about this) and a language group/owner (now we have them available as of 4.7.x).
This poses interesting challenges when you, say, rename a CF. If it was called price, your cf is (internally) referred to as cf_price and your txp_lang string key is also cf_price. If you decide to call this max_price, when you save, Txp needs to hunt down the cf_price language string(s) and re-key them to cf_max_price. Keeping the two tables in step is not pretty but it seems to work under rudimentary testing.
Doing it this way opens up the possibility of using something like smd_babel to give custom fields unique titles per language so when you switch front-end languages, your field labels change too. Now, quite what happens if you define a field and label in English, switch admin side languages and revisit the panel is not something I’ve tried. In theory it’ll leave the Title blank and you’ll need to type in the new label in the current language and save it again to set it. That should work, clunky as it is. Longer term there are plans for a much better interface experience for multi-lingual content to be defined without hopping from panel to panel, this is just a stepping stone.
The other option is to add a lang column to every table. But it’s not very normalised, and for things like txp_section that would mean duplicating records for a section, with the only difference being the language. That makes section counts and iteration more annoying. It works okay for the textpattern (articles) table – sort of – if we add a grouping capability so we know which articles are in a set. But for other stuff, it’s more hassle than it’s worth to store the language translations directly. A link table would be way better, though that brings its own baggage like referential integrity.
Anyway, it’s kind of off-topic for here. I only bring it up because it impacts custom fields and I don’t want to implement something and then find it’s more difficult to migrate to a fully-featured i18n environment later. So it’s important to discuss it on the fringes of this work to avoid causing us problems in future.
The CF branch should be usable as-is BUT it might throw a bunch of errors at first for missing this and that. I’ve no idea what will happen on upgrade or brand new installation as I’ve been iterating piecemeal. But once it’s going, it works okay. Article fields only for now.
Maybe wait until hopefully next week when I’ve ironed out the timestamps thing and fixed some more PHP 8 warnings. I’ll also have had time to test it on a brand new installation and I’d like to give it a whirl on the huge database that towndock kindly provided me. That’ll be… fun!
P.S. I agree that user customisation is perhaps overkill. But depending on how it’s implemented (e.g. if we’re allowing Publishers to do it via drag/drop) then there’s little technical impediment to allowing all users to do it. Bar storing the state per user instead of per panel.
Last edited by Bloke (2022-03-25 13:20:17)
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] Custom Fields: expirable?
Ideally I’d like people to be able to drag n drop the Write panel to group/hide stuff and lay things out as they see fit. But we then hit another issue: is this done by admins? Per user group? Per section (if we find a way to link sections to fields in a meaningful manner)? Or can individual users change their own layout? Is there a suggested layout per user group by admins, but users can tweak it to hide stuff they don’t use often?
One of the things that I read about 10 years ago was how the front/back end design of fb helped in its success and how MySpace’s flexibility lead it to failure. fb’s pages all looked similar but they functionally and aesthetically “worked.” MySpace front end pages were mostly customised by users who had little to no html/css experience.
Although, it goes without saying that I would not support fb, there is nevertheless something to be said about common experience. The web has individualised our experiences and I think that most of us here know where that has lead and where it is leading.
As such, I would urge for the common back-end interface. Drag and drop adjustments may sound good on paper but it will make supporting the back-end and any queries about it in the forum, much more difficult as we would not know what our users are looking at.
I really like the idea of TXP_MAIN which I think that it that could initially contain all existing CFs in the group.
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Re: [RFC] Custom Fields: expirable?
Date sensitive fields visual example…
----------------------------------- Time ------------------------------->
<--A1---A2------A3------A4----A5-A6----A7-A8--A9---A10----A11----> (article posted times)
<CF1-------------------------------------------------------------------> (custom field 1 defined from Epoch)
<CF2-------------------------------------------------------------------> (custom field 2 defined from Epoch)
<----------------------------CF3---------------------------------------> (custom field 3 defined from some date, no expiry)
<------------------CF4c------------------------CF4e--------------------> (custom field 4 defined earlier than CF3, but expires a little later)Okay, so given the above scenario. There are two sets of dates at play:
- The article posted dates.
- The custom field validity ranges (created and expiry dates).
CF1 and CF2 are available to all articles when you click an article to edit. The CFs appear in the Custom Fields twisty.
However, if you click on articles A1 thru A4, you will not see CF3 because, as far as the articles are concerned, it doesn’t exist. The posted date stamp of the article is compared to the created stamp of the custom field and if it isn’t in range, you don’t see it. If you click to edit articles A5 thru A11, you will see CF1, 2, and 3 can take values.
Custom field 4 has a start date and an expiry. Articles A1 thru A3, and articles A9 thru A11 will not have CF4 in them because its datestamp is outside the article’s Posted date.
Articles A4 thru A8 inclusive will show all 4 custom fields for editing.
The same logic is (or will be) applied to the front end. Any field out of scope will not be rendered. So if your template has a <custom::field name="CF4" /> tag then it will only show its field content when viewing articles A4, 5, 6, 7, or 8. Similarly. <if::custom_field name="CF4"> will only be true for those five articles.
Is that any clearer?
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] Custom Fields: expirable?
Good points, Yiannis. One of Textpattern’s guiding principles is “convention over configuration”. If we offer an option for something, it’s usually (well, should be) a last resort because if there’s something that can be decided via convention – be that a naming strategy or a logical way of working – we’ll take that first.
If we can get away with not allowing extensive customisation of the admin panels by users, that’s terrific. If some users want that, wonderful. As long as the system is flexible enough by providing all the data one needs on the page, a plugin can take over and add the whizzy stuff.
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] Custom Fields: expirable?
Your concept based on the expiry date of CFs is very interesting.
However, because future CFs creation will be unlimited, it could be confusing for users (writers)– the current case with the well known plugin– to see an interminable list of different CFs. For a better user experience, I think the most valuable feature will be based on sections, depending on CFs if they are relevant to the context (that’s your initial approach with the expiration dates, in part).
Patrick.
Github | CodePen | Codier | Simplr theme | Wait Me: a maintenance theme | [\a mi.ni.ma]: a “Low Tech” simple Blog theme.
Offline