Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: [RFC] Custom Fields: expirable?
phiw13 wrote #338824:
Weird,I did not get any debug warnings/errors here (PHP 8.4.2), with the pref set to debugging on. (and it is definitely on as I
gethad the wall-of-errors (strtotime()on the prefs panel – issue1969)
Async responses are not directly output to the surface, you need to inspect them in the browser console.
Offline
Re: [RFC] Custom Fields: expirable?
etc wrote #338826:
Ignoring bwc would make coding easier, but your neat
tableidea seems to work. Well, it means one can not transform, say, ‘file’ into ‘image’, but it’s an edge case.
Yeah, my thinking is that once you’ve defined a content type, it is detrimental to the content if you start restructuring fields, in the same way I talked myself out of the original ability to alter the field’s content_type.
Adding and removing fields to a content type is fine. If you remove one, its data is deleted. If you alter the data storage of that field, then all content types that use it will be affected. Caveat utilitor.
It is not quite clear atm which (custom) tables would be available on new content type creation, but we can start with the core ones. Probably,
textpattern(reduced to a bare fields minimum) will suffice in most cases.
Yep. The four content types we have now, plus maybe comments, will essentially be reduced to a standard set of columns in their respective table (rows?) containing the absolute bare essentials: datestamp and id and author columns. Everything else will be abstracted to CFs.
But crucially, to the outside world, the not-very-4NF table column will give us the ability to make each type look like a cohesive single table. Perhaps a View will help here?
Not sure how best to handle multi-variant options still. Nor things like a feed-updated timestamp (maybe an auto-calculated core field from the lastmod column?)
Cute, let’s try it?
You volunteering? 🤣
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?
Bloke wrote #338829:
But crucially, to the outside world, the not-very-4NF
tablecolumn will give us the ability to make each type look like a cohesive single table. Perhaps a View will help here?
Not sure to see what you mean, but Views can be expensive.
Not sure how best to handle multi-variant options still. Nor things like a feed-updated timestamp (maybe an auto-calculated core field from the lastmod column?)
Is this related to custom types?
You volunteering? 🤣
Sir, yes, sir! Let me fubar everything 🤣
Offline
Offline
Re: [RFC] Custom Fields: expirable?
etc wrote #338830:
Sir, yes, sir! Let me fubar everything 🤣
/me checks logs
etc, it’s your turn to break the repo – godspeed!
Last edited by gaekwad (2025-01-16 17:45:16)
Offline
Re: [RFC] Custom Fields: expirable?
etc wrote #338837:
Fallen on the field of custom. I’m sure you will finish it faster than I’d grok these new classes.
Ha. I was just in the process of doing exactly the same thing but was folding in the change render type at the same time! And squishing a few PHP 8 bugs in the process.
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
Offline
Re: [RFC] Custom Fields: expirable?
Nah, it’s fine. git or me will merge it.
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