The direction of Textpattern 5

tumain · 2011-08-15 10:31:56

maruchan wrote:

“Partial” is becoming a really common term for our form functionality, in the CMS world anyway. I like it better than module, snippet, chunk, include, and widget. :-)

I agree with the term Partial instead of the others.

This topic has already issued improving usabilty and some have mentioned removing some of the core and making them plugins instead. There are some plugins that I think would attract more people to use Textpattern, if they’re included to begin with:

ebl-image-edit in core
ability to upload/add mutiple images within article (not sure how the existing one works, since I’ve not used it, but I imagine a button that opens up a gallery of images you have uploaded, and clicking one puts it into the article in textile)
new commenting system (some may disagree but I’m not entirely keen on having both the Preview and Submit button)
ability to install plugins similar to how Wordpress handles installation

Are there any thoughts on having different downloadable Textpattern packages, depending on what the user wants (i.e. a blog, cms, photo gallery). One could be the most basic (no plugins). Another could have all the plugins ready for a different kind of site (image gallery plugin, zem_contact, etc…)?

EDIT: Got confused with plugin names…

Last edited by tumain (2011-08-15 17:37:42)

MattD · 2011-08-15 16:30:06

I believe the update image functionality in the core can do what upm_image does.

tumain · 2011-08-15 17:31:53

Ah silly me – I meant ebl_image_edit (* goes to edit post *).

aswihart · 2011-08-15 18:03:29

I dunno man, there’s always people asking for this and that to go into core. The downside is you don’t get any updates to what was formerly a separately maintained plugin, until someone on the core team decides to work on it, and until a new version of Txp gets released.

There’s something to be said for making the core as lean as possible. For example, I love bot_image_upload. It’s the best image uploading / selecting plugin solution for Txp, no question. But it’s best for redbot to maintain that plugin. As with many of the responsive plugin authors here, if you notice a bug, a new version is often issued in days if not minutes, whereas Txp releases are, relatively speaking, few and far between.

tumain · 2011-08-15 18:40:48

Good point.

Only reason I suggested ebl-image-edit to be in the core, is since I thought it would be the core functionality to stand out to newcomers; but I agree with what you’re saying. I definitely do feel that the user should be able to upload multiple images though and within the article, without the need of a plugin. It just feels like something you’d expect as a given.

maruchan · 2011-08-15 19:01:51

It just feels like something you’d expect as a given.

I have a client who loves typing in image numbers. He can understand how the entire system works without needing any extra context. I installed bot_image_upload and he didn’t like it. So I just have bot_admin_tooltips installed with little tooltips that have links to the Images or Files tab.

I get nothing but compliments about the site from this client, and before that we had a lot of great features, more powerful than bot_image_upload, that he felt were useful but too complex.

But there are different types of end users for Textpattern. My example comes from a “Webmaster —> Non-technical Staff member” relationship standpoint. People who want all the extra features default might come from a “Budding Webdesigner” standpoint, for example. They may feel that complexity has some big benefits and dislike that the admin front-end seems less fancy than other CMS software.

From my standpoint, I end up pulling more out of other CMSes, so Textpattern is great. There is less pulling out to do. But for others who end up installing lots of plugins to feel like they cover every use case, the lightweight core feels like a weakness.

hablablow · 2011-08-17 13:33:10

I declare the writte tab, dead.

It’s a relic from an editorial approach, a legacy from Dean’s original idea on what a website was, not so long ago.

That was the semantic era, where text was then king content, held by the leadership of the W3C and the promotion of the web standards. It was Dean’s visionnary approach to embrace and support these standards very early that made us all shift to Textpattern.

Textpattern was then the perfect bridge between Dean’s former experiences as a book editor and what would become the standards of web publishing and the semantic web.

On the complicated path the web is heading to today, with browser manufacturers pushing for inovation every single day and in every directions, the mosaic of new devices, the new server technologies, the lack of leadership by the W3C, resulting in a set of clumsy HTML5 specs, nobody can tell what the web will look like in 5 years.

It’s a set of features, not a clear roadmap.

Simplicity and elegancy are well established in Textpattern, but we need to go for more flexibility.

The writte tab currently allows everything but adds a complicated layer of abstraction between what’s being operated back-end and what will happen on the front-side.

That is where templates could come into the game, allowing us to create specific tabs under the writte tab and add as many custom fields of any types we need, reflecting so the real structure of a front-side page, instead of tweaking a single writte tab where all the magic happens.

I see a also a future for Txp in it’s community, in re-organising it’s visibility. We must unify and perhaps adopt a brand strategy under what has already been built under the main site.

The few examples on the main site are great, I know it very well, I’ve designed the first one. But it’s not enough.

The plugin site should be redesigned and focus perhaps on the most popular plugins and orphan plugins to adopt. I remember Desandro has showed some mockups on his site.

I trust the devs. I want also to be able to travel the core files and tweak them if necessary to suit my needs. I’m afraid that if we rely on another set of files, outside the core, they are certain files that will become too complicated to adjust our needs.

We need leadership based on strong ideas, not a set of feaatures.

mrdale · 2011-08-19 02:25:05

I declare that the write tab is for writing… and that I’ll have another…

net-carver · 2011-08-20 20:30:05

Regarding plugins (and core-provided tags); is there going to be some core support (by naming convention, explicit declaration via a call, or whatever) for white-listing tags?

As a plugin author I’d actually like to be able to declare which of my functions are tags for the tag parser. I realise, this would mean a compatibility problem for plugins but was wondering if the Txp5 crew have any plans afoot for such a feature.

artagesw · 2011-08-20 21:41:56

In Escher, functions do not automatically become tags. They need to be explicitly prefixed. There are backward-compatibility issues to consider with Txp5, of course.

net-carver · 2011-08-20 22:07:31

artagesw wrote:

In Escher, functions do not automatically become tags. They need to be explicitly prefixed. There are backward-compatibility issues to consider with Txp5, of course.

Hi Sam, thanks for the reply but it doesn’t really answer my question wrt Txp.

Yes, understood, there would indeed be compatibility issues for plugins but I’d like to prompt some thought/discussion about this area if there hasn’t been any yet. If the answer is ‘undecided’ that’s ok with me but it’s something on my radar for Txp in general following the findings by Mr. Poole.

aswihart · 2011-08-20 23:00:54

Sam — As I understood it Spark/Plug is very lightweight, so I’d think you aren’t going to be forced to follow many conventions. But is there something fundamental about the way Spark/Plug works that makes your references to Escher relevant to this discussion? Or are your comments meant more as an offering of your specific solution to mimic in Txp5? Sorry if I’m out of the loop here.

Last edited by aswihart (2011-08-20 23:21:12)

Textpattern CMS

Textpattern CMS support forum

#181 2011-08-15 10:31:56

Re: The direction of Textpattern 5

#182 2011-08-15 16:30:06

Re: The direction of Textpattern 5

#183 2011-08-15 17:31:53

Re: The direction of Textpattern 5

#184 2011-08-15 18:03:29

Re: The direction of Textpattern 5

#185 2011-08-15 18:40:48

Re: The direction of Textpattern 5

#186 2011-08-15 19:01:51

Re: The direction of Textpattern 5

#187 2011-08-17 13:33:10

Re: The direction of Textpattern 5

#188 2011-08-19 02:25:05

Re: The direction of Textpattern 5

#189 2011-08-20 20:30:05

Re: The direction of Textpattern 5

#190 2011-08-20 21:41:56

Re: The direction of Textpattern 5

#191 2011-08-20 22:07:31

Re: The direction of Textpattern 5

#192 2011-08-20 23:00:54

Re: The direction of Textpattern 5

Board footer