Textpattern CMS support forum

You are not logged in. Register | Login | Help

#41 2019-03-24 14:12:03

Vienuolis
Member
From: Vilnius, Lithuania
Registered: 2009-06-14
Posts: 177
Website

Re: Textpattern Next Non-Patch Version Roadmap

Before asking for new features, we should first understand the actual level of quality we stand on. You are to be congratulated for truly excellence of the publishing loom. Textpattern is an exceptionally unique CMS, with no competition on the net. The first concern is to maintain this level.

To gain more popularity we could engage savvy publishers and smart designers by explaining the correct publishing flow and key features of our Textpattern, rather destroying it with attractive drag & drop, wysiwyg and similar gadgets.

Simple, easy, elegant — too trivial market words, suitable for everyone. As I understand, in the base of Textpattern power, security, and flexibility is the clear and ultimate separation principle, decided initially by Dean Allen. A designer do not need PHP code, and a publisher do not need even HTML tags. Not only content and presentation, HTML and CSS, text and hypertext, PHP and TXP:tags (XSL and SSI replacement), sections and categories for articles, images, files, links are properly separated, too.

If you wish 5th version, name it for the theme management — a huge step forward. If you wish some new yet useful feature, try adopt API for Panda (TinyPNG.org) — very effective image compressing tool, I am using it every day. Sorry, I am not a programmer to DIY.

Last edited by Vienuolis (2019-03-24 14:17:15)

Offline

#42 2019-03-24 15:35:10

GugUser
Member
From: Quito (Ecuador)
Registered: 2007-12-16
Posts: 1,400

Re: Textpattern Next Non-Patch Version Roadmap

Vienuolis wrote #317278:

Before asking for new features, we should first understand the actual level of quality we stand on. You are to be congratulated for truly excellence of the publishing loom. Textpattern is an exceptionally unique CMS, with no competition on the net. The first concern is to maintain this level.

To gain more popularity we could engage savvy publishers and smart designers by explaining the correct publishing flow and key features of our Textpattern, rather destroying it with attractive drag & drop, wysiwyg and similar gadgets.

You said it very well.

Offline

#43 2019-03-24 16:27:27

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,622
Website

Re: Textpattern Next Non-Patch Version Roadmap

Vienuolis wrote #317278:

we could engage savvy publishers and smart designers by explaining the correct publishing flow and key features of our Textpattern, rather destroying it with attractive drag & drop, wysiwyg and similar gadgets.

Completely agree. As can be seen by the WordPress Gutenberg debacle, people don’t necessarily want to be able to make articles by dragging and dropping blocks around. It sounds wonderful to marketing people and coders, but do real users find it intuitive or useful? Not yet, it seems.

In the same vein, WYSIWYG editors tend to make horrible markup and, as you say, often rely on in-page hard-coded formatting, which is horrible to unpick in future and very inflexible.

That’s why I’m striving for a toolbar like Jukka’s plugin implementation, which is a Textile toolbar. If we support Markdown in core (which I got 95% of the way through and then abandoned because a plugin actually worked better at the time) I’m fine with a toolbar that inserts Markdown code into the article as well.

But the key is that a toolbar should – if possible – insert codes for one of our supported markup languages and NOT raw HTML if we can possibly avoid it. I don’t mind if it inserts little bits of HTML if there are no direct equivalents, or we allow people to customize the toolbar to insert whatever they need in their publishing workflows. That’d be ideal. We allow HTML in Body anyway, so a toolbar could do likewise.

If we can make a seamless real-time preview available if people want it, we don’t need the Write panel Body tag (or any textarea) to actually contain the yucky HTML produced by an off-the-shelf toolbar. We can still allow manual insertion of markup language, provide a nice WYSIWYG toolbar for inserting codes in that language as a convenience for new users, AND allow people to see what the final result might look like. All by maintaining content separation, flexibility and retaining the distinction between content and its presentation.

Pipe dream? I hope not. But that’s why I’ve been dragging my feet on this as I’m keen to keep the traditional Textpattern publishing spirit alive whilst also making it attractive for new users, without the baggage of off-the-shelf bloaty and difficult to maintain toolbar output.

Last edited by Bloke (2019-03-24 16:31:35)


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#44 2019-03-24 16:44:54

bici
Member
From: vancouver
Registered: 2004-02-24
Posts: 1,446
Website

Re: Textpattern Next Non-Patch Version Roadmap

Vienuolis wrote #317278:

If you wish 5th version, name it for the theme management — a huge step forward. If you wish some new yet useful feature, try adopt API for Panda (TinyPNG.org) — very effective image compressing tool, I am using it every day. Sorry, I am not a programmer to DIY.

thanks for the link. i am going to test drive the TinyPNG ExpressionEngine Add-on


…. texted postive

Offline

#45 2019-03-24 18:39:18

etc
Developer
Registered: 2010-11-11
Posts: 3,145
Website

Re: Textpattern Next Non-Patch Version Roadmap

Nothing is set in stone yet, we are just testing different input methods. And main parts of it (like Textile input/output) are yet to be written.

I agree that most WYSIWYG editors pollute the code way too much. We will certainly not keep MediumEditor in core, a plugin is easy to write. But ProseMirror is much less intrusive and much more configurable. I think it’s not really different from Textile or Markdown toolbars. Why should we mind wrapping a text in <strong /> instead of * while editing if this allows for a preview and if the conversion is easily done? ProseMirror Markdown example looks fine.


etc_[ query | search | pagination | date | tree | cache ]

Offline

#46 2019-03-24 18:51:00

etc
Developer
Registered: 2010-11-11
Posts: 3,145
Website

Re: Textpattern Next Non-Patch Version Roadmap

phiw13 wrote #317269:

If I understand you correctly, inserting a txp:short-tag (e.g. to insert an image) won’t work, as in, the tag will not be parsed at all. I don’t really mind if it is not rendered in the editor, but it would be nice if it is rendered in the final page.

All tags are converted to plain text atm, but Markdown example suggests that preserving some tags should be possible.

The preview/code in a dialog you were showing in a previous post up thread, that is part of the custom fields branch, right? Is that branch kinda usable now – without jumping through weirdo commands to get the DB to work?

A fresh install is usable (though absolutely not stabilized yet), but there is no to_4.8 update script.


etc_[ query | search | pagination | date | tree | cache ]

Offline

Board footer

Powered by FluxBB