Jan-Philip Gehrcke

OK. Thank you so much. As suspected before: that makes it highly likely that the remaining actions/filters are registered but after all not executed. To be 100 % sure that the filter functions do not get executed: you can try if the function ?wp_geshi_insert_highlighted_code_filter() is ever being called (via adding an echo statement there, again) around https://plugins.trac.www.ads-software.com/browser/wp-geshi-highlight/tags/1.4.3/wp-geshi-highlight.php#L356. If it is not called then it may be worth asking the Graphene Theme people about why it is not called: something gets in the way before the control is handed back wp-geshi-highlight. It might be the Graphene Theme.

Cool. That helps a lot! I also run PHP 7.4.33 and the specific snippet works for me: https://gehrcke.de/test-for-christoph/

Let’s debug this together! Doable.

The 179983…000 you see is the intended(!) outcome of https://plugins.trac.www.ads-software.com/browser/wp-geshi-highlight/tags/1.4.3/wp-geshi-highlight.php#L143. It’s a placeholder. The input was found and its placeholder was put into the doc (so that code ran fine, that’s super good to know!) but the output was not put back into the document.

If you look at ‘my’ test page, it shows (in the HTML doc) something like this:

<style type="text/css">
/**
 * GeSHi Dynamically Generated Stylesheet
...
</style>

That is not in your HTML source code.

That is, either there was a ‘crash’ in https://plugins.trac.www.ads-software.com/browser/wp-geshi-highlight/tags/1.4.3/wp-geshi-highlight.php#L150 (but no PHP error message pops up on your site, or the remaining hooks were not executed. Line 171 is

add_filter('the_content', 'wp_geshi_insert_highlighted_code_filter', 99);

which basically asks wordpress and the theme to invoke a specific function with low priority (late in the processing), to replace the placeholder 179983…000 with the output of the highlighting routine. This function wp_geshi_insert_highlighted_code_filter() never seems to be executed though. We need to find out why that is.

Can you add this at line 151?

echo "<br> right after wp_geshi_highlight_and_generate_css(), this worked<br>";

and then maybe at the end of the function wp_geshi_main() another

echo "<br>executed all add_action() and add_filter() statements<br>";

If none of these show up in the resulting document then we know there is a crash/error in the main geshi routine. This would be hard to debug. If however these messages end up in the HTML document then the actions/filter that the plugin registers (with the main wordpress loop and the theme) were not executed. That might be a specific bad interaction with the theme then.

Would greatly appreciate if you can try this out and provide the feedback. Thank you!

Edit: maybe temporarily do the following in wp-config.php so that we see PHP-emitted errors when rendering the page?

ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);

• This reply was modified 1 year, 6 months ago by Jan-Philip Gehrcke.

I would appreciate if you could provide further details that allow for narrowing down the problem:

• Ideally you can let me have a look at the HTML document (source) as it was emitted by your WordPress setup. At the very least a screenshot or textual representation would help. “A hexadecimal number” is not well defined, and might be something like 1 or f or 1f or aa or aab or 0x3c or — well, you get the point: there are different notations, and an infinite amount of numbers. The description is not specific enough for me to know what you have seen.
• The PHP version and the version of the plugin you are/were using.
• Maybe you have an idea what changed in your environment between “Once it was useful” and now. The PHP version? Did you install other plugins? Did you start using a different editor?

Thank you for you help and best regards from Berlin,

Jan-Philip

Hello Christoph. Thank you for taking the time to provide feedback. It would however be super nice if you could show specifics. While I have not updated the plugin in a long time, it works well on my demo page with the most recent WordPress release: https://gehrcke.de/wp-geshi-highlight-demo. With a tiny bit more information I might feel motivated to help address this. Thank you! Jan-Philip

• This reply was modified 1 year, 6 months ago by Jan-Philip Gehrcke.
• This reply was modified 1 year, 6 months ago by Jan-Philip Gehrcke.
• This reply was modified 1 year, 6 months ago by Jan-Philip Gehrcke.

Thanks, Vladislav.

> When using numbered lines, an empty line is added through the line in the Firefox

Upon copy/pasting, right?

That is, when using line numbers, you see unexpected copy/pasting behavior.

Choosing a method to build up the HTML when using line numbers is a difficult choice, see the documentation here (Vladislav, I suspect you have read this part, but I still put it here for reference): https://qbnz.com/highlighter/geshi-doc.html#the-code-container. There does not seem to be one method that does the right thing from all perspectives.

The solution that you propose, exposing this choice to the user of WP-GeSHi-Highlight, is definitely a possible solution.

Can’t make promises at this point, though.

Generally, it might be that a better approach is to have pure CSS-based line numbering, not making use of GeSHi’s $geshi->enable_line_numbers() at all. But that would be a breaking change …

I am not allowed to edit my comment above anymore, but the code block still does not show the correct code (it shows the _decoded_ HTML entities, whereas it’s supposed to show them encoded).

Thanks for the quick reply and I am glad that things worked already.

I am still trying to edit my comment above to show the right thing (the WordPress forum messes with the code content in a not really predictable way, and I couldn’t find documentation… simple Markdown would be so much better).

Hey @tathros!

Thanks for using the plugin and thanks for the question. I have not officially tested and qualified the plugin to work with Gutenberg yet. However, please try the following:

Have a look at https://gehrcke.de/wp-geshi-highlight-demo/ and specifically at these two examples called:

– “HTML, without decoding HTML entities”
– “HTML, like above, but with decoding HTML entities”

These two examples illustrate a technique based on the escaped=”true” option. That option allows you to have HTML entities such as > in your pre block content which after all displays correctly to your users. Example:

<pre lang="xxx" escaped="true">
< >
</pre> 

This will correctly display the < and the > characters. If you write “&” (which is the HTML entity for “ampersand”) it will decode to &.

That is, I think if you just leave the “&” as-is, and add the escaped=true option to your pre block then the content will display correctly.

Let me know how it goes.

Jan-Philip

• This reply was modified 5 years, 5 months ago by Jan-Philip Gehrcke.
• This reply was modified 5 years, 5 months ago by Jan-Philip Gehrcke.
• This reply was modified 5 years, 5 months ago by Jan-Philip Gehrcke.
• This reply was modified 5 years, 5 months ago by Jan-Philip Gehrcke.
• This reply was modified 5 years, 5 months ago by Jan-Philip Gehrcke.

@dmorlock I have released another version of the plugin incorporating both changes that you suggested. Thanks again for your feedback — much appreciated!

Thanks for the feedback @dmorlock — really appreciated. Will look into publishing another patch release asap.

Hey. Thanks for the inquiry. I have just published a patch release which addresses the warnings emitted on PHP 7.

Jan-Philip

Please have a look at the “Usage” section of the description shown at https://www.ads-software.com/plugins/wp-geshi-highlight/

This plugin renders its output when you or a user visits your website. It does not allow for syntax highlighting in the HTML or in the text editor. Nowhere this is claimed. Also, this is how most syntax highlighting approaches for WordPress work.

Hey, please excuse the late reply and thanks for the reminder. I did not find time to deeply think about why exactly this does not work, nor did I come up with a solution. This is my diagnosis from the top of my head:

WP-GeSHi-Highlight directly accesses $wp_query->posts from within the template_redirect hook and looks for the <pre lang="..">...</pre> occurrences in there. Only those are processed. The plugin only operates on $post->post_content and on the comments returned by get_approved_comments($post->ID). I am quite sure that whatever you are doing is entirely “invisible” to WP-GeSHi-Highlight, because you seem not to operate on the blog or comment content at all.

Does this provide enough information for you to better understand the issue?

Please let me know when you have a well-founded idea how we could change WP-GeSHi-Highlight to enable what you are trying to achieve and w/o breaking existing systems. Thanks!

Acy, I am glad that you could resolve that issue. If you are interested, I have just updated WP-GeSHi-Highlight again, for being a little more style-compliant with many themes out there. An update won’t hurt.

And while I am at it: I feel that I neglected the “marketing” thing a bit over the past years. It would be great if you could submit a quick review, so that others realize that my plugin actually works quite well. I have the feeling that there are loads of low-quality or unmaintained highlighting plugins out there with amazingly high download/installation counts. These people need to move somewhere else. Thanks!

Thanks, George. I anticipate that W3 Total Cache and similar solutions implement such a filter, which is why I hope that acy will be able to provide positive feedback.