Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Textpattern Next Non-Patch Version Roadmap
Oooh, I like that you’ve made it a Textfilter as that gets round the need for theme prefs and the sticky situation of how to programmatically set it to Leave untouched.
It also means it’ll work natively with custom fields that have been set to accept a Textfilter.
If we’re going with a popup for rendered preview (is that updated live as you type?) then I think we should ditch the text/html/preview tabs at the top. Maybe put a single ‘preview’ link somewhere (in the Publish box? Or is that getting crowded?) and then have the tabs in the popup so you can switch between HTML and preview mockups. And it remembers which one you used last so it defaults to that next time you hit the Preview link.
That’ll probably simplify the txp_article.php code too, because there’s a lot of if ($view === 'text') type of stuff in there.
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
Re: Textpattern Next Non-Patch Version Roadmap
Bloke wrote #317202:
Oooh, I like that you’ve made it a Textfilter as that gets round the need for theme prefs and the sticky situation of how to programmatically set it to Leave untouched.
It also means it’ll work natively with custom fields that have been set to accept a Textfilter.
I have tried various combinations (independent editor/filter, wysiwyg in preview tab, etc). This one seems to be the easiest both to implement and to use. I doubt anyone will often mix textile and wysiwyg editing.
BTW, does someone use Convert linebreaks nowadays?
If we’re going with a popup for rendered preview (is that updated live as you type?) then I think we should ditch the text/html/preview tabs at the top. Maybe put a single ‘preview’ link somewhere (in the Publish box? Or is that getting crowded?) and then have the tabs in the popup so you can switch between HTML and preview mockups. And it remembers which one you used last so it defaults to that next time you hit the Preview link.
That’ll probably simplify the
txp_article.phpcode too, because there’s a lot ofif ($view === 'text')type of stuff in there.
Preview popup is actually in custom-fields branch, so we have time to nail the interface. But we could release it in 4.7.4 if necessary, this is not much work. It could be live preview too, just a question of performance. And yes, this simplifies the code.
Re 4.7.4 branch, I would rather commit changes to dev and cherry-pick just before release.
Offline
Re: Textpattern Next Non-Patch Version Roadmap
etc wrote #317203:
I doubt anyone will often mix textile and wysiwyg editing.
Correct. Convention over configuration every time.
does someone use
Convert linebreaksnowadays?
Not me. I’ve no idea under what situations it would be useful, but it’s a legacy option and doesn’t do much harm, nor take up much code so I guess it stays?
Preview popup is actually in
custom-fieldsbranch
Didn’t spot that. I’ll take a look.
Re 4.7.4 branch, I would rather commit changes to dev and cherry-pick just before release.
That’s fine up to a point but the further development moves on dev, the harder it is to cherry pick cleanly. For example, some of the CSS fixes in recent commits would be handy to bring into the 4.7.4 branch but they come after the introduction of Dark Mode so that feature comes along for the ride unless you resolve the merge conflict and unstitch all the DM changes each time you run git cherry-pick.
Likewise, if any changes to the preview popup on the Write panel require CSS changes, the alterations would be built on the latest dev stylesheets which have Dark Mode in them. As that’s probably not something that’s ready for the 4.7.4 timeline it would need removing during the cherry pick operation. And on a minified .css file that’s a pain as it’s all on one line!
Generally, it’s easier to pull stuff forward from a lesser branch to a more advanced branch than it is to go back. Not insurmountable to do it the other way, just a little more work.
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
Re: Textpattern Next Non-Patch Version Roadmap
Bloke wrote #317205:
That’s fine up to a point but the further development moves on dev, the harder it is to cherry pick cleanly. For example, some of the CSS fixes in recent commits would be handy to bring into the 4.7.4 branch but they come after the introduction of Dark Mode so that feature comes along for the ride unless you resolve the merge conflict and unstitch all the DM changes each time you run
git cherry-pick.
Erm… you know I branched the 4.7.x version of Hive admin theme prior to working on 4.8 features and Dark Mode stuff? See here. So it would simply be a case of me cherry-picking any updates from master branch that would be good for 4.7.x and then we simply npm run get-hive-admin-theme 4.7.x and you’re done.
Offline
Re: Textpattern Next Non-Patch Version Roadmap
philwareham wrote #317206:
you know I branched the 4.7.x version of Hive admin theme prior to working on 4.8 features and Dark Mode stuff?
Sure. Maybe that wasn’t the best example since you have a parallel development process and any CSS can be reapplied from the base branch and rebuilt. I was talking from a pure git perspective. Once committed to the main repo, you can’t easily cherry-pick backwards for fear of bringing in something unexpected that is dependent on another feature.
Going forward (adding 4.7.x features to a 4.7.x branch and merging up into dev) is generally safer than vice versa.
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
Re: Textpattern Next Non-Patch Version Roadmap
etc wrote #317201:
Well, I don’t know yet how to make ProseMirror work with textareas, tbc. I have successfully integrated MediumEditor though, individually for each field.
A brilliant solution! That interface is definitely becoming more common online… and if it works code-wise, it sounds like it’s a win for everyone :-)
I’ve been researching the interface content of WYSIWYG editors since my last post – in short, the features that most editors have in common! Through checking out some of the big hitters (TinyMCE, CKEditor etc.), as well as the Textile documentation and other CMSes, I’ve come up with this list;
1. The crucial things
Simply put, I’ve not come across an editor without these seven features;
- bold, italics and underline,
- insert links,
- headers (h2, possibly with h3 as a dropdown option?),
- ordered/unordered lists (which are nearly always kept as separate buttons).
2. The extremely useful things
Being able to include these would definitely make the writing experience a lot smoother;
- insert images (this should be in the crucial list TBH – but I don’t know the TextPattern code situation, or the limits of MediumEditor),
- embed (although I’ve seen a lot of editors that automatically embed videos/images/players if a URL is pasted into the writing area).
3. Preference specific things
These are things that specific users might need, depending on their writing style and personal preferences. If it’s possible, it might be better if users were able to toggle these on/off, depending on what they wanted to see?
In alphabetical order, they are;
- alignment (left, center, right and justify),
- blockquotes,
- strikethrough,
- sub/superscript text
- tables,
I also had a question – if it’s possible to insert images into the body (as @etc’s image seems to suggest), could a similar thing be implemented specifically for images? I know Medium allows people to set image widths this way…
Last edited by ia278 (2019-03-21 16:43:19)
Offline
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
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
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!
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
Offline
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.
Offline
Offline