Textpattern CMS support forum

You are not logged in. Register | Login | Help

#11 2019-03-14 08:16:17

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

Re: Textpattern Next Non-Patch Version Roadmap

Dragondz wrote #317038:

Hi, maybe if possible create a plugin for GraphQL exposing basic data for beginner users and let advanced ones modify it or create their own plugins to handle advanced use?

That sounds like a winner if it’s possible. If anyone would like to try this out and needs core to do anything to support it, please let us know.


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

#12 2019-03-14 11:17:03

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

Re: Textpattern Next Non-Patch Version Roadmap

Dragondz wrote #317038:

Hi, maybe if possible create a plugin for GraphQL exposing basic data for beginner users and let advanced ones modify it or create their own plugins to handle advanced use?

That sounds like a good idea – a bit similar to the com_connect contact form / email plugin. And if you don’t want or need that tech, you don’t install the plugin and your site is not exposed to the eventual risks.

Offline

#13 2019-03-14 11:58:59

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

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

#14 2019-03-19 17:42:01

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

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; !https://www.isaacanderson.co.uk/images/160.jpg!

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

#15 2019-03-20 11:27:05

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

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.


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

Offline

#16 2019-03-20 11:45:55

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

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

#17 2019-03-20 13:29:50

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

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

#18 2019-03-20 13:45:41

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

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.

Offline

#19 2019-03-20 14:22:47

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

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

#20 2019-03-20 15:01:23

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

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.


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

Offline

Board footer

Powered by FluxBB