Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: The evolution of Textpattern
Me too, I’m sad by the adoption of Jekyll for documentation :(
It’s a terrible disavowal for Textpattern.
This choice simply mean that Textpattern is not a suitable tool for content managed collaboratively by a community.
Although I’m ok with that.
But once Github was chosen to manage collaboratively the documentation, 2 choices opened to the core tram :
- Evolve Textpattern to enable it to handle the import of articles files from github and flat files
- Use another tool like Jekyll and rewrite all content in markdown markup.
For me, you make the wrong. Textpattern could be better and offer a new capacity.
But this is not the most important. The most important is that textpattern have a documentation :)
Offline
Re: The evolution of Textpattern
We are using Jekyll since it is the right tool for this – that simply means we are dumping MediaWiki for Jekyll for collaborative documentation. Textpattern hasn’t _lost_here since it wasn’t ever running the docs in the first place.
GitHub builds a new flat file Jekyll site every time you commit changes to a page/document, so what you are saying is I should wait around for some speculative feature that does this via Textpattern instead, somehow injecting new changes into a database when someone commits changes on GitHub, making a more complex system that can easily fall-over (and probably can’t be done in the first place)? No thanks.
The original textpattern.net docs are/were in Wiki markup so the content has to be rewritten anyway, so we would have had to (and did for some of the docs) rewrite in Textile anyway since they were not in that format. It just happens that we now have to use Markdown instead, since GitHub wanted to streamline their support and Textile just wasn’t used by the vast majority of their user base.
Offline
Re: The evolution of Textpattern
sacripant wrote #301224:
This choice simply mean that Textpattern is not a suitable tool for content managed collaboratively by a community.
Not even close to being a concern, or relevant.
We’re not talking about just any “content”; we’re talking about documentation, which is a significant distinction, because documentation, ideally speaking, calls for some robust collaboration features:
- accommodates contributors in a controlled way (no stepping on toes)
- can track editorial changes
- can provide versioning/rollback
- employs use of system notifications (a critical collaboration function)
- provides issues tracking (think wiki “Talk” pages)
- etc
Textpattern doesn’t provide any of that. Never has. It can’t even send a notification to a Copy Editor when a Freelancer changes an article’s status from Draft to Pending, which is a pretty simple workflow, and pretty basic function in most other collaborative publishing systems. GitHub, on the other hand, handles all that extremely well, in it’s own particular way — it’s a collaborative demon by nature.
Textpattern is great for a lot of projects and content types; especially where content has a clear division of labor. But when it comes to flat-file documentation that begs for controlled collaboration, it’s not the best choice, not by a long way. I could probably find a 100 employed tech writers in my network to tell you the same thing, but then you’d have to listen to boring accounts of DITA authoring and exotic applications with much steeper learning curves than Jekyll. ;)
Jekyll may not be the best choice either, but any flat-file solution on GitHub is a far better option than Txp alone.
Offline
Re: The evolution of Textpattern
Destry wrote #301227:
Textpattern is great for a lot of projects and content types; especially where content has a clear division of labor.
That’s what Textpattern’s documentation workflow has been over the years, 2 or 3 volunteers who took it upon themselves to write and maintain the docs. There was a division of labor, collaboration by the many never quite materialized.
You talk about Doctor CMS, which brought me to the Minio docs.
Would you like to see the Textpattern docs looking just like Minio’s by the end of next week?
- Installation
- Quickstart
- User Guide
- Content
- Textile
- Presentation
- Tags
- Themes
- Admin
- Plugins
- Content
- About
I can guarantee, without a shadow of a doubt, that Textpattern 4.6 will render a doc page before Doctor CMS even has a chance to start it’s progress wheel.
We Love TXP . TXP Themes . TXP Tags . TXP Planet . TXP Make
Offline
Re: The evolution of Textpattern
I’d rather you help work on the project and platform I have chosen (and I’ve already explained why I’ve chosen) – that being here
Offline
Re: The evolution of Textpattern
I might as well add… aside from the functional features I outlined above, a flat-file approach to documentation on GitHub also allows contributors to use the editor they want to use, rather than constrain them to a single one.
Sure, Phil has made the admin-side pretty. But I don’t want to carry a tool belt when all I need is a pencil. I work with words more than anything else most of the day, and there’s nothing I’ve found yet that beats iA Writer as a copy editing application, and I’ve tried and paid for many editors. (I also like Scrivner, but that’s a different world.)
I like Writer because it’s designed for writers, not developers. It’s designed around the writing process, and the features that writers are sensitive to; editing comfort, mainly. The only way it could be better is if it supported Textile too, and in that respect I hear Ulysses is pretty good (supports both). I also love that it’s a native OS application, and I can manage files in a regular file manager, both locally and in the ether. No web server or database overhead to worry about. That works quite nice with GitHub repos, and when I’m offline.
But, this isn’t a pitch to sell you on iA Writer. You likely have your editor preference too, and that’s the whole point — be able to use what you like! It just happens to be another good reason for flat-file collaboration.
If Txp articles could be flat-files, and I could push from Writer to Txp, that’s how I would work whenever I didn’t need to fiddle with custom fields, output configurations, metadata, time stamps, or whatever. Headless, baby, headless.
Offline
Re: The evolution of Textpattern
philwareham wrote #301229:
I’d rather you help work on the project and platform I have chosen (and I’ve already explained why I’ve chosen) – that being here
Sorry, I don’t do Markdown.
Destry wrote #301230:
Headless, baby, headless.
We’re getting there, give me time.
We Love TXP . TXP Themes . TXP Tags . TXP Planet . TXP Make
Offline
Re: The evolution of Textpattern
Again, I think I misspelled my thoughts.
I understand why you have chosen to github + Jekyll: Github for the benefits just described by Destry and Jekyll because he is integrated with Github : automatic compilation for each commit in maser branch.
Cool, perfect, it corresponds to your need and it’s efficient.
Truly, I would have been really happy if Textpattern proposed an articles import system since flat files (it’s already exist for pages / forms / css, why not for articles ? ).
And needs of a new documentation site could have been a good pretext and challenge to develop it.
Offline
Re: The evolution of Textpattern
I always like to be the one to bring some context to these discussions.
From 2004
Alright. I did some poking around, and honestly MediaWiki does seem to be the best setup for this sort of thing. I rather like all the sub-page discussion so that regions can be discussed. – Remillard
From 2006:
Why was MediaWiki picked for Textbook? – hcgtv
At the time it happened I think because it was the product with the best multi-language support. – hakjoon
From 2008:
TextBook should use Textpattern! I’m serious, MediaWiki is a pain to use, especially when you’re used to Textile. I hate that there’s no obvious hierarchy and that pages get lost in the wiki. Given wiki accounts are manually created, I don’t see any problem with using TXP authors or copy editors. – jm
The downside to using Txp is: defacement and mistakes – a wiki keeps a history you can one-click revert back to when that happens and whom changed what and when? – a wiki usually allows you to track that with feeds. I would recommend DokuWiki, if you want to switch to something else. – Mary
Alright this last bit of nonsense with Textbook has me really wanting to pull the plug on MediaWiki. At this point I am really leaning towards DokuWiki. I don’t think we lose any features in comparison with MediaWiki and it can do Textile with a plugin. It also has an auth interface so maybe we can eventually make wiki login and forum login the same. Also since DokuWiki is file based I think I could probably create a transformer to convert scrapped textbook pages into DokuWiki pages. That to me seems way more attractive then copying and pasting a ton of files. I think this would mostly be useful for the tag list. – hakjoon
zero, most of this will be fixed in the transition to doku wiki. – jm
From 2009:
The concept of using a wiki at all for user-generated docs was still new for a lot of people and they just didn’t — or didn’t want — to get it. You’d often hear, “It’s about Txp so it should be created using Txp” or similar crap reasoning. People were — and often still are — locked in the blog mentality. – Destry
Last edited by michaelkpate (2016-09-08 17:03:31)
Offline
Re: The evolution of Textpattern
Michael,
During the xPattern era, I started converting the docs to DokuWiki. I started with the tags, never got around to the rest. The flat files in DokuWiki were the basis for TXP Tags.
Got a question, how do you search the forum?
We Love TXP . TXP Themes . TXP Tags . TXP Planet . TXP Make
Offline
Re: The evolution of Textpattern
hcgtv wrote #301234:
Got a question, how do you search the forum?
It isn’t particularly easy to find things if you can’t think of the right keyword to search for. I started out trying to find the earliest occurrence of “mediawiki” and kind of went from there with combos like “mediawiki dokuwiki” and “mediawiki textbook” and so forth.
Bert is doing a pretty quick job with the Tag pages so the way I see it we can make Doku the official and interwiki link to textbook until stuff is migrated over. – hakjoon
I seem to remember there was some sort of purge of posts that were deemed no longer relevant but I am not really sure.
Oh, and I found another post to add to the timeline above.
Offline
Re: The evolution of Textpattern
meh… I think this discussion is pretty moot. We should use any tools available to make developing TXP easier and better.
After resisting for a good while, I now use tools that can save me a significant amount of time. I was, however, dragged kicking and screaming into using them on a daily basis by those younger and less set in their ways than me.
Thanks Steelie, and even my great (sprite-map using, and “with-selected” must be placed somewhere beyond the viewport) adversary Phil ;)
- Task runners like gulp and grunt are really no brainers, they just queue up tasks that you’d be doing anyway and execute them flawlessly. I personally love gulp
- Sass or Less is actually what CSS should have been all along. Learning them provides an immediate and dramatic payoff in flexibility, versatility and saved time.
- I Could care less about composer, but I suppose someone will drag me kicking and screaming into utilyzing that as well at some point.
Interestingly enough, I was talking to a Microsoft developer this weekend, talking about how great all these new (and free) tools are and he lamented the fact that tey are not permitted to use any of them because of NIH. Glad we don’t have that problem.
I
Offline