Textile vs Markdown

candyman · 2016-09-20 17:22:36

Michael, the link has been disabled.

michaelkpate · 2016-09-20 18:23:45

candyman wrote #301651:

Michael, the link has been disabled.

Very strange. Nothing in the goo.gl interface even tells me that.

mrdale · 2016-09-20 19:02:58

I’m agnostic but more choices seems fine to me. Especially considering markdown’s adoption rate. I never liked textile anyway. Used to use it a lot with big tables that I wanted to generate from scraped text.

BUT: In my opinion the only thing that would make the whole textile and markdown inclusion really, really useful would be some implementation of automagic flat file content import like rah_flat…

Mentioned the idea to rah_flat’s new maintainer. We’ll see where it goes.

I recently used kirby on a project. It was breathtaking how dramatically faster my site came together while editing articles as flat files in directories instead of through the GUI interface.

This approach is developer-centric in that my customers would continue to edit through the GUI after launch… but just imagine, during build, duplicating a file 10 times, renaming them all something unique, dragging them to other section’s directories and boom you have a whole site’s placeholder content.

Then just edit away each item, saving as you go.

philwareham · 2016-09-20 21:15:48

Isn’t flat files (aka skins/themes) already planned for 4.7? Stef gas a branch on GitHub with some preliminary code in it. If not, then I’m all for the rah_flat code being combined into core if soneone wants to take ownership of it.

Bloke · 2016-09-20 22:44:33

philwareham wrote #301654:

Isn’t flat files (aka skins/themes) already planned for 4.7?

(OT) Yes. I had the preliminaries all coded up before the admin-layout-upate branch hit master and was starting work on the flat file portion. Need to refresh my memory on what’s planned as I can’t remember if Article content was included or if it was just Presentation layer stuff. I suspect the latter because syncing Articles across Sections might be tricky.

mrdale wrote #301653:

This approach is developer-centric in that my customers would continue to edit through the GUI after launch…

Since the way rah_flat works is to turn off the Presentation menu items so you can manage them in the file system, would you “turn off” the Write and Articles panels if editing articles that way?! And how would you define custom field data? Article Image data? Cats?

Editing presentation layer stuff works because there’s a one-to-one mapping. One file = one Form/Page textarea block, and (in the case of Forms) the filename determines type. Articles have many blocks of content. How would you demarcate them? xml? html? json? And, getting back on topic, they need passing through a Textfilter prior to publication so the relevant DB columns can be set or content generated.

If you’re advocating running the entire site — content and presentation — from files, you’re going to hit performance issues over disk contention (at least, noticeable on spinning platter) and will lock out your content creators unless they also adopt flat-file based editing. Not saying it’s impossible, but having to write into a fixed-format language file so all the sidebar content can be attributed properly, and uploading/downloading files all over the place to get content to show up is hardly my definition of “Just Write”.

(this can all be discussed elsewhere, let’s stay on topic here)

bici · 2016-09-21 05:00:46

The best option for editing flat files that i have experienced is Mountee with ExpressionEngine. Must be tried to be believed. Mountee mounts the presentation files as a flat directory. Something to shoot for.

Destry · 2016-09-21 07:59:56

Mountee looks fantastic. Presumably the initial login details can be for a local dev site too, synced with a repo. Don’t think it’s enough for me to start using EE, though. ;)

Bloke wrote #301655:

Articles have many blocks of content. How would you demarcate them? xml? html? json?

From my ignorant vista, I’d imagine something similar to the current new docs, as an example concept, where auxiliary text fields and other form controls (status, dates, image IDs, section/cats…) were defined at top of page. Is that JSON?

Purists and professional CCMS people would tell you XML, but JSON is probably a better choice for Txp country.

mrdale · 2016-09-22 16:58:35

Bloke wrote #301655:

(OT) Yes…

…(this can all be discussed elsewhere, let’s stay on topic here)

er… guilty! sorry about the misdirection

behold, a shiny new topic »

GugUser · 2016-11-17 18:08:29

Great news, Textile 3.6 was released.

philwareham · 2016-11-17 19:22:32

Yep! It’s already been rolled into Textpattern 4.7dev for testing.

ax · 2016-11-17 20:49:38

https://txstyle.org runs Textile 3.6 now.

colak · 2016-11-17 21:30:26

Thanks sooo much Steve.

Textpattern CMS

Textpattern CMS support forum

#37 2016-09-20 17:22:36

Re: Textile vs Markdown

#38 2016-09-20 18:23:45

Re: Textile vs Markdown

candyman wrote #301651:

#39 2016-09-20 19:02:58

Re: Textile vs Markdown

#40 2016-09-20 21:15:48

Re: Textile vs Markdown

#41 2016-09-20 22:44:33

Re: Textile vs Markdown

philwareham wrote #301654:

mrdale wrote #301653:

#42 2016-09-21 05:00:46

Re: Textile vs Markdown

#43 2016-09-21 07:59:56

Re: Textile vs Markdown

Bloke wrote #301655:

#44 2016-09-22 16:58:35

Re: Textile vs Markdown

Bloke wrote #301655:

#45 2016-11-17 18:08:29

Re: Textile vs Markdown

#46 2016-11-17 19:22:32

Re: Textile vs Markdown

#47 2016-11-17 20:49:38

Re: Textile vs Markdown

#48 2016-11-17 21:30:26

Re: Textile vs Markdown

Board footer