Improvements to editor (write page, code pages)

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

Drupal has a way of working on draft versions of articles whilst there is also a live version, it also keeps previous draft iterations so you can revert back to if things go wrong. It’s a bit of a clunky system in practice though – I have clients that just forget to publish their draft and leave the incorrect live version published instead for weeks. It probably bloats the database quite a bit too. There’s probably a better way to handle it if we do it.

monkeyninja · 2014-01-24 20:07:51

philwareham wrote #278456:

Drupal has a way of working on draft versions of articles whilst there is also a live version, it also keeps previous draft iterations so you can revert back to if things go wrong. It’s a bit of a clunky system in practice though – I have clients that just forget to publish their draft and leave the incorrect live version published instead for weeks. It probably bloats the database quite a bit too. There’s probably a better way to handle it if we do it.

Yeah, Drupal has its revisions, but it felt overly complicated to me when I worked a lot with it. We tended to disable it as a result. The only time we got it effectively working was when we installed a module that added a workflow to the publishing of content. I don’t think there is need for a revisions system to be in core, but just to be able to have a copy of the current working draft separate to the current published version. It would be relatively simple to show in the interface that the version in the editor is just a draft I would have thought.

etc · 2014-01-24 21:09:32

monkeyninja wrote #278459:

I don’t think there is need for a revisions system to be in core, but just to be able to have a copy of the current working draft separate to the current published version.

It can be stored locally, in your browser, using localStorage. That’s (almost) txp-independent and easy to implement.

phiw13 · 2014-01-26 07:15:22

etc wrote #278463:

It can be stored locally, in your browser, using localStorage. That’s (almost) txp-independent and easy to implement.

But that makes it browser dependent. The only reason I sometimes work in the textarea for an article is when I’m working on a draft that I’ll probably edit further from a different machine. Or to give a different example: various persons work together on one article (editor, authors) from different locations; the revisions of the article are only available in one browser cache.

etc · 2014-01-26 10:00:11

phiw13 wrote #278495:

The only reason I sometimes work in the textarea for an article is when I’m working on a draft that I’ll probably edit further from a different machine.

I guess, otherwise you prefer your fav text editor, because of indentation, syntax highlighting, and so on? That’s the point of this discussion: give authors more reasons to use txp textarea, the possibility to save and reedit an article later (even offline) being one of them. Of course, you’ll have to upload your draft somewhere to share it (with yourself or others), but that’s true for external text editors too.

Maybe, articles need some new revisions field, ideally incremental?

phiw13 · 2014-01-26 11:51:14

etc wrote #278496:

I guess, otherwise you prefer your fav text editor,

Yes, absolutely – across various machines, and have done so for ages.
(this reply was composed in my favorite text editor)

because of indentation, syntax highlighting, and so on?

Wrong, actually. For writing I use plain text editor, and I don’t plan to change that. But that is all beside the point of the discussion.

That’s the point of this discussion: […] the possibility to save and reedit an article later (even offline) being one of them.

Indeed, that is something I’d like to see in TXP: a (light?) version history mechanism. Your post to which I replied to suggested localstorage, I then pointed out the limit of that mechanism as it is browser + machine specific.

The rest of the discussion, syntax highlighting and the like doesn’t interest me much, I don’t have any use for it, personally. Like Stef (Bloke) upthread and eventually some others, I’ll hope it is as unobtrusive as possible, or can be turned off. A better preview mechanism than what is currently available is probably something I can see on my wish list, but more for my clients than for me.

etc · 2014-01-26 13:05:06

phiw13 wrote #278498:

Indeed, that is something I’d like to see in TXP: a (light?) version history mechanism. Your post to which I replied to suggested localstorage, I then pointed out the limit of that mechanism as it is browser + machine specific.

Yes, but, unless your text editor is on the cloud, it has the same limitation.

The rest of the discussion, syntax highlighting and the like doesn’t interest me much, I don’t have any use for it, personally. Like Stef (Bloke) upthread and eventually some others, I’ll hope it is as unobtrusive as possible, or can be turned off.

Since I publish many txp code examples, an optional unobtrusive auto-indentation/tag closing would be a plus for me, but I can live without it.

A better preview mechanism than what is currently available is probably something I can see on my wish list, but more for my clients than for me.

I have played a little with contenteditable attribute, to combine edit/preview, feedback is welcome.

monkeyninja · 2014-01-26 13:32:08

etc wrote #278500:

Since I publish many txp code examples, an optional unobtrusive auto-indentation/tag closing would be a plus for me, but I can live without it.

Indenting in the textarea is a real pain. Another reason I switch to a text editor for composing a post as I also regularly write code examples in posts using Textpattern. Unfortunately the tab key needs to work for switching between form elements to keep things accessible. I’ve yet to figure out how to indent in a textarea from the keyboard.

etc · 2014-01-26 13:39:22

monkeyninja wrote #278501:

Indenting in the textarea is a real pain. Another reason I switch to a text editor for composing a post as I also regularly write code examples in posts using Textpattern. Unfortunately the tab key needs to work for switching between form elements to keep things accessible. I’ve yet to figure out how to indent in a textarea from the keyboard.

Probably, upm_insert_tab still works?

springworks · 2014-01-27 10:35:30

I think it’s important to have a native and supported way of editing pages, forms and styles as flat text files. This makes development much quicker and easier and allows for easier use of version control during development.

In terms of live previews of articles, there is already a “view” button on the Write screen when editing an article. Perhaps this could be added to the Write screen when creating a new article too? Also, instead of opening the article in a new window/tab in the browser, I wonder if opening it in a lightbox-style view would be better and feel more immediate?

philwareham · 2014-01-27 11:29:40

etc wrote #278500:

Since I publish many txp code examples, an optional unobtrusive auto-indentation/tag closing would be a plus for me, but I can live without it.

Behave.js provides some of that, and is quite unobtrusive. It’d be relatively easy to build into Textpattern from reading the documentation.

monkeyninja wrote #278501:

I’ve yet to figure out how to indent in a textarea from the keyboard.

Just use soft tabs (4 spaces), I use those for all my coding anyway.

etc · 2014-01-27 14:31:00

philwareham wrote #278519:

Behave.js provides some of that, and is quite unobtrusive. It’d be relatively easy to build into Textpattern from reading the documentation.

Yes, but it does not seem to handle XML out of the box, which makes it almost useless for writing txp code. Hooks are possible, but I haven’t found one for XML.

mrdale · 2014-01-27 17:27:28

Here’s my vote for codemirror/emmet combo. I’ve been using it for a couple of years now and it handles txp(xml) code very nicely. Probably better to keep it available through a plugin tho.

It has the added benefit of including a shorthand for markup that really speeds things up. DEMO

That is,

div>(header>ul>li*2>a)+footer>p

translates to the following with a single keystroke…

<div>
    <header>
        <ul>
            <li><a href=""></a></li>
            <li><a href=""></a></li>
        </ul>
    </header>
    <footer>
        <p></p>
    </footer>
</div>

etc · 2014-01-29 14:39:25

mrdale wrote #278527:

Here’s my vote for codemirror/emmet combo. I’ve been using it for a couple of years now and it handles txp(xml) code very nicely. Probably better to keep it available through a plugin tho.

emmet is great, but I have not found a way to quicktype self-closing tags: txp:article>txp:title results in

<txp:article><txp:title></txp:title></txp:article>

Howto?

maverick · 2014-02-06 17:52:11

Some really good discussion.

re: bigger textbox area, more focus on writing

My initial attraction to TextpatternCMS was it’s focus on “just let me write”. I agree that over time it’s UI has lost that edge. I am for a refresh.

Making the textareas larger is a start. Even better might be to take note of the browsers that allow text fields to open on a text editor window or hand off to a third party text editor. Personally, I like the bigger, more focused window while writing, and the integration that comes by closing the window and having everything in the text field. No copy/paste.

A modal window built into Textpatter that allows me to focus solely on writing until I click done/save/whatever would do the job nicely. I can set all the options before or after writing.

re: live preview

A less clunky live preview is a plus. The reason that WYSIWYG is so popular is that it is the ultimate in “live preview” as far as text formatting goes. People want what people want. . .

re: WYSIWYG

philwareham wrote #278423:

No, the last thing I want in Textpattern is a WYSIWYG.

I’m not inherently for or opposed to the concept of WYSIWYG. I hate UI clutter though, and that seems to be where WYSIWYG ends up. Plus it rarely goes with light weight code. I too would avoid a full WYSIWYG integration by default.

philwareham wrote #278423:

Something along the lines of rah_textilebar. . .would be acceptable though.

I’m a fan of rah_textilebar for helping people bridge the WYSIWYG to Textile gap.

Textpattern CMS support forum

#31 2014-01-24 19:23:05

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

#32 2014-01-24 20:07:51

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

philwareham wrote #278456:

#33 2014-01-24 21:09:32

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

monkeyninja wrote #278459:

#34 2014-01-26 07:15:22

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

etc wrote #278463:

#35 2014-01-26 10:00:11

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

phiw13 wrote #278495:

#36 2014-01-26 11:51:14

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

etc wrote #278496:

#37 2014-01-26 13:05:06

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

phiw13 wrote #278498:

#38 2014-01-26 13:32:08

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

etc wrote #278500:

#39 2014-01-26 13:39:22

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

monkeyninja wrote #278501:

#40 2014-01-27 10:35:30

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

#41 2014-01-27 11:29:40

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

etc wrote #278500:

monkeyninja wrote #278501:

#42 2014-01-27 14:31:00

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

philwareham wrote #278519:

#43 2014-01-27 17:27:28

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

#44 2014-01-29 14:39:25

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

mrdale wrote #278527:

#45 2014-02-06 17:52:11

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

philwareham wrote #278423:

philwareham wrote #278423:

Board footer