Textile and Textpattern: the future

It’s official: Textpattern’s development will soon no longer be tied to Textile. Find out what this means for your favourite markup system.

A few months ago during development of Textile 2.2 the idea was floated that it would make sense for Textpattern and Textile to part development company. Textile would of course remain shipped with Textpattern and be the default installed markup system, but development of the engine should be spun away from Textpattern’s core.

The reasons for this are numerous:

  • Faster development cycle for Textile which could satisfy third parties that integrate the language in their products, as they would not be bound by Textpattern’s release cycle
  • Attract a wider development base—especially in porting the engine to other languages such as Python or Ruby
  • Present a one-stop shop for official downloads, documentation, a user/developer testing environment, and Issue reporting
  • Push Textile further in terms of localization and feature sets
  • Allow Textpattern to merely ‘include’ the latest Textile version at release time, just like we do with jQuery

With this in mind, we will begin the process of separating the two projects after Textpattern 4.3.0 is officially released.

Where to?

We need a home for Textile. Perhaps a top-level domain if we can secure funding for it. Then we can migrate the tools and documentation that we developed for testing Textile 2.2 to the new location. The current official locations—thresholdstate.com and textism.com—house out-dated versions and documentation. We’d also need some volunteer authors to help with putting together a newbie introduction, official detailed usage docs, quick-reference cheat sheets, etc.

Putting the docs on the Textpattern user documentation site means lots of hoops to jump through since we’d have to mock up the Textile output: it would be far better to have docs on a Textpattern installation, despite it being more ‘closed’. Hosting it here is a possibility but having an open—or even hardened—textarea on the site for user testing doesn’t feel quite right from a security standpoint. Similarly, Textpattern Resources is no good because it’s becoming a plugins-only repository.

A dedicated domain and environment is most attractive on the surface, so if anybody has any ideas of a name/location or wishes to be a benefactor in donating to the domain costs then please raise your hand. We can probably host here on Joyent—details to be discussed.

There is, however, the important matter that Drew McLellan brought up on the dev list. We’re maintaining the PHP implementation of Textile. So does, for example, gettextile.com imply that all versions are available to download and try from there? Therefore other ports would have to be uploaded too, meaning the respective teams would have to submit the code to us for inclusion. And what if someone tries Textile (against PHP, because that’s on the server) with features from an older port and doesn’t get the expected results? We might receive a bug report that we can’t replicate. Messy.

So is a PHP-specific domain better, e.g. textile-php.com? Or could subdomains like php.gettextile.com be used, giving the relevant subdomain management to the interested parties, perhaps leaving the docs on the root domain? Or are downloads not hosted on the TLD at all and deferred to the local repos? Or do we not bother with a TLD at all?

Call to arms

Splitting the development means choosing developers—or at least garnering interest in the project such that an initial team can be formulated to make a few decisions. As current Textpattern devs, we do not wish to dictate where the project should be hosted when handed over. Google Code? GitHub? SVN? Mercurial? Who knows? Whatever is best for everyone; as long as there’s a place we can grab the latest version and put it in the core at release time.

With that in mind, are there any people who would like to be involved in running with this at the outset? Anyone care to decide where the code repo should be hosted? Steve (net-carver) has already registered a root project on GitHub “just in case” and is willing to take an active role in developing Textile (PHP), but the decision over the toolset ultimately rests with whoever wants to help with the development legwork. We will also need some people to put the official site together—in Textpattern—and keep it maintained.

It should be noted that this change won’t be overnight. We probably need to unpick the hard-coded references to /lib/classTextile.php in the core and do some bits ‘n’ bobs of maintenance first to ease the transition for plugins. We’ll post more news as we have it.

So who’s up for taking Textile to the next level? And what are your thoughts on the domain issues? The floor is yours…


  1. Nice news Stef,

    From my p.o.v this separation makes sense. Let’s see where this goes.

  2. Happy to donate the domain registration for 2 years at least. I have a wholesale reseller account so let me know what you would like registered, where you want it pointed and also who you’d like listed as the owner. I’m afraid I’m no programmer so can’t really contribute to the development but we’ve built dozens of sites on TXP in the 6 years of our business so I’m happy to give this little bit back if it helps.

  3. I totally support this.

    As a suggestion, I think it would be a great time to use something like GitHub to officially house the source and just point to it from the new Textile site.

    That way you could also point to other (unofficial) implementations of Textile implemented in other languages.

    I think we need an official test suite for each version of Textile. That way, we can be sure to what degree other implementations of Textile adhere to the standards.

  4. Github would be the best solution IMO. The scalability would be something not anything else can compete with.

  5. I think a TLD domain would be nice for the docs and a ‘try Textile’ page at least, with subdomains for implementations, etc.

    I’m for Steve’s GitHub project for the code repo too.

    I can volunteer some time to help develop the official TXP site for Textile. Just let me know any site guidelines/structure that should be followed. Cheers! (^ _ ^)

  6. Reading Gerry’s post I’d be glad and proud to provide a logo for Textile, too. If you see the need for it maybe it could be something with crossed pen and pencil or so to show where the roots of Textile are and to strengthen the position of Textpattern as “Textiles Home”.

    And, I think that’s a good decision to separate it from TXP.

  7. Regarding the TLD, two possibilities come to mind at the moment (more may follow)…

    gettextile.com as originally suggested by Wet (I think) &

    Of the two, I think subdomains would go better with textilethis.com (php.textilethis.com, python.textilethis.com etc.) Additionally, this TLD ties in nicely with giving each implementation a visitors “test” area, not to mention textilethis() is one of the worker functions inside textile itself.

    Regardless of the TLD, if we go for one subdomain per implementation then each subdomain could point to whatever repo the implementation lead dev has setup for the project and code could be downloaded directly from the repo rather than the TLD site.

  8. This sounds like a great plan. I can’t help with backend coding, but I am happy to help updating and putting together documentation, including some video screencasts for end users if that is desirable.

  9. I have one of the “lifetime” Joyent accounts from back when they were TextDrive. I can host way more domains than I can use. Would be happy for the Textile domain(s) (whatever the name(s)) to be hosted in my spare space. Lemme know if interested.

Commenting has expired for this article.