Improvements to editor (write page, code pages)

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.

maverick · 2014-02-06 17:54:13

I figure several moderate sized posts are preferable to one super long one. :)

phiw13 wrote #278498:

Indeed, that is something I’d like to see in TXP: a (light?) version history mechanism.

rah_post_versions?

philwareham · 2014-02-06 18:05:47

OK, I’ll be back working on Textpattern in a couple of weeks or so, just got a huge site to launch which is taking all my time at the moment.

maverick · 2014-02-06 19:00:43

of modularity, txp tags on admin pages & smd_tabber

etc wrote #278433:

The only thing I miss on the admin side are txp tags… compose one’s own write panel, wouldn’t it be loverly?

sacripant wrote #278436:

I’m talking about exactly the same idea in 2009 in french forum

etc wrote #278438:

Stef has written the great smd_tabber, but the road is still long.

Bloke wrote #278406:

By all means, as Sacripant says, let’s modularise the panels and make it simpler to shuffle things around to suit many different workflows. . .I’d prefer to open up the Write panel more to plugin authors so this kind of custom functionality can be offered more easily.

jakob wrote #278416:

Sacripant’s mention of admin side layout flexibility – re-arrangeable elements, image-upload to article, custom fields+types – is in my view more urgent, or perhaps rather part of the same problem. Aside from the actual site design, I probably spend most time trying to make it easy for the client to use their site so they actually use it properly instead of sending me their edits. I have no problem doing the edits for them, but clients invariably embrace using their site more if they use it themselves, and that’s when they take on a life of their own.

philwareham wrote #278417:

The new custom fields are going to need some way of users placing and moving them around the write page, so that too needs investigation.

My “CMS” worldview is that content management involves multiple tasks. A content management system generally does one or two of those tasks well, and leaves you wishing it could do a better job with the rest.

Among other things, content management does the following:

Provides a way to input/save the content
Provides for storage of the content (flat file, SQL, etc.)
Orders the content
Provides a way to manipulate the content (search, compare, contrast).
Provides a way to output the content (publish to the web, print, etc.)

Few CMSes do all this in-house. Rather they offer their unique take combined with other tools: databases, scripting languages, html, pdf, etc. Since a CMS creates a front-end for all these functions, the breadth of its capabilities combined with the simplicity and beauty of it’s UI will determine how much I want to use it.

Textpattern’s xml style language plus it’s focus on writing in a light weight package that hid php from us is what make it a winner. We can do almost anything on the “publish to the web” side (output) The cry for modularity is because we need the same ability for input. The ability to customize the UI for input is as much of a need as to customize the output (whether as a website or a pdf).

When I first asked Stef about smd_tabber, the ability to create a custom UI for content input was really my heart’s desire. He did an awesome job of getting us as close to that idea as anyone ever has. Thank you Stef!

However, as I understand it, the admin side pages would have to be rendered by the tag engine. I’m not even sure if that is possible, let alone desireable.

Alternately, if there were tags that could securely recreate the admin UI on the front side – sort of like Manfre’s suite of plugins but more easier to use, that would also achieve the goal.

Imagine: <txp:custom_field_input field=“1” /> or <txp:body_input />. It seems like such a simple idea to achieve what we want. Except for the whole coding/tech side that is! Oh well, dreaming of the ideal is fun! :)

SymphonyCMS is another CMS that tried to achieve a customizable admin side UI as well. I’ve not check the last year or so to see how they’ve been doing.

Anyway – I agree modularity and flexibility in the write tab is highly desirable.

Textpattern CMS support forum

#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:

#46 2014-02-06 17:54:13

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

phiw13 wrote #278498:

#47 2014-02-06 18:05:47

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

#48 2014-02-06 19:00:43

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

etc wrote #278433:

sacripant wrote #278436:

etc wrote #278438:

Bloke wrote #278406:

jakob wrote #278416:

philwareham wrote #278417:

Board footer