Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#25 2015-10-21 10:11:56

etc
Developer
Registered: 2010-11-11
Posts: 5,133
Website GitHub

Re: Improved Text Editor Capability

NicolasGraph wrote #296080:

If we want more users, I’m afraid that Tye is true: a WYSIWYG editor is required.

and is actually easier to implement that a syntax highlighter. But we already have hak_tinymce, right? It can be replaced with some more sexy contenteditable editor.

Offline

#26 2015-10-21 11:31:31

NicolasGraph
Plugin Author
From: France
Registered: 2008-07-24
Posts: 860
Website

Re: Improved Text Editor Capability

etc wrote #296082:

But we already have hak_tinymce, right? It can be replaced with some more sexy contenteditable editor.

That’s right hak_tinymce still works.
How is that for something sexiest but still light?


Nicolas
Follow me on Twitter and GitHub!
Multiple edits are usually to correct my frenglish…

Offline

#27 2015-10-21 11:49:10

etc
Developer
Registered: 2010-11-11
Posts: 5,133
Website GitHub

Re: Improved Text Editor Capability

NicolasGraph wrote #296085:

How is that for something sexiest but still light?

Looks good! The only problem I see is that <txp:tag /> are transformed into &lt;txp:tag /&gt;, but a normal user shouldn’t need tags in articles anyway. Something must be doable, but more as a general interface to plug wysiwyg editors.

Edit: what I really really think is that it could be part of admin-side themes.

Last edited by etc (2015-10-21 14:40:20)

Offline

#28 2015-10-21 12:06:36

NicolasGraph
Plugin Author
From: France
Registered: 2008-07-24
Posts: 860
Website

Re: Improved Text Editor Capability

etc wrote #296086:

Looks good! The only problem I see is that <txp:tag /> are transformed into &lt;txp:tag /&gt;, but a normal user shouldn’t need tags in articles anyway.

I can’t remember if it’s possible to use <txp:tags /> in hak_tinymce. You are probably right when you say that a normal user shouldn’t need tags in articles anyway. On my side I still add figures in the article body with <txp:images /> but it is maybe not a common behaviour.


Nicolas
Follow me on Twitter and GitHub!
Multiple edits are usually to correct my frenglish…

Offline

#29 2015-10-21 14:49:32

colak
Admin
From: Cyprus
Registered: 2004-11-20
Posts: 9,071
Website GitHub Mastodon Twitter

Re: Improved Text Editor Capability

NicolasGraph wrote #296087:

On my side I still add figures in the article body with <txp:images /> but it is maybe not a common behaviour.

Although I use the <txp:image id="##" /> I do it too. It’s one thing i find easier and more flexible than the textile equivalent.


Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.

Offline

#30 2015-10-23 07:59:01

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,564
Website GitHub Mastodon

Re: Improved Text Editor Capability

Just putting this back on the radar

Not sure if it has any value for us, but it’s a nice thing.

Offline

#31 2015-10-23 14:08:48

etc
Developer
Registered: 2010-11-11
Posts: 5,133
Website GitHub

Re: Improved Text Editor Capability

philwareham wrote #296123:

Not sure if it has any value for us, but it’s a nice thing.

Yes, if we value live previews. But all js versions I have tested seem behind php-textile: no "$":http://fast.links, for example.

Offline

#32 2015-10-25 11:36:35

Destry
Member
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,909
Website

Re: Improved Text Editor Capability

tye wrote #296063:

IMO – the lack of a decent core WYSIWYG editor in txp, regardless of code output, is one of the reasons that other CMS systems are ahead of txp in popularity.

That doesn’t mean it’s good reason to add one.

There is tremendous effort, and reasonably noticable progress, in the UX and content communities, and even among some advocating devs/agencies, to educate the sheeple away from the harms of whizzy-wig technology. And a lot of this is happening — besides advocating in the field — by way of new technological directions, such as decoupled/headless systems, modern APIs that allow easy mashups between applications, and who knows what else around the corner.

Thurthermore, such advocates are pointing at systems like WordPress as doing it wrong anymore. It’s just a matter of time before WP either changes its tech direction too or begins it’s inevitable slide from the top as a new generation of web publishing systems take over.

I think this community would do itself a benefit by not comparing itself with WP all time and focus on being more future-relevant.

My vote:

  1. leave heavy wysiwyg tech to plugins
  2. include a light formatting bar for markup filters (textile and markdown) that can be turned on or off
  3. add visual behavior to main editor (and leave ‘preview’ to a different button, as is, or get rid of it)
  4. focus on editor size, display, and writing comfort
philwareham wrote #296123:

Not sure if it has any value for us, but it’s a nice thing.

Regarding split screen, I raised that idea a few years ago in the G+ area as a potential txpmag topic to explore, and it got the vehement ire of MrDale, who made it clear he did’nt like it.

While I was on the fence at the time about split screens (a la Ghost), which seem very much a ‘desktop-only’ concept, I don’t think the app trend has shown to be moving that way, rather the trend has been more ‘swipe-in/out’ oriented, like how the new iA Writer implemented it. I’m not saying to do it that way, but I am voting down the split screen idea.

In fact, in all the years of using Txp, I’ve never used the textile and html preview buttons, and clients have told me they never do either, rather they use the “view” link. Seems to me we could merge the default and filter render views into a single view (#3 above), and get rid of the two preview views that exist relying only on the default editor and the frontend view.

Offline

#33 2015-10-25 12:33:11

GugUser
Member
From: Quito (Ecuador)
Registered: 2007-12-16
Posts: 1,473

Re: Improved Text Editor Capability

Destry wrote #296185:

I think this community would do itself a benefit by not comparing itself with WP all time and focus on being more future-relevant.

My vote:

  1. leave heavy wysiwyg tech to plugins
  2. include a light formatting bar for markup filters (textile and markdown) that can be turned on or off
  3. add visual behavior to main editor (and leave ‘preview’ to a different button, as is, or get rid of it)
  4. focus on editor size, display, and writing comfort

1+

Offline

#34 2015-10-25 13:20:25

etc
Developer
Registered: 2010-11-11
Posts: 5,133
Website GitHub

Re: Improved Text Editor Capability

Destry wrote #296185:

  1. leave heavy wysiwyg tech to plugins
  2. add visual behavior to main editor (and leave ‘preview’ to a different button, as is, or get rid of it)

Good ideas, unfortunately contradictory.

Offline

#35 2015-10-25 13:48:18

hcgtv
Plugin Author
From: Key Largo, Florida
Registered: 2005-11-29
Posts: 2,722
Website

Re: Improved Text Editor Capability

Destry wrote #296185:

I think this community would do itself a benefit by not comparing itself with WP all time and focus on being more future-relevant.

For the last 10 years, we’ve been told that WordPress is hands off, no speaking ill of the Automattic.

Textpattern, at the most, may have 50,000 installs, and that’s being optimistic. The vast majority of installs are web designers using Textpattern for a client site, the end-user base is quite small in comparison. I would peg the end-user ranks at about 15 to 20,000, very optimistic.

WordPress has over 50 million installs, that’s 3 more zeros before the decimal point for all you math majors. So for every Textpattern install there’s 1,000 WordPress installs.

I don’t want to deviate this thread, but it’s time to take the gloves off.

WordPress sucks, and it sucks so much that the WordPress Foundation bought up WordPress.sucks in June as soon as it became available.

Should we plunk down $249 of our donated funds and register Textpattern.sucks, just in case?

Sorry Destry, but the hands-off approach has done nothing for the Textpattern project.

Offline

#36 2015-10-25 15:07:23

GugUser
Member
From: Quito (Ecuador)
Registered: 2007-12-16
Posts: 1,473

Re: Improved Text Editor Capability

hcgtv wrote #296190:

WordPress has over 50 million installs, that’s 3 more zeros before the decimal point for all you math majors. So for every Textpattern install there’s 1,000 WordPress installs.

What would be the advantage if Textpattern would be installed 50 million times?

Offline

Board footer

Powered by FluxBB