Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Perennial "Improved (and unlimited) custom fields in core" discussion
@Steve What I am saying is that it’s up to the community (aka satellite and/or core developers) to extend TXP core features with plug-ins based on rigid & stable & documented hooks/interfaces.
I am more than happy to have a stable solid designer CMS with a cautious developer team.
To have a strategic way/vision of developing Textpattern for the future is gold compared to tactical marketing maneuvers of adding a feature here and there with inbuilt regressions all the time.
To be a little bit provocative: I am also more than happy that Stev/Bloke is pushing the TXP edges via his plug-in menagerie and not by pushing his features into TXP core :)
Get all online mentions of Textpattern via OPML subscription: TXP Info Sources: Textpattern RSS feeds as dynamic OPML
Offline
#32 2009-09-23 20:12:27
- uli
- Moderator
- From: Cologne
- Registered: 2006-08-15
- Posts: 4,316
Re: Perennial "Improved (and unlimited) custom fields in core" discussion
merz1 wrote:
To be a little bit provocative: I am also more than happy that Stev/Bloke is pushing the TXP edges via his plug-in menagerie and not by pushing his features into TXP core :)
This is true as long as the Blokes are around. But there’s also the Cokes ;)
- – - –
I’m rather undetermined, both positions here have strong pros and cons. That’s why I welcome thoughts like Stuart/thebombsite’s to keep the core lean and get rid of stuff that’s of not much use (his CSS-form thread ).
I’m perceiving more and more wishes to move TXP away from blogging and towards the CMS side. If possible at all, to feature-freeze the blogging commenting system with its 28(!) tags and to make it removable from core similar to the RPC folder would possibly clear a space for the stuff we’re discussing here.
Last edited by uli (2009-09-23 20:15:13)
In bad weather I never leave home without wet_plugout, smd_where_used and adi_form_links
Offline
#33 2009-09-24 02:20:45
- kevinpotts
- Member
- From: Ghost Coast
- Registered: 2004-12-07
- Posts: 370
Re: Perennial "Improved (and unlimited) custom fields in core" discussion
This is true as long as the Blokes are around.
This is the real root for my passion for rolling more extensible custom fields into the core. We have at our disposal an arsenal of incredibly powerful plugins, but scanning through textpattern.org is a bit depressing because of all the “archived” entries. As plugins age and Textpattern keeps moving, their functionality and reliability become ever more brittle.
I would never argue against plugins, and every platform has their share of old ones that just don’t work or are not available. But from my observations and experience, the need for useful custom field functionality is essential. It’s too big of a feature to keep going with ten fields in advanced preferences and hope the gerhards and net-carvers of the world stick around for each update to the core. (Panic!)
We’ve all been affected by brilliant developers leaving brilliant plugins behind (zem_, rss_, etc.). Custom fields have such a deep impact on how Textpattern as a global system is used that I just want to keep their importance in the minds of our esteemed developers. (Believe me, if I could write even a single “hello world” script, I would try to contribute.)
Kevin
(graphicpush)
Offline
Re: Perennial "Improved (and unlimited) custom fields in core" discussion
I only skimmed through those 4 pages and I want to make 1 thing clear: glz_custom_fields is a feature that is either in the core from the beginning or not. A plugin is a few hundred lines of code. glz_custom_fields is well over 2,000 lines of code and therefore is more of a module (it even has a lib directory!). But that’s not the real problem here.
Robert did a great amount of work on the TXP to support plugins such as glz_custom_fields. He pretty much opened the gates for other, greater plugins, similar to glz_custom_fields. Of course, he could’ve started talks into getting this plugin into the core, but you have to see things from his viewpoint to understand his decision of pluggable_ui which I think was a cracking idea. TXP is a platform, a core CMS, which can be expanded into anything one could dream of – and that’s where its power lies. It’s not bloated, it’s fast and it has been stable for years now. If Robert would’ve started adding new functionality, things would have gotten out of hand. More features means more bugs and more code to maintain. What Robert did was to open up this platform even more, enable guys like me to work with this amazing system which is TXP and make it even better.
Can we have custom fields for all data types? Of course we can. Can this be done through glz_custom_fields ? Of course it can. In a timely fashion? Most probably yes. Why? Because of what Robert did through pluggable_ui. There is no longer a need to use Extensions tab for plugins, a plugin can hook right into the core of TXP seamlessly. This is where a lot might have missed the point of pluggable_ui and all the other changes that Robert pushed into core. A plugin is no longer contained to its own little tab, it can be spread though the system. The issue at hand is not going crazy with the UI changes, because glz_custom_fields is a big enough plugin to change the UI of TXP considerably, add bloat and make the interface more difficult to navigate. That’s something that we definitely don’t want.
One last thing. Relational database are not suited for blogs or CMSes, period. The more time I spend with document-oriented databases, datastores and graph databases, the more I realize that this is the next big shift in software development. The way we store data is 1970s, and that is hindering progress for most web apps. Storing custom_fields in the textpattern table is a big no-no and I would have to change that, but this will require more work from Robert. Cluster fucking a single table is the wrong thing to do, but you have no idea how complex and resource intensive searches and building routines would be in MySQL with multiple tables. If you have 10 custom fields, it’s quicker to have them in textpattern table. If you have 20 custom fields, still the same. If you start approaching the 50 custom fields territory (which I know most of you are running), then the situation is slightly different. Also, it’s not only about db columns, it’s also about rows. How many of you have textpattern tables with ~50 custom fields and 1,000 records? Now can you imagine a situation where you can custom_field any TXP datatype and adding hundreds of custom field columns across the various tables?
Robert, this is a question for you. How can we make doArticles() use custom SQL for generating a list of articles? How about searching?
That’s all I have time for now, will keep an eye on this thread though.
p.s. : if I ever was to leave the TXP scene for good, I would not do so without leaving this plugin to someone capable of taking it further. If you look at the plugin code, it’s very well commented and very well formatted, any decent developer could pick it up. So, don’t panic, if worst happens, this plugin won’t get lost, it will only become reborn_ : ).
Offline
Re: Perennial "Improved (and unlimited) custom fields in core" discussion
kevinpotts wrote:
(Believe me, if I could write…
You can write. Not code, but poetry. Attracting new talent is the key to plugin longevity, and all of you have media outlets at your disposal. Make Textpattern more noticeable.
Offline