Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Textpattern Next Non-Patch Version Roadmap
Sure, I’d be fine with a plugin if it was an officially supported (core) plugin like com_connect. I can see why people would not want it. Equally, having it can open the CMS up to all sorts of new exciting possibilities.
We can then also ditch all the old RPC server stuff in core and streamline that.
Offline
Re: Textpattern Next Non-Patch Version Roadmap
While I think it’s a lot easier to develop a website on TextPattern compared to other CMSes, I do think it’s a lot simpler to publish articles on platforms such as WordPress (pre v5.0, the Gutenberg editor is stupid IMO)! Because of this, I’m limiting my suggestions to one area – the article writing experience.
So what would I do differently? It’s difficult to comprehensively say without researching the problem, but of the top of my head I’d suggest two things;
1. WYSIWYG editor in the core
Once it comes to typing on computers, there’s a layout that we’re all quite familiar with;
That’s a screenshot from Word – but it could be from virtually anywhere, given how widespread WYSIWYG editors are in digital products.
I’ve got no problem with Textile. But from a user experience point of view, it’s nearly always better to present users with an interface they’re familiar with, rather than ask them to learn something new. It’s why Gutenberg has gone down badly with users, and definitely one of the reasons I wouldn’t build a client website with TextPattern – I think the familiarity of WYSIWYG editors trump Textile.
2. Article image handling
It sounds like this is going to be massively improved in the next release – and I can’t wait to see what’s suggested!
Saying that, my (very ambitious) dream would be some way of being able to view images in the text tab (or even the preview tab). Again, I’ve probably been spoiled by Word and influenced by a desire for consistency – but not being able to get a general gist of the general layout of a page without previewing it has always slowed me down when I write an article! Adding to this, I can’t see an easy way for non-technical users to easily change the size of an image.
My personal work around these issues have been to create a non-indexed testing area to publish articles in development (for some reason, draft article previews don’t update when changes are made), and to assign image sizes by class name (so images of width 100%, 75%, 50% etc. would have different class names) – but again, this seems over-complicated, and another reason I’d build a client site with other CMSes.
Personally, these things aren’t problems for me – I love this CMS! But if I could improve anything, it’d be those two things.
Last edited by ia278 (2019-03-21 14:29:41)
Offline
Re: Textpattern Next Non-Patch Version Roadmap
@ia278 thanks for the ideas, very welcomed. I see the point of
… it’s a lot easier to develop a website on TextPattern compared to other CMSes, … it’s a lot simpler to publish articles on platforms such as WordPress
We have discussed WYSIWYG editors integration many times. Each time the conclusion was “it’s plugins territory”. But I finally think we could ship it natively – not in core but in a theme. We have no time to develop our own editor, I think, so the choice belongs to theme authors. I have tried jQuery TE integration in Hive, it works out of the box though needs some polishing.
@philwareham would you like to develop a WYSIWYG capable theme for the next txp release? It looks independent of custom fields, so it could be 4.7.4.
Offline
Re: Textpattern Next Non-Patch Version Roadmap
@etc sure – if you want to collaborate in the Hive admin theme repo then we can branch in there and develop this with some nice styling. Let me know and I’ll set you up as a contributor.
My time over next month is quite limited as I have a massive Drupal 8 site launching for a client which I’ve been asked to come into last minute and pick up the broken pieces of – but I can spare a few minutes here and there to do some CSS on Hive I think, if you can handle the JavaScript side of it?
Offline
Re: Textpattern Next Non-Patch Version Roadmap
Oooh, not seen jQuery TE before. Looks good. Is it responsive do you think?
I would still like to investigate ProseMirror and write a Textile module for it one day, as that has the capability of creating actual Textile and Markdown (etc) markup and you can switch between the raw and cooked views on a whim to preview it. Still not “in situ” like ia278 says (i.e. not with the rest of the Page paraphernalia showing) but I’m sure that can be achieved with just a slight change to their workflow. For example, make a parallel cloned Theme for test content, and put conditionals to only show such content from, say, a particular category in the cloned theme. Then omit that category content from the real theme. Or something.
A few things to note:
- If this can go in a 4.7.4 drop, that’s fine. I’ll make a branch if so and we can merge to dev periodically. And we could pull things like the title attribute forward maybe?
- Possible issue: to make this work, the option to use Textile markup or Linebreaks will need to be removed (hidden?) from the Write panel and the preference forced to “Leave untouched” for excerpt and body so that generated HTML isn’t mangled. This implies we may need to build in Theme prefs support first.
If there’s an ability to toggle the editor on and off inside the theme somehow, it’ll need to be mindful of the above mentioned settings. If the idea is to make a dedicated theme that’s identical to hive but with a WYSIWYG editor baked in, that poses a slightly different set of issues.
Theme prefs are not insurmountable as there’s code to handle it that we can steal from setup (in fact, there’s a stub function for it already used during setup that could probably be made more universally applicable).
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 #317176:
I have tried jQuery TE integration in Hive, it works out of the box though needs some polishing.
Quite interesting and simple at first look (and once you’re past their rather aggressive anti-adblocking…).
Maybe I give it a try to integrate it into Sandspace next month.
Bloke wrote #317179:
Oooh, not seen jQuery TE before. Looks good. Is it responsive do you think?
Out of the box, their demo is not, but the demo’s styling is rather inflexible – typical for those jQuery projects. I don’t see why it should work at various screen sizes; at worse you’ll get a multiline toolbar.
- Possible issue: to make this work, the option to use Textile markup or Linebreaks will need to be removed (hidden?) from the Write panel and the preference forced to “Leave untouched” for excerpt and body so that generated HTML isn’t mangled. This implies we may need to build in Theme prefs support first.
Yeah that was my first thought too; that pref would have to be set to ‘Leave untouched’, and the widget hidden.
Personally, I am more interested in your eventual work “ProseMirror”, which looks much more flexible.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Re: Textpattern Next Non-Patch Version Roadmap
Having now looked at jQueryTE I’m favouring the ProseMirror approach too. Not least because jQueryTE hasn’t been updated for years whereas ProseMirror has ongoing updates and improvements.
The license is MIT so that works for us too. I’ve advocated for years that we should have some form of formatting bar on the write panel so I’m fully behind any push to bring this to fruition.
You could probably use the prosemirror-markdown codebase as a starting point for a Textile version. I’m fairly sure the devs of ProseMirror would welcome Textile support.
Offline
Re: Textpattern Next Non-Patch Version Roadmap
I’m fine with ProseMirror, we can try it too. My point is that it’s a theme feature, core must just provide enough flexibility for (un)plugging text filters.
Re 4.7.4, most of dev branch could go there imo. We have not yet merged anything custom-fields specific into dev.
Offline
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
Re: Textpattern Next Non-Patch Version Roadmap
etc wrote #317186:
Re 4.7.4, most of
devbranch 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
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
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!
Offline