Improvements to editor (write page, code pages)

philwareham · 2014-01-23 13:12:37

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.

philwareham · 2014-01-23 13:20:31

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.

etc · 2014-01-23 13:50:03

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.

philwareham · 2014-01-23 14:00:45

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.

gaekwad · 2014-01-23 14:13:09

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.

philwareham · 2014-01-23 14:19:24

It was just an informal thing on Google+

gaekwad · 2014-01-23 14:19:56

OK, no worries -thanks.

etc · 2014-01-23 15:04:25

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.

philwareham · 2014-01-23 15:32:37

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.

sacripant · 2014-01-23 15:51:04

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.

etc · 2014-01-23 15:55:50

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).

philwareham · 2014-01-23 16:06:31

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?

Textpattern CMS

Textpattern CMS support forum

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