Textpattern CMS support forum

You are not logged in. Register | Login | Help

#21 2019-03-20 15:09:30

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

Re: Textpattern Next Non-Patch Version Roadmap

etc wrote #317186:

My point is that it’s a theme feature, core must just provide enough flexibility for (un)plugging text filters.

Absolutely.


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

#22 2019-03-20 15:10:46

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

Re: Textpattern Next Non-Patch Version Roadmap

etc wrote #317186:

Re 4.7.4, most of dev branch could go there imo. We have not yet merged anything custom-fields specific into dev.

My Hive Dark Mode work is in there but needs to be completed and depends on non-existent theme-based prefs, so I’d have to back that out or wait for that feature to happen. I think everything else I’ve done in 4.8 dev is OK to go into 4.7.4 (not sure about the widows pref).

Offline

#23 2019-03-21 01:09:49

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

Re: Textpattern Next Non-Patch Version Roadmap

In case we need it I’ve created a v4.7.4 branch and cherry-picked anything non-theme-related into it. Things I’ve not cherry picked (mainly due to them creating merge conflicts) :

  • Dark mode
  • Anything that changes the admin-theme CSS or public theme (because we don’t want four-point-eight in it). So all these commits are omitted:
    • Inline-date fields
    • Google Fonts references
    • Invisible field selectors fix
    • Pophelp amendments referring to no_widow
    • Disabled styling bug
    • Stronger button focus
    • Cross-browser progress tags
  • The history that refers to 4.8

Feel free to update or cherry pick anything in the above from dev that you feel is compatible.


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

#24 2019-03-21 12:46:23

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

Re: Textpattern Next Non-Patch Version Roadmap

Well, I don’t know yet how to make ProseMirror work with textareas, tbc. I have successfully integrated MediumEditor though, individually for each field:

As you see, HTML/Preview are now modal dialogues. The way they worked before do not suit future custom fields. Stay tuned!


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

Offline

#25 2019-03-21 13:19:59

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

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

#26 2019-03-21 13:37:03

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

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.php code too, because there’s a lot of if ($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.


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

Offline

#27 2019-03-21 14:28:30

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

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 linebreaks nowadays?

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-fields branch

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

#28 2019-03-21 14:37:53

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

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

#29 2019-03-21 16:13:09

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

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

#30 2019-03-21 16:16:20

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

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

Board footer

Powered by FluxBB