Insertet <code>-Tag from other filter isn't processed
Crashtest - July 16, 2009 - 22:11
| Project: | GeSHi Filter for syntax highlighting |
| Version: | 6.x-1.2 |
| Component: | Filtering |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
Hi,
I have a filter that comes before GeSHi-filter. It replaces something with foo. But GeSHI-filter does not process it. These tags are untouched.
Why?
Is there some pre filtering happening before any other filter gets in touch?

#1
Geshifilter uses a prepare phase, which captures the codeblocks to highlight and re-embeds them in [geshifilter-..] style containers. The processing only triggers on those [geshifilter-..] containers, not on the original <code> style tags.
So if your filter has no prepare phase, the pipeline is:
if you want your <code> tags to be captured by geshifilter, you should insert them in the prepare phase of your filter so the pipeline is:
#2
(setting issue status back to "active" to make it more visible)
#3
The problem is I'm using the Custom Filter module. So I have no influence on any preperation.
How do the [geshifilter-...] style containers look like?
#4
This is internal representation and you should not depend on how it works.
(It can change from release to release and depending on it makes your site very fragile.)
can you describe your use case in more depth? why are you using the Custom Filters module and not inserting code tags directly?
#5
I was creating a Creole wiki style markup. And I wanted to make things consistent. So [code] didn't fit in the concept.
But it's not that important. It was just worth a try.
#6
what is creole wiki style?
could this be related to #455564: Handling of tag style [[code]]?
#7
It's a wiki markup language. http://en.wikipedia.org/wiki/Creole_%28markup%29
Yes, it is some kind of related.
The prefiltering habbit of this module reduces a bit the interoperability with other modules resp. makes it more difficult. But I think there a very few cases, where interoperability is really needed.
Maybe this is more a flaw in the input filter system of drupal. Can you control the order in which the preperations of the input filters take place?
#8
I still don't see how you want creole wiki style talk to geshifilter. How do you want your code blocks to look like in creole wiki style?
the prepare phase (not only for geshi filter, but all filters that use a prepare phase) is to avoid collisions between filters and by consequence integration is harder indeed. I agree though that the filter system in drupal could use some rethinking.
about the order: first the prepare phases of all filters are executed (in the configured order) and then the process phases.
If you have an input format with filter order:
- filter A
- filter B
- filter C
then the processing order is:
- filter A prepare
- filter B prepare
- filter C prepare
- filter A process
- filter B process
- filter C process