Well, the code that I have for Textile 2.0 is actually marked “beta” but it works great. In fact, it’s what I use to do all the formatting of posts for my site (including the comments – hint, hint [ ]). At any rate, it is what Dean Allen calls “a Humane Text Generator.” It’s purpose is to allow you to do some formatting of your posts without having to learn HTML at all.
That is, you put asterisks (*) on either side of a word for strong text, and underscores (_) for emphasis, and so on. You can play with how it works on Dean’s test site for textile and if you want the WordPress textile plugin, you can get it here... I also made a plugin of the older version, at Matt’s request, so here is the textile 1.o plugin
As a side note… this plugin completely disables WordPress’s built in “texturize” plugin. Not doing so results in a mishmash of ampersands and garbage that practically always results in random links and completely illegible posts.
Edit 3-May-2005] I just noticed I’m using a slightly updated version that I haven’t linked before (all I did was make some changes that make Beautifier work a little better), but just to be sure, here are my 2.5 changes
Edit 3-Oct-2005] Another release by Dean Allen in his blogging tool TextPattern 4.0 has prompted me to make another release too. Supposedly minor changes, but … it should improve block handling and the ‘notextile’ tag (or double equals) works, as evidenced by *this text* not being _marked up_. Textile 2.6 and Textile 2.6 for beautifiers ... the “for beautifiers” version is what I’m using, it removes Textile’s clean-up of <code> sections, so that I can use “GeshiSyntaxColorer”:http://dev.wp-plugins.org/wiki/GeshiSyntaxColorer
Looks like the
==notextile==stuff is acting like hiscodeblocks used to. Ugh. You think he’d take my fixes if I could figure this out?I’ve installed your Textile 2.6 plugin and also the GeSHi plugin. For some reason when I write:
print (“Hello World”);
I see the pure HTML tags for the syntax highlighting. WordPress is not rendering the HTML for some reason.
I have the same problem as you James, from what i can guess the Textile plugin is getting the html after the GeSHi plugin colours it, then Textile converts the html into entities.
i tried using a Textile plugin that skipped over pre tags (what i was using to contain the source code) but it was just messing it up even more (wrapping the pre tags in another set of pre tags, then just generally messing with the html)
at the moment i have just disabled the source highlighting until i can find a working configuration.
If you use the “For Beautifiers” version, and set the priority of Geshi higher than that of Textile, you shouldn’t have any problems, although I seem to be getting an extra < br />. Of course, only I can get < code > (or anything else that looks like HTML) into these pages, so let me show by example:
Perl:
print $foo;
Html
<p>This is a paragraph with a <b>bold</b> word in it.</p>
<p>This is another paragraph with an <em>emphasized</em> word in it.</p>
</div>
[...] En estos dos casos existen plugins para WordPress, sin embargo, en mi caso particular me crean un problema bastante grande ya que al activarlos estropean el cA?digo de los posts anteriores, produciendo dificultades especialmente con los hipervA?nculos, pA?rrafos que se agregan de mA?s, etc. Lo ideal hubiese sido haberlos usado desde un comienzo, pero hasta ahora preferA?a escribir XHTML directamente, principalmente porque tenA?a acceso a todas sus posibilidades; sin embargo, desde la versiA?n 2.0 Textile, este lenguaje se ha convertido prA?cticamente en un meta-lenguaje de XHTML, que ofrece prA?cticamente todas sus posibilidades e incluso mA?s. Como contrapartida, es mA?s lento que sus anteriores versiones y puede llegar a ser una verdadera carga para tu servidor (en caso de que tu sitio sea intensamente visitado), pero para remediar esto existen otros plugins, tales como [...]
[...] Sin duda, este no es el A?nico factor a considerar al momento de fijarnos en el consumo de CPU, sino que tambiA?n es muy importante ponerle atenciA?n a los plugins que tenemos instalados y la cantidad de trabajo que implica servir cada pA?gina: por ejemplo, muchos ponen los A?ltimos comentarios en la pA?gina principal, y es sabido que algunos de los plugins que hacen esto implican mucho trabajo de CPU (p. ej: Brian’s Latest Comments, creo que se llama). FA?jense en el comentario que hace Mariano al post de Boja. Otro plugin que consume bastantes recursos es Textile, desde su versiA?n 2 en adelante (no pasa lo mismo con la primera versiA?n). [...]
[...] Los plugins generan una carga extra de trabajo, sobre todo aquellos filtros para el texto que escribimos, tales como Textile o los que generan muchas consultas a la base de datos, como Brian’s Latest Comments [...]
[...] One thing I do have to say is that I have grown attached to Textile which was built into Textpattern. Same maker. So I added Textile for WordPress 2.6 to my plugin list allowing me to continue to post entries using it. [...]
[...] Also, since you’re coming from Textpattern, you probably have been using Textile to format your comments and posts. If this is the case, we recommend downloading and installing Textile for WordPress. Trust me… You’ll want it. [...]
[...] On the individual post formatting front I’m also leaning towards standardizing on markdown rather than textile, but I will need to do some further investigatiion on the relevant post pluginformatting issues that WordPress 2.0 may have introduced. It looks like the Text Control plugin will allow me to switch between Textile and Markdown formatting relatively painlessly, but [Smarty Pants][] character encoding doesn’t seem to work properly at the moment. I’d investigate further, but it lets me set Textile as my default for all my old posts and specify Markdown on an individual post basis and that’s all I really need. [...]
[...] Achtung: das Preview-Template gibt den Inhalt mit der Funktion ‚textile()‘ aus. Wenn ihr das Textile-Plugin nicht installiert habt, entfernt die Funktion bitte aus dem Template, bevor ihr dieses einsetzt. [...]
[...] Il est disponible sur Site Textile [...]
There seems to be a bug with parsing link attributes. In this example, the link should have ‘oops’ as a class attribute. Instead, the parenthesised ‘oops’ appears as part of the link text.
link attribute test: (oops)link text
I think you mean to put “link text(oops)” which works like: link text
Jaykul, Tom is right. The plugin is not parsing class attributes correctly. “link text(oop)” would give a TITLE attribute of “oops.” Parentheses coming before the text should give a CLASS of “oops.”
I assign an “ext” class to all my external links. The parser bug is most frustrating.
I see what you mean … I think you will find that none of the attributes work on links in Textile at all (test here). Which is to say: this is not a problem with my plugin, which is merely a wrapper, it’s the way the Textile parser works. I am not usually prepared to alter the parser, since IMHO, these pseudo-markup languages are only useful when they work the same way everywhere…
PLEASE feel free to file bug reports:
http://www.textism.com/tools/textile/index.php
[...] Migrating content over from Textpattern was as simple as running a built-in script, which moved the content without any errors. The template migration was quite straightforward – I merged the XHTML/CSS from my old Textpattern templates with code taken from the great Minimalist Sandbox template. I then went through all my old content and removed the Textile (although had I wanted to continue with Textile there’s a plug-in available to run Textile in WordPress). [...]
Great plugin I love textile! Hey, so performance-wise how does this fare? Is a cached version of the html stored in the database or is it generated each time someone visits the article?
It does not cache the output — there are already many plugins for caching full WordPress pages, and having the Textile plugin cache it’s output separately would mean storing two full copies of the article (in each markup: Textile and Html) so that you could edit it — because nobody’s ever gotten Html->to->Textile conversion working satisfactorily.
It does not cache the output — there are already many plugins for caching full WordPress pages, and having the Textile plugin cache it’s output separately would mean storing two full copies of the article (in each markup: Textile and Html) so that you could edit it — because nobody’s ever gotten Html->to->Textile conversion working satisfactorily.
Hey Joel, does this plugin store a cache version of the HTML. Or does it convert the textile page to HTML on the fly each time someone visits the page?
I don't see anything wrong with storing two files — memory is cheap, speed and performance, on the other hand, are not. (Ex: my host gives me unlimited storage but temporarily takes me down if my site overwhelms their servers. In any case, we're talking about text files, so storing a second copy is not significant.)
The real problem Joel is dynamically creating the html each time someone visits a page. That slows down your site (specially on a cheap host). Plus, if you ever get any decent traffic (say from digg), that'll kill you…
I'm not really familiar with the cache plugins on wordpress —- but if I recall correctly, (at least on drupal), you don't enable them all the time because your site lags with changes you make. That's why the drupal textile plugin keeps a cache copy of the html. The result is that regardless of whether or not the cache is enabled, textile does NOT slow down your site…
I use WPSuperCache, and haven't had any problems with the site lagging with changes, as far as I know … honestly, I don't have any problem with the concept of storing both copies.
When I wrote this I couldn't think of a way to store the two copies and have the front end show one version and the back end show the other. I can think of a way now… maybe I'll recode it after all