Insertet <code>-Tag from other filter isn't processed

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:

1. geshifilter prepare: convert all code blocks to [geshifilter-..] style
2. your filter: insert <code>
3. geshifilter process: highlight [geshifilter-..] containers

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:

1. your filter prepare: insert <code>
2. geshifilter prepare: convert all code blocks to [geshifilter-..] style
3. your filter process
4. geshifilter process: highlight [geshifilter-..] containers

(setting issue status back to "active" to make it more visible)

How do the [geshifilter-...] style containers look like?

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?

what is creole wiki style?

could this be related to #455564: Handling of tag style [[code]]?

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

Issue is long dead, please reopen if still relevant.

This issue is still relevant, re-opening.

It is implied that the prepare callback is used to prevent conflicts of any other filters that wish to deal with code tags, but the prepare function converts all code tags so that no other filters would be able to deal with the tags unless additional code code tags where added by that filter or another filter post-geshi. This seems an unnecessary precaution, as simply using a process callback and weight adjustment would allow Geshi to handle all original code tags without missing any additional ones by other filters that are weighted intentionally to be handled by Geshi.

My personal use case is the Parsedown module, using github style code formatting, I want that code formatting to be handled by Geshi, and the current approach it can not do so.

The simplest workaround is to force the process callback to re-run the prepare callback, but it seems to be that just moving the prepare callback functionality into the process callback is the better solution.

Happy to discuss further, especially if someone can show reason why this should not be the case. Patch incoming.

Patch attached simply adds processing of extra <foo>..</foo> style code blocks, as these are likely the only ones that would get added via other filters. I did look as merging the prepare callback into the process callback, and had it 99% done, but the <?php .. ?> style code blocks where making it more complicated than I currently have time to get into.

It is not better you just mimic the prepare function in your module and make it output the code that geshilfilter expect?

In drupal 8 i will create a service for other modules work with geshi, but i do not have plans to make this for 7.

In your module use the function geshifilter_geshi_process() it will do sintax highlight, so you do not need to prepare the code to filter again by geshi. Closing this as outdate, please reopen if you still need this.