The direction of Textpattern 5

bornpilot · 2011-08-22 16:33:04

I am looking to create a professional blog and I have narrowed my choices to either wordpress or texpatter however, I don’t know if textpattern is on it’s way out or is there active development for the future. My background is in Textpattern. Any encouragement on active development and a road plan for textpattern?

mrdale · 2011-08-22 17:19:07

hablablow wrote:

I would like to avoid a user to have up to 10 custom fields every time he is writing something.

bot_wtc

hablablow · 2011-08-22 17:57:30

bot_wtc switches fields visibility upon sections, only after a certain section or another, has been choosen by the user in the section dropdown.

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

renobird · 2011-08-22 18:45:07

Sam,

Thank you for this post above. That clears up a lot and is very good news.

:)

aswihart · 2011-08-22 19:41:01

hablablow wrote:

bot_wtc switches fields visibility upon sections, only after a certain section or another, has been choosen by the user in the section dropdown.

I see what you mean, we are just using JQuery to make it look like we’re editing a different type of content (different section) when really they’re all just Txp articles with different custom field inputs.

If I follow you I think you are just asking for proper custom content types with unique Write tabs for each type. Personally, I think the Write tab as a concept is entirely sensible. Is it the name that bothers you? Whatever you want to call it, it’s just a form for adding / editing various content-types, with inputs for all of that content-type’s fields.

hablablow · 2011-08-22 19:59:55

aswihart wrote:

If I follow you I think you are just asking for proper custom content types with unique Write tabs for each type.

Exactly.

I didn’t say I disliked the write tab, I just said it’s not enough anymore and can become very fuzzy for editing different types of content in various areas of a website when you sometimes just need to edit short values such as: name, date of birth, Facebook link etc… Cases when you do not need to post a full body of text.

In short the write tab is not tailored to edit micro-content.

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

mrdale · 2011-08-22 20:03:04

aswihart wrote:

bot_wtc switches fields visibility upon sections, only after a certain section or another, has been choosen by the user in the section dropdown.

hablablow wrote:

I see what you mean, we are just using JQuery to make it look like we’re editing a different type of content (different section) when really they’re all just Txp articles with different custom field inputs.

zackly. In the absence of a retooled method of handling custom content types, it does get you some of the way there… Incidentally my desire for full-fledged CCTs for TXP dates back to the early bronze age.

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

We talk exactly about the same stuff Dale.

Imagine being able to create images, albums, movies, cars, events, books, products— all as content-types all with their own discreet place in the content tab.

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

Bloke · 2011-08-22 20:12:49

hablablow wrote:

to have a full set of write options just to update his date of birth or add a Google Maps link, is not so friendly and adds a noisy experience.

Sorry I don’t get it. If you’re storing a date of birth in an article custom field, that implies that an article is used as a profile. From a purist viewpoint isn’t smd_bio / txp_users table a better place for that type of data?

With a Google Maps link, I don’t follow the logic either. If your map is related to an article — which is implied because it’s a custom field attached to an article — why would you want to allow someone to create an article with no CF data then have to save / publish the article, visit another tab, reselect the article from a list (or something) and then assign only the custom field(s) data that is permitted for articles in that section?

Or do you mean ditch the Write tab completely and create a “Google Maps” tab that, behind the scenes, sets up hidden fields ready to create an article in a dedicated section and on the screen only has one or two input fields: Location (URL) (a CF) and Name (Txp’s Title) perhaps. Then another tab for creating other ‘types’ of article that only shows dedicated fields to the user – e.g. no Status options, no Publish date / time, no Excerpt, no Article Image input, etc.

Maybe I just don’t understand your intended workflow.

I can create additional tabs and use custom fields in it but it requires at least two additional plugins and some voodoo.

If you need that level of customisation and you prefer all your users to have it across multiple sites then could it be a write-once, install on many sites experience? Either a dedicated plugin or smd_tabber and some page template trickery plus a single line mod to the theme’s CSS to shut off the Write tab’s CF area. smd_user_manager could remove the Write tab for all users if you don’t see a need for it, and it gives you more detailed control over your users too, which sounds like it might suit your type of ‘power’ sites.

As I say I’m not sure on the workflow you are trying to achieve. Perhaps when I get it and the penny drops I’ll see why it’s a serious limitation in the current Txp.

EDIT: should have waited and read your previous posts. I get it now. But if you’re using the article tab for micro format info then I’d suggest it’s not the right place for it at all. Links work better. And failing that, a custom, plugin dedicated to micro format data (as I alluded to above) is easily¹ achievable. An article is an article is an article. Custom fields blur the line a bit, but an article should not be used for non-article data. It’s a waste of space for starters and a waste of effort for users to be told to ignore certain areas of the screen.

¹ easy, not quick. We can do anything, we just can’t do everything :-)

EDIT2: won’t adi_matrix help?

Last edited by Bloke (2011-08-22 20:19:29)

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.

Textpattern CMS

Textpattern CMS support forum

#196 2011-08-22 16:33:04

Re: The direction of Textpattern 5

#197 2011-08-22 17:19:07

Re: The direction of Textpattern 5

#198 2011-08-22 17:57:30

Re: The direction of Textpattern 5

#199 2011-08-22 18:45:07

Re: The direction of Textpattern 5

#200 2011-08-22 19:41:01

Re: The direction of Textpattern 5

#201 2011-08-22 19:59:55

Re: The direction of Textpattern 5

#202 2011-08-22 20:03:04

Re: The direction of Textpattern 5

#203 2011-08-22 20:05:20

Re: The direction of Textpattern 5

#204 2011-08-22 20:12:49

Re: The direction of Textpattern 5

#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

Board footer