flat file editing for content.

mrdale · 2016-09-22 16:57:56

So after using Kirby for a bit (thanks james for dragging me kicking and screaming into that situation), I came to see the massive benefits of a flat-file CMS. In the development phase of a website it makes the initial build lighting fast.

We have rah_flat which allows all the TXP to simply suck in all presentation items from flat files in a directory. After using Kirby for a bit I kinda wish there was a rah_flat for content items. Imagine writing textile or markdown text and just having those items get sucked into the TXP database.

Leveraging rah_flat to speed site development

Now when I build TXP sites I use “rah_flat”: and set up a whole project with sublime text. I include my src directories:

Sass
JS
import
- forms
  - article
  - my_form_type
  - cheese_grommit
- pages
- sections
- styles (which I no longer use)
- textpacks
- variables

Nicholas has recently added some new killer features to rah_flat

form type directories that map to folder names to form types allow a greater degree of site organization and flexibility. Example: do have a code pattern consisting of several forms you use all the time? Why not keep it in the “hangar” library some place and just drag that directory into your forms folder when you need it. You’ve just reused some optimized code perfected elsewhere.
User-editable prefs (can be numerous types of inputs) that translate into txp variables This capability fill the gap of “adi_variables” updated by users being by flat files.
Textpacks replace all the “rah_flat_variable_my_fancy_variable” type pref labels with “My Fancy Variable”

Obvious benefits

Working this way is dramatically better for builds than within TXP. Suddenly you can:

Search and replace across your entire install using sophisticated regex patterns.
Have tags auto-complete and auto close
Use emmet style abbreviations
Use automatic code prettify
Spell-check an entire site
Code syntax coloring
Multi item select and edit

I won’t go back to editing presentation elements in the TXP interface.

If we add flat file content…

Now imagine if we were able to apply the same kind of benefits for the content side. Building a whole site’s content out by dragging around files.

Articles: I envision a scenario where articles are stored in section directories as textile or markdown files that either include json or alongside an accompanying json file for custom fields etc. Imagine filling a whole site with placeholder content simply by drag duplicating files between directories then editing them in your text editor.
files and Images stored in category directories get sucked into the database and synced with the files and images txp directories
categories are a directory tree containing json files.
links are json files

core vs plugin

IMHO it should be a plugin… Kirby is completely flat file, with no database, which is problematic past a certain point of complexity. You really start to run into headroom issues.

If you keep this as a plugin, TXP continues to function just fine for customers and site editors the moment you switch off the plugin.

What do you think?

philwareham · 2016-09-22 17:07:34

I think that any themes development we do will need to include some article content import too, since the standard ‘welcome to textpattern’ article just doesn’t cut it when demonstrating a newsletter theme, portfolio theme, etc. So I’m all for this.

Maybe Nicolas and yourself can work with Stef to incorporate this with the work he has done/is planning. If any UI is needed I will help (I’ll also provide some themes when it’s ready to do so).

Bloke · 2016-09-22 21:29:06

A plugin is the right place to do it. As we develop theme capability, anything we can do in core to facilitate such a plugin and help it to help you work in flatland, let’s do it. Stay close and stick your beak in / offer pull requests and raise issues to help direct the way files and the DB should interact.

I was planning to permit flat file syncing of Presentation elements if I could re-get my head round it. I had it all kinda planned out, but that was months and several hundred commits ago so I’ve forgotten what I was doing. No reason it couldn’t be extended to content if we can nail down what that means in some meaningful — and logical — way. i.e. file formats, directory structure, custom fields, etc.

I can see a few hurdles to overcome with the proposal above, not least of which is “files and Images stored in category directories”. How’s that going to work with unlimited cats/tags? You don’t want to be duplicating a file/image ten times to put it in ten categories…

NicolasGraph · 2016-09-23 08:42:15

Bloke wrote #301696:

I can see a few hurdles to overcome with the proposal above, not least of which is “files and Images stored in category directories”. How’s that going to work with unlimited cats/tags? You don’t want to be duplicating a file/image ten times to put it in ten categories…

+1

Flat files for content would be nice but it is not as simple as it is for presentation stuff. For example, I’d really love to manage images without the need of any .json files but I’m not sure that every users would be able to include data in their images (…and I never try to suck it with php!).

Anyway there is at least one thing to do in rah_flat before to add a content management, it is a way to manage plugins. I didn’t work on that already but I would probably need help. Then we could try to extend to contents…

Last edited by NicolasGraph (2016-09-23 08:43:44)

sacripant · 2016-09-23 09:05:56

I would like to have the possibility (at least) an importer/updater/exporter of articles in textpattern from flat file.

jmd_csv plugin is old and nor very usefull.

Textpattern CMS

Textpattern CMS support forum

#1 2016-09-22 16:57:56