Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#1 2014-01-23 13:12:37

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

Improvements to editor (write page, code pages)

We need to make some serious improvements to the editor pages of Textpattern I think. That means the coding pages (pages, forms, styles) and also the write page.

I’m building a new grid layout for Textpattern admin side that makes the editor areas much bigger (a two column span), and moves the other UI to a third column, which will help. But that is only half the story – we need to make use of existing open source tools in the core to make the process of writing stuff in the system actually a pleasant experience (currently I never write directly in Textpattern because of this – I use my IDE then copy/paste in content/code to the CMS).

There really is no excuse not to – plenty of open source options are available now which could be viable for integration, such as Ace editor, MarkItUp, txstyle and Textile live web editor to name a few.

I’ve already had a conversation with Jon Hicks in the last couple of days who is considering moving away from Textpattern because of the lack of live preview pane in the write page. He initially brought me to use Textpattern so it would be a shame to lose such a respected web designer.

I’m willing to put some funding towards this – but since I’m only a front-end person it’s not something I can create myself (although I can help skin where needed). Once again, these need to be core features, not left to plugin authors. It also should be available as an option for the custom fields that we plan to build into the system.

Offline

#2 2014-01-23 13:20:31

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

Re: Improvements to editor (write page, code pages)

There are also plenty of contextual popup text formatting bars that we could use, which are pretty cool. We could possibly use one of those in an edit window along with the Textile (or Markdown) live preview pane next to it, which would be very nice.

Offline

#3 2014-01-23 13:50:03

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

Re: Improvements to editor (write page, code pages)

philwareham wrote #278393:

There are also plenty of contextual popup text formatting bars that we could use, which are pretty cool. We could possibly use one of those in an edit window along with the Textile (or Markdown) live preview pane next to it, which would be very nice.

Hi Phil, nice ideas. Per se, integrating Textile live preview is fairly easy (I’ve done it for comments), but there are two “buts”:

  • if the text is formatted server-side, with txp own Textile class, there is no need for third party components, but you need a fast enough internet connection;
  • if it happens client-side (in javascript), then the js code must be revised on each txp Textile class update, to produce consistent results.

I prefer the second solution (and could help if needed) if someone can keep textile.js up to date.

Offline

#4 2014-01-23 14:00:45

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

Re: Improvements to editor (write page, code pages)

etc wrote #278394:

I prefer the second solution (and could help if needed) if someone can keep textile.js up to date.

Jukka is on the Textile team as well as Textpattern team so I guess he knows the code pretty well. The JavaScript solution would also be my preferred route from the sound of it, though as I’ve stated before I’m not a programmer so I don’t know how the inner workings of Textpattern work past the HTML/CSS. I just see these editor tools as standard in other emergent CMSes (Perch, Medium, Ghost) and want them to also be in my CMS of choice.

This subject has come up many times in the past without resolution. When I did a user poll of missing features in Textpattern last year, this, custom fields and flat file editing were far and away the most requested things by the community.

Offline

#5 2014-01-23 14:13:09

gaekwad
Server grease monkey
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 4,241
GitHub

Re: Improvements to editor (write page, code pages)

philwareham wrote #278395:

When I did a user poll of missing features in Textpattern last year, this, custom fields and flat file editing were far and away the most requested things by the community.

Are the results of that poll public, Phil? If so, where can I find them? Thanks.

Offline

#6 2014-01-23 14:19:24

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

Re: Improvements to editor (write page, code pages)

It was just an informal thing on Google+

Offline

#7 2014-01-23 14:19:56

gaekwad
Server grease monkey
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 4,241
GitHub

Re: Improvements to editor (write page, code pages)

OK, no worries -thanks.

Offline

#8 2014-01-23 15:04:25

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

Re: Improvements to editor (write page, code pages)

philwareham wrote #278395:

I’m not a programmer so I don’t know how the inner workings of Textpattern work past the HTML/CSS.

Nobody’s perfect! But that’s really ease, see here for a basic implementation. The problem is, js code is outdated, so some recent Textile features (like "$":http://some.thing) won’t work.

Offline

#9 2014-01-23 15:32:37

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

Re: Improvements to editor (write page, code pages)

That’s similar to whats here but older I think

Jukka started building something out for the official Textile site which does a similar thing, it’s not anywhere near finished yet though. It’s on GitHub here

That might give some clues as to the latest codebase.

Offline

#10 2014-01-23 15:51:04

sacripant
Plugin Author
From: Rhône — France
Registered: 2008-06-01
Posts: 479
Website

Re: Improvements to editor (write page, code pages)

Hello Phil,

I don’t understand this discussion.
Now, textpattern is a CMS or a bloging plateforme ?

Because, in write tab, UI and needs are different for a blogger , an event website, a e-commerce website, etc.

For me, The best ideas last 3 years is bot plugins (write_tab_customize, bot_image_uplaod) pugin. I thinks it’s important to gain more modularity.
The objectif for write tab is to be a hyper-flexile interface for all needs. And not impose a system input

It’s a user want a big textarea for writting in mardown or Textile with live preview. Textpattern core does help to implement very easely that, and not implement that by default.

For my personnal need I’m implemented a Full Screen Ace Editor in write tab.
It is very comfortable to write directly in textpattern and I am very satisfied. I even plan to add a “live preview Front” based to view url. This can meet the need of some users, but not all. Did you tested?

After, for page and form tab, work on a better UI is good idea.

Offline

#11 2014-01-23 15:55:50

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

Re: Improvements to editor (write page, code pages)

philwareham wrote #278400:

That’s similar to whats here but older I think

Not exactly, txpstyle.org calls the server every time you type something (solution 1), while in my example the formatting is done locally, in your own browser (solution 2).

Offline

#12 2014-01-23 16:06:31

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

Re: Improvements to editor (write page, code pages)

sacripant wrote #278401:

I don’t understand this discussion. Now, textpattern is a CMS or a bloging plateforme ?

I feel it needs something in place on the write page, that can be switched on or off by the user as desired for any textareas, if their workflow needs it. For code pages, something like Ace Editor is almost a no-brainer, it should be included IMHO. Again, the user should be allowed to turn it off (though I don’t know why they’d need to for code).

The current ‘preview’/‘html’ tabs are just not going to cut it when proper custom fields are introduced – how exactly will those be processed otherwise? Should the preview show custom field text areas? Or should it not? Or should it show some and not others? How?

Offline

Board footer

Powered by FluxBB