The evolution of Textpattern

hcgtv · 2016-09-07 06:30:05

Textpattern, such a small and compact set of PHP scripts. Fell in love with it from the moment I installed it. Got to learning Textile, and have never looked back.

Over the years it has evolved, as has everything around it, but it’s remained nimble, kicks ass if you ask me.

There used to be a time when all you needed was a text editor and access to SVN to contribute code. If you decided to participate in the ecosystem, well you ran a Textpattern site and created suitable content.

Official sites were manned by trusted volunteers, they all ran Textpattern. New site designs were worked on and content massaged in a beta.Textpattern.site, the forum got a peek here and there.

Other than Textpattern, we used PunBB for the forum and MediaWiki for the docs. There was a definite need for a forum script, I’m not too sure we needed a collaborative wiki for docs, Textpattern would of sufficed.

Today, Textpattern relies on many other projects for it’s development and presence. The barrier for participation is a bit higher now, needing to install all kinds of stuff just to get a glimpse.

Progress, sure I’m all for moving forward, but are we faster at producing code, or launching sites?

Textpattern, such a small and compact set of PHP scripts.

Destry · 2016-09-07 11:44:58

Sounds like a nostalgic way to propose putting the docs on a Txp install, which is a very belabored old chestnut.

I, as one late-adopter, have come to realize the benefits of GitHub for certain things, and collaborative documentation being one of them. Not the least of which is because every editorial change, no matter how small or large is tracked and recorded for easy referral or recovery. You don’t have that traceability with Txp. It also eliminates having to manage user accounts. Anyone can create a GitHub account and make contributions. No admin-intervention needed.

As for the choice of the wiki, originally, back in 2004 — that was Dean’s, when he supplied the .net domain for it. It was a feasible choice then too, for the same reasons: content traceability and easily leveraging contributors. It further allowed doc translations, which was the only tool that did at the time. The setbacks of a wiki, on the other hand, revealed themselves over the years, and it was good to move away from it, but I would not choose Txp for community documentation, however.

Bloke · 2016-09-07 12:47:11

Sidestepping the docs for a moment, if you’re referring to the use of grunt for example then, yeah I see your point.

All these productivity tools like Grunt, Travis, Node and even Composer have mostly passed me by. I made a passing nod at Composer, and can see the benefit of Sass (though don’t use it), but the rest just do nothing for me. By the time I’ve downloaded the damn thing, grokked what the hell it does, followed a few simplistic examples and then sat down to configure it to do something mildly more complex that’ll save me three seconds per commit, I might as well have put the energy into writing code instead.

I’m sure they’re all brilliant once you get your head round them and can save time in the long run, but until I hit a brick wall that stops me from coding, I’m faster on a keyboard and muscle memory.

So, for now at least, I don’t need anything more than a text editor (currently Sublime as it has some great plugins like docblockr and gitgutter), command-line git and a GitHub account to contribute.

Git is just sooooooo much nicer than SVN to merge and collaborate. I must use fewer than ten of its commands regularly, and that’s it: clone, pull, push, checkout/branch, status, diff, log, show, commit, merge. It just makes perfect sense most of the time and I only have to reach for the docs if I get myself in a pickle.

So don’t let the peripheral tools put you off contributing. To paraphrase the Beatles: all you need is Git.

hcgtv · 2016-09-07 12:55:23

Destry, at this point I just observe, I’ve done my share of proposing in the past.

All I’m saying is that we have an excellent little content management system, I’d use it more often.

hcgtv · 2016-09-07 13:06:55

Stef, I think Git is great, and I’m glad the repository moved there.

Yes, I’m referring to all these dependencies to test out things. I think they are all wonderful advancements in developer productivity, and I can see their merits when you’re juggling multiple projects.

Personally, I long for the simplicity of grabbing a zip or tar ball, unpacking it into XAMPP, MAMP, or your favorite flavor of *nix, and trying things out.

etc · 2016-09-07 13:26:37

I’m developing and contributing without any notion of Grunt, Travis, Node and even Composer. And Github suffices for most Git tasks.

gaekwad · 2016-09-07 13:55:37

hcgtv wrote #301150:

Personally, I long for the simplicity of grabbing a zip or tar ball, unpacking it into XAMPP, MAMP, or your favorite flavor of *nix, and trying things out.

Like this?: github.com/textpattern/textpattern/archive/master.zip

michaelkpate · 2016-09-07 14:02:25

etc wrote #301153:

I’m developing and contributing without any notion of Grunt, Travis, Node and even Composer. And Github suffices for most Git tasks.

I love Github – but I mostly interact with it via the online editor and retrieving .zip files via the download button.

Destry wrote #301145:

The setbacks of a wiki, on the other hand, revealed themselves over the years, and it was good to move away from it, but I would not choose Txp for community documentation, however.

Quoting Dean in 2003

Creators of personal journals, images, web logs, periodicals, magazines, gossip, fiction and/or commentary of any form are those for whom Textpattern is ideal.

Note that he did not include Documentation.

hcgtv · 2016-09-07 15:16:10

michaelkpate wrote #301165:

Note that he did not include Documentation.

He also mentions charging for business related sites.

Weebly is a nice example of what could be done with a Textpattern hosted service.

Their docs are simple, and to the point.

Oh, and the Wayback Machine link has a %3A instead of a “:” in the url.

philwareham · 2016-09-07 15:30:29

To put this in context, to contribute all you need is a text editor, a (free) GitHub account and the GitHub client app (and/or CLI if you desire).

Further to that, because it’s 2016 not 2004 I use Sass and an automated build chain to build websites. This is because the build does all things like minifying code and prefixing CSS rules where needed. The only thing you need to preinstall is NodeJS on your computer (because Grunt and Sass compiler need it). Hardly a barrier to entry.

If you don’t use Sass then unfortunately you’re not going to be much help to me anyway.

michaelkpate · 2016-09-07 15:34:46

hcgtv wrote #301179:

Oh, and the Wayback Machine link has a %3A instead of a “:” in the url.

Updated to a bit.ly link :)

He also mentions charging for business related sites.

Weebly is a nice example of what could be done with a Textpattern hosted service.

Their docs are simple, and to the point.

Paying $99 a month for Zendesk Enterprise seems a bit excessive.

hcgtv · 2016-09-07 15:41:59

philwareham wrote #301180:

If you don’t use Sass then unfortunately you’re not going to be much help to me anyway.

I’ve just gotten an understanding of CSS, so Sass is like way overkill for me.

michaelkpate wrote #301182:

Paying $99 a month for Zendesk Enterprise seems a bit excessive.

I was pointing out how simple the docs were, one page, linking to examples, instructions, etc. Not too overwhelming, everything easily accessible, no having to click here and there to dig a find.

sacripant · 2016-09-08 09:11:30

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

philwareham · 2016-09-08 09:35:55

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.

Destry · 2016-09-08 12:17:15

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.

Textpattern CMS support forum

#1 2016-09-07 06:30:05