Perennial "Improved (and unlimited) custom fields in core" discussion

masa · 2009-09-22 15:34:41

mrdale wrote:

The requirement of a plugin to unlock basic functionality is flaky.

Agreed; I found that rather odd when it was announced.

merz1 · 2009-09-23 11:28:27

@masa I have to agree about the oddness but on the other hand Robert explains pretty well what are the advantages of offering a stable platform and let other developers do the rest.

Related: We have a second issue in one of the corners of the TXP universe: Take a look at the keyword field and how the external plug-in tru_tags is expanding that ‘core platform’ into a pretty good tagging solution.

@all Roberts basic trend question was: Designer CMS OR developer CMS?

I am more of a publisher than a designer/developer so what do I miss? I do not miss unlimited fields (custom or not) but I do miss applications. I miss a calendar, I miss newsletter management, an easy calendar solution and I do miss classified ad management (not to forget smart full or partial page caching :). Other publishers miss shop solutions like the Drupal Uberkart.

Breaking down such wishes top-to-bottom and realizing plug-in hooks for developers to program such applications is the strategic way to go and I think the TXP dev team is on the right way.

TXP core should stay as small and with good performance as possible. I am definitely more on the ‘Designer CMS’ side and I don’t want a bloated and slow solution for everything.

iblastoff · 2009-09-23 16:26:37

merz1 wrote:

@masa I have to agree about the oddness but on the other hand Robert explains pretty well what are the advantages of offering a stable platform and let other developers do the rest.

Related: We have a second issue in one of the corners of the TXP universe: Take a look at the keyword field and how the external plug-in tru_tags is expanding that ‘core platform’ into a pretty good tagging solution.

@all Roberts basic trend question was: Designer CMS OR developer CMS?

I am more of a publisher than a designer/developer so what do I miss? I do not miss unlimited fields (custom or not) but I do miss applications. I miss a calendar, I miss newsletter management, an easy calendar solution and I do miss classified ad management (not to forget smart full or partial page caching :). Other publishers miss shop solutions like the Drupal Uberkart.

Breaking down such wishes top-to-bottom and realizing plug-in hooks for developers to program such applications is the strategic way to go and I think the TXP dev team is on the right way.

TXP core should stay as small and with good performance as possible. I am definitely more on the ‘Designer CMS’ side and I don’t want a bloated and slow solution for everything.

so in order to use this ‘designer cms’ to its fullest extent you have to be a developer is what you’re saying.

Last edited by iblastoff (2009-09-23 16:26:57)

els · 2009-09-23 16:47:19

iblastoff wrote:

so in order to use this ‘designer cms’ to its fullest extent you have to be a developer is what you’re saying.

Or hire one ;) I agree with Markus.

wet · 2009-09-23 17:42:57

iblastoff wrote:

so in order to use this ‘designer cms’ to its fullest extent you have to be a developer is what you’re saying.

This is an universal truth for just about every software product I can think of, at least since I discovered VBA in MS Excel 4.0

mrdale · 2009-09-23 17:46:06

Yeah, I still think that requiring coding to get to 11+ custom fields is lame. Let the plugin devs add all kinds of types, bells and whistles to the CFs but you should be able to at least set them in the vanilla UI.

merz1 · 2009-09-23 18:50:30

@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 :)

uli · 2009-09-23 20:12:27

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)

kevinpotts · 2009-09-24 02:20:45

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.)

gerhard · 2009-09-24 06:05:04

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_ : ).

wet · 2009-09-24 06:18:57

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.

Textpattern CMS

Textpattern CMS support forum

#25 2009-09-22 15:34:41

Re: Perennial "Improved (and unlimited) custom fields in core" discussion

#26 2009-09-23 11:28:27

Re: Perennial "Improved (and unlimited) custom fields in core" discussion

#27 2009-09-23 16:26:37

Re: Perennial "Improved (and unlimited) custom fields in core" discussion

#28 2009-09-23 16:47:19

Re: Perennial "Improved (and unlimited) custom fields in core" discussion

#29 2009-09-23 17:42:57

Re: Perennial "Improved (and unlimited) custom fields in core" discussion

#30 2009-09-23 17:46:06

Re: Perennial "Improved (and unlimited) custom fields in core" discussion

#31 2009-09-23 18:50:30

Re: Perennial "Improved (and unlimited) custom fields in core" discussion

#32 2009-09-23 20:12:27

Re: Perennial "Improved (and unlimited) custom fields in core" discussion

#33 2009-09-24 02:20:45

Re: Perennial "Improved (and unlimited) custom fields in core" discussion

#34 2009-09-24 06:05:04

Re: Perennial "Improved (and unlimited) custom fields in core" discussion

#35 2009-09-24 06:18:57

Re: Perennial "Improved (and unlimited) custom fields in core" discussion

Board footer