Textpattern CMS support forum

You are not logged in. Register | Login | Help

#31 2019-03-21 16:51:23

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

Re: Textpattern Next Non-Patch Version Roadmap

ia278 wrote #317208:

The crucial things

Agree.

The extremely useful things

This is probably where we differ in approach. For me, embedding pictures inline within (say) Body text as an <img> tag somewhat defeats the purpose of content separation and templating. But I can see why it’s a draw due to the way Txp is currently set up with fairly rigid boundaries between content types.

Putting image references in the article image field gives way more scope for placing those images in templates around the content, but you can’t (easily) embed them inline with text if you want to pepper the article with them. Conversely, once they’re embedded inline, that’s it. You need to revisit every article to make changes in future.

Placing an image inline is handy BUT doing it by embedding a <txp:image> or <txp:images> tag would be better than an HTML <img> tag, imo. Even better still, would be to somehow offer the ability to embed a shortcode (<txp:output_form form="image" id="45, 46, 47, 48" /> for example, where the numbers are the image ID that have just been uploaded and added to the DB when you selected them from your computer via the WYSIWYG toolbar). That Form could then control the surrounding markup so you could make changes to your images (class names, etc), automatically add captions in <figcaption> tags and so forth based on the metadata associated with each image.

The problem I have with pure HTML-based editors is that they make a rod for your own back if you ever decide you want to freshen up your layout in future. If we can find some happy medium between the following I’ll be happy:

  • immediacy of implementation for those people who just don’t care and want an image hard-coded in their content.
  • ability to upload images from the WYSIWYG tool and have them added to the database and either directed to the article image or embedded, if that’s your whim, via txp: tags.
  • ability to specify what gets inserted when you operate the WYSIWYG tool. So advanced users can customize the tag and leverage the power of the CMS and its content separation with the convenience of embedding and previewing content on-the-fly.

There are plugins that go some way towards doing some of each of the above, to varying degrees, but no one-size-fits-all yet.

Last edited by Bloke (2019-03-21 16:57:08)


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

#32 2019-03-21 17:03:49

philwareham
Core designer
From: Farnham, Surrey, UK
Registered: 2009-06-11
Posts: 3,190
Website

Re: Textpattern Next Non-Patch Version Roadmap

I’m in agreement with Bloke on inserting media. The most flexible way of inserting images (and indeed other media) is to use a ‘shortcode’. This keeps content separation and means that if you overhaul your site in future you can simply change the code within the shortcode to amend the whole site. This is especially pertinent in an era of responsive images and high pixel density screen displays. You simply can’t achieve this with a simple media embed.

See example (video) shortcode code here and instructions on use here.

Where we do agree is that finding the images and their IDs is not intuitive right now (you have to go to the images panel to find it) but we have plans on integrating that directly in the write panel for 4.8 onwards.

Offline

#33 2019-03-21 18:39:41

ia278
Member
From: UK
Registered: 2018-11-07
Posts: 17
Website

Re: Textpattern Next Non-Patch Version Roadmap

I might have explained my idea badly. Or, it might just be impossible to implement :-)

I’ve always thought that the body (and excerpt) textareas were text-only. That was until I saw @etc’s Medium editor screenshot, which has got an image in it!

!https://i.postimg.cc/nhwThPNL/medium.png!

If that’s the case (i.e. if textareas can support text and images), then the idea was to use the editor to allow users to write articles how they can on other platforms. So, starting with a block of text, you could perform actions on them (bold, underline, headers etc.) and be able to preview roughly what your article looked like while writing it. Of course, inserting images would give you an even better preview…

The idea behind the image button was this – instead of having to write out <txp:image id="149" /> to insert an image from the database, you’d be able to use the MediumEditor to do it instead! Apart from that, images would work in the same way as previously – so if image #149 was updated, any articles with it in would update as well. I 100% agree that hard coding images into an article isn’t a good idea, especially when it comes to quickly editing them.

From a code perspective, I’ve got no idea if this is possible (I don’t know the TextPattern code situation, or the limits of MediumEditor)! And of course, if the body textarea is text-only, this idea won’t work.

But… yeah, that’s the idea :-)

Bloke wrote #317210:

  • ability to upload images from the WYSIWYG tool and have them added to the database…

I did think about that – but like I’ve said, I don’t even know if the first part is possible yet! :-)

Offline

#34 2019-03-21 20:08:52

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

Re: Textpattern Next Non-Patch Version Roadmap

Bloke wrote #317207:

Going forward (adding 4.7.x features to a 4.7.x branch and merging up into dev) is generally safer than vice versa.

I agree, but they are conflicting (version numbers?), so merging is not automatic.


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

Offline

#35 2019-03-21 20:21:22

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

Re: Textpattern Next Non-Patch Version Roadmap

ia278 wrote #317215:

I’ve always thought that the body (and excerpt) textareas were text-only. That was until I saw @etc’s Medium editor screenshot, which has got an image in it!

Right, textareas are for text only. Medium editor just replaces texareas with editable div and updates them behind the scene with HTML code of the edited rich text. The code itself is generally poor, though.

The idea behind the image button was this – instead of having to write out <txp:image id="149" /> to insert an image from the database, you’d be able to use the MediumEditor to do it instead!

That should be possible by writing an extension to Medium editor, we will see. However, you will not be able to preview images inserted this way, since txp tags are not parsed in previews for various reasons.


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

Offline

#36 2019-03-23 20:15:09

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

Re: Textpattern Next Non-Patch Version Roadmap

MediumEditor can already be tested in dev branch, and ProseMirror is making its way into Textpattern:

!https://i.postimg.cc/zfYZZPwL/prosemirror.png!


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

Offline

#37 2019-03-23 20:45:18

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 3,435
Website

Re: Textpattern Next Non-Patch Version Roadmap

Impressive: great moves here on both input methods! I particularly like the idea of Prosemirror being able to insert textile, but you’re probably showing html there?

One thing that interests me with both these options: can you use txp:tags or txp::shortcodes inside them?

If so, it would be beautiful if there was a method to potentially add admin-definable insert buttons to the taskbar.


TXP Builders – finely-crafted code, design and txp

Offline

#38 2019-03-23 21:43:01

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

Re: Textpattern Next Non-Patch Version Roadmap

jakob wrote #317264:

I particularly like the idea of Prosemirror being able to insert textile, but you’re probably showing html there?

Frankly, I wouldn’t bet on it. We could transform ProseMirror markdown parser into textile, but it would be a very basic one. Moreover, we would need to rethink the editor workflow. What should happen when you switch from ProseMirror to Textile? The source is converted to Textile, I guess. And if you switch to Leave untouched instead, you get HTML source, right? But then the same thing should happen when switching from Textile to Untouched, but it’s not like it presently works. Moreover, for consistency we would need converters between all potential textfilters (Textile, Markdown, etc) and this looks unrealistic.

One thing that interests me with both these options: can you use txp:tags or txp::shortcodes inside them?

Probably with ProseMirror, but not by default – someone must write a schema for txp tags. And since txp is not XML (tags and nested quotes in attributes), that does not look straightforward.

I would not expect more than a basic text writing from WYSIWYG atm, sorry.


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

Offline

#39 2019-03-24 01:03:29

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 1,652
Website

Re: Textpattern Next Non-Patch Version Roadmap

etc wrote #317263:

MediumEditor can already be tested in dev branch, and ProseMirror is making its way into Textpattern:

That sounds great so far. We’re kinda spoiled here… two editors! It is very nice to see them accessible as text filters.

What worries me is this – txp:tags and txp:short-tag:

etc wrote #317265:

Probably with ProseMirror, but not by default – someone must write a schema for txp tags. And since txp is not XML (tags and nested quotes in attributes), that does not look straightforward.

I would not expect more than a basic text writing from WYSIWYG atm, sorry.

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.

—-
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?

Offline

#40 2019-03-24 11:22:31

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

Re: Textpattern Next Non-Patch Version Roadmap

WYSIWYG toolbar reminds me former deprecated ‹center›, ‹font size=”“›, ‹font color=”“›, and looks like an attempt to replace them with formally valid ‹p style=”“› tags. Every such toolbar breaks the design concept, defined once by stylesheet.css, because there are no align, size or color alone, though.

I could imagine some buttons like [dl] with default settings of a style sheet from an <article> editable </article> section only. With supplemented drop-down list of another article dl.class {}, like [numbered dd], [inline dd] or so. And similar [ol], [ul], [table], [figure], and [p] buttons on a future Textpattern toolbar.

In any way, all styling features should be decided by the designer of a website and completely described in an appropriate style sheet.

Offline

Board footer

Powered by FluxBB