Improvements to editor (write page, code pages)

phiw13 · 2016-06-03 12:05:30

element wrote #299465:

What about moving “Meta” below “Custom fields”? I believe one would use custom fields more than meta.

Agree with gaekwad on that. ‘Comment options’ could be moved lower down in the list – although not everybody will see it (it only shows up if you turn commenting on).

Destry · 2016-06-03 13:53:07

philwareham wrote #299464:

In Textpattern 4.7 we hope to allow authors to move the panels around to suit their tastes

Relevant to that future vision, something occurred to me while working on a spec to structure a content type with RDFa (which may end up being JSON-LD instead, but that’s a different story).

CMSes are undeniably moving to more “structured” models. In other words, being able to break content down into separate components so content models can be conceived more efficiently.

Textpattern is pretty good, but still suffers from the big body “blob” field, where a lot of individual content components need to go but can’t easily be done because you have to insert stuff into the body field in an inflexible way.

Consider this spec, for example, that describes structuring academic articles. The template I’m working on follows that to some degree. Briefly, an academic article has these components, more or less:

Title
Authors (several, with affiliations links)
Abstract
Intro
Background
Methods
Results
Discussion
References
Funding

If you imagine that as a Textpattern article, everything from Intro to Funding would be crammed into the body field in “blob”-like fashion, and Markdown and Textile are out the window because you need more specialized use of HTML in order to map the semantic schema correctly. In fact, when you remember that templates are usually parsed into nested form components in Txp, the notion of using RDFa starts to wobble because you’re breaking all those scoping attributes apart and it gets really hard to work with, thus JSON-LD starts looking like the better choice. However…

With the arrival of Txp 4.7 and extended custom fields, notably the ability to define them as textarea and move them around, we gain more control over componentizing content — leveraging it out of the body field in many cases, and people will get increasingly better at doing this as they get more familiar with the idea of chunking content and mapping it to schema.org, for example.

In that respect, two things might be worth thinking/asking about here:

First, if we can start leveraging content out of the body field, it becomes less necessary for it to be the dominant box in the panel, both in size and in concept of being where everything is dumped. It no longer has to be so big, and especially if it’s going to have less content in it. So in this respect maybe all textarea fields, body included, have a three size behavior: a minimum height when empty or a few lines, a max height when some determined number of lines is reached (but can be dragged open further), and maybe an option/plugin for auto-extending heights as you type, or whatever. The point being that component boxes, and namely textarea boxes, could/should behave more uniformly because content might end up being broken out more uniformly.

Second — and getting back to the notion of semantically structuring components — the body field, in a way, starts acting like another Txp form for HTML because we can’t use Textile, etc, which just falls apart when it comes to the semantic web.

So if you think back to an academic article, which provides a great example of semantically structuring web content, the body field would either just be used for one section of the article, take your pick:

<section typeof="ClassType" id="results">
<h2>Results</h2>
<p> ... </p>
</section>

Or maybe the body field serves as the holder of the <article typeof="Article"> ...</article> container part of the template, with all the <sectionn typeof="ClassType" id="">...</section> components in it, which, significantly, makes it easier to see them in one place, as opposed to spread out over a dozen form files:

<article typeof="Article>
  <section typeof="ClassType" id="intro">
    <h2>Intro</h2>
    <txp:custom_field name="intro_section">
  </section>
  <section typeof="ClassType" id="methods">
    <h2>Methods</h2>
    <txp:custom_field name="methods_section">
  </section>
  <section typeof="ClassType" id="results">
    <h2>Results</h2>
    <txp:custom_field name="results_section">
  </section>
...
</article>

And then custom fields are used for the structured content inside each section. You could even break those sections down into as many sub-component custom fields as needed.

So you not only have the ol’ Pages, Forms, Tags nesting as always, but a fourth nesting item too, the Body field, so that when working with schema you have everything together in one place, in context of the damn body field that ties it all together.

Can we get something like that? ;)

maverick · 2016-06-03 14:49:32

I’m of a similar mind to Destry in changing up the paradigm of the body field as the elephant on the page. Though I’m still thinking on the implications of his specific proposal.

With the advent of unlimited custom fields, we create a pragmatic need to manage custom fields – not just for output, and not just for content type and form controls, but also for input on the UI.

In many ways we are not far from the reality that every field is a custom fields. Ala CraftCMS, SymphonyCMS, and a number of others.

Perhaps we go beyond just draggable panels (which is a good start!) and begin to think about making it an option for developers to design an entire admin page with just the custom fields they want; without having to hide a bunch of stuff with CSS and plugins.

Bloke · 2016-06-03 15:38:02

maverick wrote #299481:

Perhaps we… begin to think about making it an option for developers to design an entire admin page with just the custom fields they want

Sounds a lot like custom content types, which is something mrdale has been hankering after for about flibrblbubrbrblbrlr years.

In the unlimited custom fields branch so far, I’ve included an arbitrary ‘family’ (a.k.a. group) column which can be used for any purpose by a plugin. The core may not necessarily use it, but I feel it’s important enough to be there. This way, you can divide up your custom content fields into sets. The obvious contender would be to use the same group name as Section name, thus tying fields to a specific Section. It wouldn’t be a great leap of faith for a plugin to add an event handler to the section dropdown such that the available custom fields altered immediately by matching Section->CF Group. Quite what happens to the data when you switch section and then save the article is up to the plugin!

Plugins might permit the same field to be used in multiple sections by, I dunno, comma-separating the section names in the group field. And let’s not forget that the custom fields aren’t restricted to articles so you could link them to image categories in this manner, or whatever takes your fancy.

Another way to do this is to attach custom fields to Sections directly. Nothing stopping a plugin from doing that. Fields can be attached to any content type, although in core we restrict it out of the box to the four main content types, plus section, category and user. There are callbacks to allow this to be extended.

The point is, none of this is mandated by core. Custom fields implementation is just a place to store data of arbitrary type that happens to be linked to a content type. Wanna make mav_video as a content type? Write a plugin: add an admin interface to the Content area, create a database table to complement it. Add custom fields to support it and link them via your content type. Add a mav_video tag to retrieve data and it’s Game On.

So although it’s not out-of-the-box functionality, it’ll be possible to define your own data types by slicing and combining custom fields with content types.

Still a way to go in terms of implementation details (lots of ‘todo’ entries in the code) but I’m happy enough with the concept that I think it (finally) has a future.

ax · 2016-06-03 16:21:19

Destry wrote #299478:

Briefly, an academic article has these components, more or less:

Respectfully, I totally disagree. Journal requirements are quite variable, and may require statements of conflict of interests, ethical approval, authors contributions, acknowledgements, funding, supplementary material, and more. Let alone the requirements for formatting references. Online tools for writing articles or book chapters include sharelatex, overleaf, or any other collaboration tool, including Google docs, in conjunction with Endnote, for example. Why would anybody want to use Textpattern for this, let alone for publishing. Articles are published as PDF.

Can we get something like that? ;)

Hopefully not. Textpattern’s explicit advantage is that it does not any have any preconceptions about content. And this, in conjunction with its robustnes, a rich tag syntax and almost ominpotent plugins, translate into a very powerful creativity tool for websites. The impetus for further development should be to strengthen these qualities, not to restrict the user in any way.

Having said that, I find the two boxes, body and excerpt, not ideal. For some purposes, you would rather like to have three, or five, or only one, and with a header and ordering of your own choice.

Last edited by ax (2016-06-03 16:45:37)

bici · 2016-06-03 17:31:57

ax wrote #299487:

Having said that, I find the two boxes, body and excerpt, not ideal. For some purposes, you would rather like to have three, or five, or only one, and with a header and ordering of your own choice.

I concur.

Destry · 2016-06-03 18:35:08

Ax, regarding academic articles, I think you missed the point of my post. I’m not saying I need to create academic articles, it could be any kind of article. I used that as an example of the semantic wrangling involved. But, if someone wanted to create academic articles in HTML, let ‘em.

mrdale · 2016-06-04 00:24:47

Bloke wrote #299482:

Sounds a lot like custom content types, which is something mrdale has been hankering after for about flibrblbubrbrblbrlr years.

Har… I’m only flibrblbubrbrblbrlr + 20 years old.

your custom_fields work looks monstrously cool. A little bit scared about transitioning all my glz_custom_fields faff tho. Been using it for years.

maverick · 2016-06-04 01:43:27

@Bloke

By the way – just an upfront thanks for the incredible amount of time and effort you have put into the new release, and the upcoming releases, as well as to the rest of the devs and contributors!

The new branch w/ unlimited custom fields sounds really good. And yes, it sounds like it make custom content types possible – which is part of what I’ve been hoping would be opening up. It’s exciting times for Textpattern.

Tying cf to Sections, etc – would be excellent – a very nice smart ui feature.

Ax echoed more succinctly the intent of my post when he said “I find the two boxes, body and excerpt, not ideal. For some purposes, you would rather like to have three, or five, or only one, and with a header and ordering of your own choice.”

Sometimes maybe you don’t want any of the pre-existing content pages. You just want a simple page with 5 custom fields. No body, no excerpt. Maybe even no title.

I think right now that would require a lot of hiding using bot_write_tab_customize, or css mods under the new hive admin theme, or smd_tabber and mem_form and/or zem_contact_reborn, and perhaps on occasion some additional hacking . .

I just keep imagining something more elegant for creating custom content page.

smd_tabber works well enough but mem_form can be a tough plugin to grasp at times – or maybe it’s just me who has had problems working the bugs out.

So I dream of nice tag like <txp:input cf=“my_shiny_new_custom_field” />. Perhaps an attribute that allows you to tie into content types and ui elements added by other plugins. Then that can be used on smd_tabber to build a custom content page.

Last edited by maverick (2016-06-04 10:27:10)

Destry · 2016-06-04 09:41:18

Everything Mav said. Including a huge appreciation for your efforts, Stef, on bringing Txp custom fields into the modern age. Can’t wait to test the 4.7 concepts.

Last edited by Destry (2016-06-06 09:28:15)

jakob · 2016-06-05 22:15:36

maverick wrote #299481:

Perhaps we go beyond just draggable panels (which is a good start!) and begin to think about making it an option for developers to design an entire admin page with just the custom fields they want; without having to hide a bunch of stuff with CSS and plugins.

maverick wrote #299500:

I just keep imagining something more elegant for creating custom content page.

smd_tabber works well enough but mem_form can be a tough plugin to grasp at times – or maybe it’s just me who has had problems working the bugs out.

So I dream of nice tag like <txp:input cf=“my_shiny_new_custom_field” />. Perhaps an attribute that allows you to tie into content types and ui elements added by other plugins. Then that can be used on smd_tabber to build a custom content page.

Yes, that echoes my thoughts exactly. Drag and drop and positioning is nice and looks cool in a cms demo video but – for the most part – you’re not changing things around often. Most entry panes are set once and then stay that way. And as it is (mostly) the developer who sets up what goes where, it would be very txp-like to have admin-pane templates in which it would be possible to define one’s one data entry and entry-list panes, and be able to remove those cases from the regular articles list. The new “partials” setup for the write tab is already a step towards that modularisation of admin ui items.

Myusername · 2020-12-09 00:50:25

It has been years since this topic was last commented on. How are current users thinking about this? Do you still consider adding a javascript editor to Textpattern textareas?

I’m using version 4.8.4 of Textpattern, and unfortunately plugins like smd_textile_bar are not working as they should. Although, in some previous versions of txp I remember using it successfully. I believe that it is not something serious to resolve.

Anyway, I started using “MarkItUp”, and since then I use it every time I create a website on Textpattern. It is the closest to the ideal, and it is very easy to configure according to my needs. You can easily add an “output_form” to the article, for example. I would say that this is the main reason why I use it, sometimes I use so many forms for images, videos and slides that it is difficult to remember when publishing.

When it comes to the editor on the tabs “pages”, “forms” and “styles”, it’s complicated haha. I particularly find it necessary to install any editor before starting to write something straight through the Textpattern admin. I usually use ACE, despite having some bugs.

Does anyone here usually develop directly by the Textpattern admin without any editor installed?

Textpattern CMS

Textpattern CMS support forum

#73 2016-06-03 12:05:30

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

element wrote #299465:

#74 2016-06-03 13:53:07

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

philwareham wrote #299464:

#75 2016-06-03 14:49:32

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

#76 2016-06-03 15:38:02

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

maverick wrote #299481:

#77 2016-06-03 16:21:19

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

Destry wrote #299478:

#78 2016-06-03 17:31:57

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

ax wrote #299487:

#79 2016-06-03 18:35:08

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

#80 2016-06-04 00:24:47

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

Bloke wrote #299482:

#81 2016-06-04 01:43:27

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

#82 2016-06-04 09:41:18

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

#83 2016-06-05 22:15:36

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

maverick wrote #299481:

maverick wrote #299500:

#84 2020-12-09 00:50:25

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

Board footer