The direction of Textpattern 5

hablablow · 2011-08-22 20:22:42

Stef,

I have created a custom content tab called About where a user can add various informations using your smd_bio plugin indeed.
It’s purpose is completely different from what the user can do in the write tab and on the rest of the site.

We should be able do build this kind of tab or if you prefer define as many custom content tabs to reflect the real structure of what’s being edited on the front site.

As you said perfectly: keep the write tab to write articles and play with custom content types elsewhere.

Dale has said it perfectly in the post he mentions above.

Last edited by hablablow (2011-08-22 20:36:22)

Bloke · 2011-08-22 20:44:43

hablablow wrote:

We should be able do build this kind of tab or if you prefer define as many custom content tabs to reflect the real structure of what’s being edited on the front site.

Sure. And that’s easy (see previous definition of ‘easy’).

But today it’ll have to be a plugin with its own tag to putput your data types since it wouldn’t (and shouldn’t!) store the data in the textpattern table. In future, who knows.

Bloke · 2011-08-22 20:51:16

Perhaps I should clarify ‘easy’ more: conceptually it’s simple to create new fields on the fly. Heck, smd_bio does it. The tricky thing is storing the data because, unless you know what you’re doing, having an SQL table for each content type is often wasteful. smd_bio gets away with it because it’s only storing one ‘type’ of data: biographical info.

Conversely having one table to store any type of content is too limiting (cf. the current situation). Some middle ground of having ‘use cases’ in mind and then building a table structure such that differen’t ‘types’ could be defined and there are already slots for the data (albeit if their MySQL ‘type’ is deferred until runtime instead of out of the box) is very messy. And in that case someone’s bound to say “but I wanted to store a date in that field and make sure it’s valid and between X and Y” and then we’re back to the current situation of it being too limiting.

It’s difficult to get away from the fact that true custom content types require knowledge of the underlying storage mechanism if the database is to remain efficient, lightweight and general purpose enough that people can use it without a massive learning curve. That’s contra to Txp’s ethos. And I’d wager that 75-80% of people are more than happy with the simple — albeit limited — scope of today’s article-centric Txp*.

I would far rather enable the core to have the capability to more easily define custom types and then leave it to plugins to do the heavy lifting if required, rather than code the interface and only please 10% of power users. Of course, I’m no guru when it comes to this stuff so someone will no doubt (hopefully) prove that it really is “easy” to do this for mass consumption, and my current thinking is wrong.

*arguments over whether this has limited the user base are out of scope :-p

Last edited by Bloke (2011-08-22 21:00:57)

frickinmuck · 2011-08-22 20:53:35

philwareham wrote:

‘Partials’ or ‘Includes’ is much more logical labelling than the current ‘Forms’. I’d also be quite happy for the pages/includes to all be housed in a single editor page as long as you could differentiate between the two if you wanted to.

Agreed. And I am partial to the term “partials”. :^)

els · 2011-08-22 21:02:44

bornpilot wrote:

I don’t know if textpattern is on it’s way out or is there active development for the future. (…) Any encouragement on active development and a road plan for textpattern?

What a question to ask in this very topic :) Did you read it at all?

aswihart · 2011-08-22 22:11:06

I’m not sure how much to consider people asking for custom content types “power-users”. I think most average Joes making a website with Txp come fairly rapidly to the point where they need to make something that isn’t quite an “article”, and then goes and learns about custom fields and using bot_wtc to simulate the desired result.

It’s hacky, and if nothing else, it shouldn’t require a plugin to be able to customize the Write tab. As Guillaume said, without bot_wtc, the Write tab becomes a disaster quickly. Big kudos to redbot for making bot_wtc. But, I do appreciate the benefits of the current article-centric approach of Txp from a developer’s point of view.

Still, if we could create new content-types on the fly using some kind of wizard, generating new custom Write tabs, a new database table, and new txp:custom_type tags, it would be magical. That’s something that would set Txp apart. It’s big a feature that would need a lot of thought and effort, but it’s one that I’ve heard requested on this forum for years by the most passionate Txp users.

What are the devs thinking about Escher with regards to this? Sam does seem to have some kind of solution going with his Pages, Page Parts, and Models in Escher. Pages and Page Parts live in single big tables, representing a variety of content types. This isn’t far removed from the omnipotent Article in Txp, but it’s a step in the right direction. Maybe a solution that actually generates new tables in the database for each content-type is not worth the effort from a programming or performance perspective.

Bloke · 2011-08-22 23:15:51

aswihart wrote:

I’m not sure how much to consider people asking for custom content types “power-users”.

Maybe I was being unduly harsh, sorry. What I meant and probably didn’t communicate effectively was that — with the best will in the world — I cannot anticipate how someone will intend to use such a huge feature. So writing an interface to do it will only please about 10% of users and be deemed too limiting or too complex for others. In terms of time invested in developing an interface, that’s not a good return so I’d rather put the effort into enabling Txp to handle custom content types more easily but leave implementation details to plugins to suit specific use cases.

Take ‘video’ as an example. A video is a special type of file so you could in theory set up a file category called ‘video’ and get people to upload them via the Files tab (or FTP if they are big). There are no special fields required — perhaps an associated image might be handy, but it fits fairly well into a ‘file’ context.

If the video is online somewhere, it’s a Link, right? Description, title, sort order, URL. Just set a category of ‘video’ and you can capture that content type right now, and distinguish it by category on the site itself.

Similarly, a Google Maps URL is a Link. Don’t use an article for it: get people to enter it in the Links tab and choose the appropriate ‘map link’ category so you can differentiate on the site. If you want to associate it with an article, put the article ID in the sort order or name field, or something inventive like that.

To some people that’s not good enough. They want a dedicated tab that says “Video” dammit because that’s what the client understands! And they want to validate the input in the width and height boxes to between useful boundaries. Fair enough, I’d like to be able to get to a point where it’s technically feasible for a plugin to please that person without too much trickery.

IMO, the API is where this power comes from, not necessarily the user interface. Txp has article, file, image, link. If we manage to build tables and an API that allows custom types, the core itself may well use the API to ‘build’ those 4 base types. If it’s simple and obvious to add a tab that allows building of custom types it may well see the light of day in the core but I suspect the use cases are so varied that it’d overcomplicate and bloat the core to do so natively. Just thinking out loud as I’ve not actually studied this in detail yet.

need to make something that isn’t quite an “article”, and then goes and learns about custom fields and using bot_wtc to simulate the desired result.

Custom fields have caused untold confusion over the years, mainly because of the backwards way they are defined and the fact they can clash with other txp:article attributes and can’t be filtered if they contain spaces and are only confined to articles and there are only 10, blah blah. Namespaced custom fields for all built-in types would be a big first step towards breaking the limitations.

But here comes the problem: someone would be happy with using 4 new fields for Images and telling users when to use which ones. Someone else might want the available CFs to change when the Image Category was altered. Someone else might want 4 different brand new tabs under a new top-level tab to capture the basic info and the relevant CF for each type.

The same argument as above is valid here: how do we code an interface that can help all 3 use cases? Answer: with great difficulty. So why not use the effort instead to allow the core to help 3 plugins be built to suit the 3 use cases? You get the desired functionality with no unnecessary overhead.

it shouldn’t require a plugin to be able to customize the Write tab.

It doesn’t. You can do that in the theme if you like. Stuart’s done it very successfully on other tabs in Vitraux to shunt things around, remove ‘unnecessary’ things like the tag builder and so on. It depends on the level of customisation of course and I guess a lot of redbot’s great effort went into figuring out how to get round the awful table-based layout of the Write tab rather than the job of actually doing the plugin’s stated function.

Here again is where I want to focus effort: I’d rather ease redbot’s task as a plugin writer by making the interface and markup leaner and more flexible than write a core tab to allow you to customise the Write tab. Because someone else will want to customise the Files tab. Or move Pages from Presentation to Content. The core should allow these functions with ease: the specific way they are moulded and applied should be up to the individual site owner and plugin authors to write either very specific or general purpose plugins to appeal to certain cross-sections of potential administrators.

Anyway, rambling over. Bottom line is probably that I don’t know how to do it myself so I’m coming up with reasons not to do it! If someone else can do it then I say bring it to the table.

Last edited by Bloke (2011-08-22 23:19:48)

aswihart · 2011-08-22 23:55:47

I here you Stef, that all makes sense. What about Escher, have you had a chance to consider Sam’s work with Pages / Parts / Models?

artagesw · 2011-08-23 01:07:21

aswihart wrote:

What are the devs thinking about Escher with regards to this? Sam does seem to have some kind of solution going with his Pages, Page Parts, and Models in Escher. Pages and Page Parts live in single big tables, representing a variety of content types. This isn’t far removed from the omnipotent Article in Txp, but it’s a step in the right direction. Maybe a solution that actually generates new tables in the database for each content-type is not worth the effort from a programming or performance perspective.

My personal opinion is that two separate tables, one for pages (Escher pages, not Txp pages) and one for parts, strikes the right balance between flexibility and complexity. A table-per-content type seems overkill. It also complicates certain functionality. For example, how do you search across content types that are stored in disparate tables, some of which are not core, and therefore unknown to the core search mechanism? That’s just one example off the top of my head. There are others.

The beauty of Escher’s approach is that it yields unlimited content types with no schema changes, and every piece of content – regardless of type – is encapsulated by a page, and is therefore a bona fide addressable resource with its own unique URL. If we were to apply this approach to Txp5, the “article” as a special content type goes away, giving way to the page. Whether this is too drastic a change for Textpattern remains a topic for discussion.

aswihart · 2011-08-23 01:57:28

I think you guys understand this issue well and will do what’s best for Txp. Thank you.

hablablow · 2011-08-23 12:31:14

Yes, thank you to the devs for considering, discussing and clarifying this request, seriously.

As Stef suggests, I’m not sure if this feature would be mainstream but I’m sure it would bring something totally unique to Txp.

A couple of additional thoughts.

I think we should keep a distinction between forms and pages and not mix them in a single bag. I agree on the fact that technically there’s no difference between them but it’s rather a matter of perception. Pages add a top shelter to forms in the flow of perception just as you you need titles above a paragraph. Remove these titles and you end up with a blurry, unstructured amount of text. Same for pages, they structure the forms below. Put everything in one place and you’ll loose clarity.

Something different, and I don’t know if this has been implemented in the lastest versions of Txp, but I usually have more than 10 tabs of forms open and I never know which one was the latest version I edited, talking of the same form. Could we have the same time stamp as for articles but for forms, such as: last edited on the… At 10pm..

Last edited by hablablow (2011-08-23 12:32:37)

hcgtv · 2011-08-23 13:04:19

bornpilot wrote:

I don’t know if textpattern is on it’s way out or is there active development for the future. (…) Any encouragement on active development and a road plan for textpattern?

Els wrote:

What a question to ask in this very topic :) Did you read it at all?

Textpattern is a small project, with a small team of volunteer developers, who have lives outside of Textpattern. Whatever time they can give to the project is much appreciated by all. That being said…

The enthusiasm in this thread could be better utilized on a distributed version control system like GitHub. The issue tracker could serve as a road plan of sorts that’s being ironed out, rather than having a long forum thread with all kinds of requests with subsequent replies that is very confusing to follow.

Then we can point new users like bornpilot to this GitHub repository and say, here, this is our future.

Textpattern CMS

Textpattern CMS support forum

#205 2011-08-22 20:22:42

Re: The direction of Textpattern 5

#206 2011-08-22 20:44:43

Re: The direction of Textpattern 5

#207 2011-08-22 20:51:16

Re: The direction of Textpattern 5

#208 2011-08-22 20:53:35

Re: The direction of Textpattern 5

#209 2011-08-22 21:02:44

Re: The direction of Textpattern 5

#210 2011-08-22 22:11:06

Re: The direction of Textpattern 5

#211 2011-08-22 23:15:51

Re: The direction of Textpattern 5

#212 2011-08-22 23:55:47

Re: The direction of Textpattern 5

#213 2011-08-23 01:07:21

Re: The direction of Textpattern 5

#214 2011-08-23 01:57:28

Re: The direction of Textpattern 5

#215 2011-08-23 12:31:14

Re: The direction of Textpattern 5

#216 2011-08-23 13:04:19

Re: The direction of Textpattern 5

Board footer