The direction of Textpattern 5

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.

philwareham · 2011-08-23 13:19:52

I agree that Github would be a massive benefit to the project, not least because some of the development burden could be shared by willing contributors. The core devs could cherry-pick any pull requests that suit the philosophy of the project.

aswihart · 2011-08-23 13:44:33

+1 Github is awesome

Bloke · 2011-08-23 13:52:39

philwareham wrote:

Github would be a massive benefit to the project, not least because some of the development burden could be shared by willing contributors. The core devs could cherry-pick any pull requests that suit the philosophy of the project.

Github, Mercurial. Same animal, different breakfast. Either way, that is the plan. Should have happened by now, hasn’t, sorry. But I’m on the case now the holiday season is over and we have some free(ish) time between us.

Part of the delay has been the CSRF thing (which the new version of Spark/Plug (imminent) will bring us, along with some other loveliness), part time constraints, part thinking / planning / taking requests on board.

Once we’ve put together a screen or two to show the sort of M/V/C split we’re adopting and started work on some of the convenience libraries, we’ll open up the repo to the community and encourage contributions for pull requests. Once the admin side is modelled as we have it today (so we know we haven’t missed anything with the migration) we can begin the serious work of porting Phil’s theme work over and fixing the database to deliver all kinds of future goodies.

This may end up with v5.0.0 looking very similar, if not identical, to 4.4.1 but with a different framework underneath and then incremental 5.x.x releases (hopefully at a faster release rate than we’ve traditionally been used to because the framework allows this) bringing in the various goodies talked about here and there, and chasing stuff down on an issue tracker as things move forward. That approach also gives plugin authors plenty of time to get to grips with the new way of doing things so we can hopefully limit the fallout.

One thing we’re keen to adopt is a testing framework like PHPUnit so we can minimise introducing regressions. That’s the primary motiviation behind doing a straight port of 4.4.1 to 5.0.0 so we can write the same tests on both and check we’ve caught every possible edge case. If anyone has any experience with writing tests for that tool, or has recommendations on one framework over another, please holler, otherwise we’ll go with PHPUnit and have to live with it.

Again, sorry for the huge delay. And remember this is only a rough plan not a roadmap and is subject to the usual fluctuations in the space-time continuum!

Last edited by Bloke (2011-08-23 13:56:27)

philwareham · 2011-08-23 14:10:34

Bloke wrote:

Once the admin side is modelled as we have it today (so we know we haven’t missed anything with the migration) we can begin the serious work of porting Phil’s theme work over and fixing the database to deliver all kinds of future goodies.

I’ve been on holiday last week but I’m going to do some substantial work on my admin side structure project this coming weekend. I’ve rewritten the existing TXP4 write, category and article list pages in HTML5 along with some (hopefully) more logical classnames, structure and tags already.

Once I’ve duplicated all the current TXP4 admin pages in HTML5 I’ll encourage people to look over the code and make any suggestions on how it can be further improved. That’s also where the fun begins with theming.

And I’ve pretty much finished the front-side theme apart from sorting out some language strings and a couple of lingering bug fixes that have been reported.

net-carver · 2011-08-23 15:30:38

Re: GitHub

Looks like this might have flown under people’s radars but Textpattern is available on github — and has been for some time. Graeme and I started the github mirror some time ago and it tracks the SVN commits well. Should the core team wish it we’ll gladly hand the keys to the github account over. We grabbed the ‘textpattern’ user account to make sure it was…

available to the core team should they want it and to…
maintain a mirror if they didn’t.

So people are already free to fork Textpattern on github & make changes. But pull requests are disjoint as they would come to Graeme and I rather than direct to the core devs.

PS. I also believe our very own Manniqui has a repository that also tracks the SVN sources.

mrdale · 2011-08-23 15:39:46

OK, regardless of all my bellyaching about CCTs in TXP (and at risk of pissing off previous Devs who worked very had on TXP), IMHO this Dev team is by far and away the best at creating a clear strategy for TXP, detailing features and sharing them, and producing meaningful updates on a regular basis.

Awesome work guys. It’s exciting to watch.

michaelkpate · 2011-08-23 18:27:44

net-carver wrote:

Looks like this might have flown under people’s radars but Textpattern is available on github — and has been for some time. Graeme and I started the github mirror some time ago and it tracks the SVN commits well. Should the core team wish it we’ll gladly hand the keys to the github account over.

We sort of discussed the existence of the repository a while back, although it is not the most coherent thread.

Bloke wrote:

Github, Mercurial. Same animal, different breakfast.

According to some guy named Linus Torvald, “Two systems worth looking at: git and Mercurial. The others with good features are too slow [for large projects].” If you aren’t on Windows, you may not care.

net-carver · 2011-08-23 19:08:12

Michael wrote:

We sort of discussed the existence of the repository a while back, although it is not the most coherent thread.

That discussion flew under my radar.

ruud · 2011-08-23 20:11:41

michaelkpate wrote:

According to some guy named Linus Torvald, “Two systems worth looking at: git and Mercurial. The others with good features are too slow [for large projects].” If you aren’t on Windows, you may not care.

LOL… they all are fast enough for a tiny project like TXP.

Textpattern CMS

Textpattern CMS support forum

#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

#217 2011-08-23 13:19:52

Re: The direction of Textpattern 5

#218 2011-08-23 13:44:33

Re: The direction of Textpattern 5

#219 2011-08-23 13:52:39

Re: The direction of Textpattern 5

#220 2011-08-23 14:10:34

Re: The direction of Textpattern 5

#221 2011-08-23 15:30:38

Re: The direction of Textpattern 5

#222 2011-08-23 15:39:46

Re: The direction of Textpattern 5

#223 2011-08-23 18:27:44

Re: The direction of Textpattern 5

#224 2011-08-23 19:08:12

Re: The direction of Textpattern 5

#225 2011-08-23 20:11:41

Re: The direction of Textpattern 5

Board footer