harikaram

Sorry, it’s been a while, but let me see if I can remember…

The issue is that the plugin code runs the ‘the_content’ filter which executes other plugins’/hooks’ code. These other hooks might have a dependency on the global $post (perhaps indirectly via get_post_type()).

In order words you call apply_filter(‘the_content’, $content) on custom $content but the resulting filter code might check the global $post to get the post_type, leading to an inconsistency. This isn’t necessarily bad practice for plugin/theme devs. They may wish to process different post type’s differently.

Since you have no control over what the_content filter executes, the only way I can see to prevent this issue is to resolve the inconsistency by setting the global $post and then reset it when done. It’s pretty safe to do I think. Check out this post: https://club15cc.com/code/wordpress/wordpress-sub-queries-the-many-options-and-best-practices-wordpress

The only question then is whether you set the post_type to ‘content_block’ or to the original post’s content type. The former would prevent custom processing of content blocks emanating from different post_types. The later prevents theme hooks from distinguishing content blocks from posts. Perhaps a hybrid? post_type=’content_block_myposttype’

Hope this helps…

I’m getting this on my single pages now:

Fatal error: Undefined class constant ‘EXCERPT_STRIP’ in D:\wwwserver\club15cc.com\wp-content\plugins\crayon-syntax-highlighter\crayon_wp.class.php

Do I need the update of crayon_settings.class.php too?

Feature request:
A nice public API for outputting code on manually.

Just want to reiterate, this is a great plugin ?? Thanks.

Ok, this is how I’ve accomplished it in my template file:

// Grab the raw code and limit to N lines
$NUM_LINES = 3;
$tmp = CrayonWP::post_captures();
$c = array_pop($tmp[get_the_ID()]);
$lines = preg_split('/[\r\n]+/', $c['code']);
$content = ''; $i = 0;

// Combine the first $NUM_LINES lines
while ($i < count($lines) && $i < $NUM_LINES) {
    if ($i > 0) $content .= "\n";       // combine with newline
    $content .= $lines[$i];
    $i++;
}
if (count($lines) > $NUM_LINES) $content .= "\n...";        // add ellipse if not complete

// Format the code and render
$crayon = CrayonWP::instance($c['atts'], get_the_ID());
$crayon->code($content);
echo $crayon->output(false);

Cool thank you. Just for clarity, I tried this in my template, mimicking CrayonWP->the_posts():

// global $post;
$captures = CrayonWP::capture_crayons(get_the_ID(), get_the_content());
$content = array_pop($captures['capture']);
//print_r($content);
$crayon = CrayonWP::instance(array(), get_the_ID());
$crayon->code($content);
echo CrayonFormatter::plain_code($crayon->code());

…but it still just gives the shortcode. When/where does Crayon convert the DB content to a shortcode?

Hi. This is concerning, as is the lack of response. Have you or can you try hardening the folder with htaccess? Something like:

RewriteRule ^wp-content/wp-plugins/w3-total-cache/[^/]+\.php$ - [F,L]

This would rule out the possibility that the vulnerability is a dodgy script, though the injection may still come via a carefully crafted query string or something similar.

Also, does the vuln occur when the plugin is disabled but NOT deleted?

What’s in the actual dodgy files? What are they named?

Hi. Here’s another small patch. It fixes an error in the setting which turns it on/off and changes the default to “off” to make it more upgrade friendly.

It also adds another setting to append a suffix to the slugs for auto-created tags to avoid naming conflicts (and annoying “-#” suffixes) to normal post tags.

https://pastebin.com/8FjmtbFT

I can send you the updated files if you’d like as well.

Oh I see, the later just checks whether *any* sidebar is registered and has widgets – possibly a throw back to the time when there was only 1 sidebar?

…and which adds a setting to turn it on/off.

Updated version which actually saves the tags rather than just puts them in the form :^

Pastebin of the diff patch…
https://pastebin.com/pqkRBZTh

Same problem on WAMP/PHP 5.2 and it persists when I replace it with the link referenced.

Hi Johan,

https://pastebin.com/PgzGPn1g

Basically, I just declare the global $post and assign the query result. Otherwise other hooks which may affect the widget will be given the wrong post as the context (either the first or last post in the main loop if I remember correctly).

I then added wp_reset_postdata() afterwards as per what I read upon doing some research.

I couldn’t find a cleaner way of setting the global post without affecting other things…