Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Pages: 1
disable textile within tag
Hi,
I have a tag handled by my plugin that manages code highlighting.
Now, if the user enables textile to write down the article unfortunately my tag screw up because textile is applied inside the contents of my taag too.
If I have something like <txp:abc_plugin>some text</txt:abc_plugin>
, I would like to avoid having textile applied to “some text”.
Is there any way to achieve that without having the user to type every time notextile.
, please?
Gr3yFox
Offline
Re: disable textile within tag
Gr3yFox wrote:
Is there any way to achieve that without having the user to type every time
notextile.
, please?
Unfortunately it’s not possible to disable Textile within a tag. Only possible way of achieving that, is to modify the contents of article body on fly every time an article is saved.
Basically you could hook to the Write tab’s save/create event and then search and replace <txp:abc_plugin>
instances with appropriate syntax in Textile, followed by re-parsing and saving the contents. Other thing is, if it’s worth it, and whether it causes other problems/limitations as a side product.
Actually fox_code/GeSHi could use that, I mean caching, to the whole GeSHi syntax highlighting. Caching the formatted markup would improve overall performance quite a lot. GeSHi could suit a Textile plugin well too.
Offline
Re: disable textile within tag
Thank you for your answer. I thought it was easier.
Making a plugin for textile could be an interesting trick, but my plugin also has some integration with textpattern forms, and I would lose it with a textile plugin.
I surely would like to have a caching mechanism, but unfortunately modifying Body_html with callbacks seems a little bit too dangerous: it’s the perfect situation to obtain unexpected side effects.
At this point I’m not so sure if it’s a good idea to keep going implementing this feature. What do you suggest?
Gr3yFox
Offline
Re: disable textile within tag
Gr3yFox wrote:
I surely would like to have a caching mechanism, but unfortunately modifying Body_html with callbacks seems a little bit too dangerous: it’s the perfect situation to obtain unexpected side effects.
It’s not necessarily that dangerous, at least not if you give an option to turn it off (globally, or per article basis). Even if the modifying fails, the article won’t loose any content as only thing modified would be Body_html. But it might not be that easy to implement; you would have to take nesting, inline usage (etc) into account. Code base that is relatively easy to maintain might grow into something bigger and less attractive.
What do you suggest?
Personally, I wouldn’t implement such feature the way I described. In my opinion it is not worth it. I would just suggest users to use correct Textile syntax, or disabling Textile for the article completely.
Additional Textile plugin could serve article usage (potentially) better than a TXP tag; it offers easy Textile syntax and doesn’t have same limitation. Too bad the plugins aren’t yet part the main branch, nor Textpattern out of the box. As far as integration and feature-set goes, when Textile is used with Textpattern, one can use all functionality Textpattern has, like for example, you could keep the form integration.
I personally use Textile to provide GeSHi powered code blocks to articles (and other content) with a small textplug I wrote some time ago.
/**
@name syntax.textplug.php
@description Use GeSHi syntax highlighting from Textile.
@author Jukka Svahn
@license GPLv2
*/
/*
Registers new block tag handler.
We name our new tag 'syntax' and add a function
named '_textile_syntax_block_handler' to the stack
*/
Textile::RegisterBlockHandler('syntax', '_textile_syntax_block_handler');
/**
Function generating the markup when our new tag is used. Usage: syntax(javascript). alert('Hello World!');
@param $textile obj Textile object.
@param $tag string Name of the Textile tag being parsed.
@param $att string Raw attributes passed in Textile format.
@param $atts string Attributes in HTML format.
@param $ext
@param $cite
@param $o1 string Opening tag.
@param $o2 string Opening tag, level 2.
@param $content string Block tag's content.
@param $c2 string Closing tag, level 2.
@param $c1 string Closing tag.
@param $eat
@return array
*/
function _textile_syntax_block_handler($textile, $tag, $att, $atts, $ext, $cite, $o1, $o2, $content, $c2, $c1, $eat) {
/*
Check if the block tag in question is 'syntax'
*/
if($tag === 'syntax') {
/*
If constant 'GESHI_PATH' is defined look for GeSHi library from there.
If not, look geshi/geshi.php from the relative directory.
*/
$path = defined('GESHI_PATH') ? GESHI_PATH . '/geshi.php' : 'geshi/geshi.php';
/*
If the GeSHi library exists, include it.
*/
if(file_exists($path)) {
include_once $path;
/*
Get definition language from HTML class,
i.e. syntax(language). Defaults to PHP.
*/
$language = trim($att,'()');
$language = $language ? $language : 'php';
/*
Set opening and closing tags
*/
$o1 = '<pre class="'.$language.'">';
$c1 = '</pre>';
$o2 = $c2 = '';
/*
Create new GeSHi object. Disable
inline styles, use classes instead.
*/
$geshi = new GeSHi($content, $language);
$geshi->enable_classes();
/*
Parse code
*/
$content = $geshi->parse_code();
/*
Unite indepently parsed 'longblocks' (i.e. tag..) into single block.
*/
$content =
$textile->shelve(
str_replace(
array(
'<pre class="'.$language.'">', '</pre>'
),
array(
'',"\n"
),
$content
)
);
}
}
/*
Return the tag
*/
return array($o1, $o2, $content, $c2, $c1, $eat);
}
Feel free to use the code above, fork it, expand upon it. That’s if you want to provide additional Textplug for article usage and so on.
Last edited by Gocom (2011-09-04 21:11:06)
Offline
Re: disable textile within tag
You’re right, I think I will not implement that feature, it would take way too long considered the benefits.
A textile plugin is indeed interesting, but usually I write my articles in plain html and that would make an eventual textile plugin completely unuseful to me. A textpattern plugin is compatible with both edit modes.
Thank you very much for everything :)
Last edited by Gr3yFox (2011-09-10 12:37:58)
Gr3yFox
Offline
Pages: 1