jimappleg8

I did a little research on this and it looks my original assumption was wrong. I seems that if you have a line of HTML in your ‘pre’ tag, Google Code Prettify is not expected to display the HTML any more than the actual ‘pre’ tags does. Neither the ‘pre’ or ‘code’ tag displays HTML code unless you escape it first, and that is how Code Prettify works as well.

So, your example above actually is expected behavior for Google Code Prettify and is not a bug.

Your plugin automatically escapes HTML so it will display, and that is fine, but I don’t think that is what I need. I just want Google Code Prettify implemented in WordPress without any additional features. I suppose you could consider allowing users to turn escaping off and on in the settings if you want to allow for Code Prettify’s default behavior.

Thank you for building this plugin and contributing to the community. I think you can consider this issue resolved.

I’d like to expand on this.

I really like this plugin, but it produces a lot of PHP notices. Because I’m often doing some coding on projects, I keep the error reporting in my dev environment set to show me errors at all levels, and it’s a bit annoying.

I’ve gone into the code and fixed many of them, but I’m not sure how I can communicate all the changes I’ve done without creating a huge post here. In general, the errors are “Undefined index’ errors, and I fix them the same way. This example is from the /newsletter/subscription/subscription.php file, line 953:

$alert = stripslashes($_REQUEST['alert']);

was throwing a notice because there was no $_REQUEST[‘alert’] variable defined, so I changed the code to this:

$alert = (isset($_REQUEST['alert'])) ? stripslashes($_REQUEST['alert']) : '';

These kinds of issues don’t take very long to fix. I would just ask that you turn on your error reporting and work through these before your next update. Otherwise, I’m going to have to do the whole thing again when I have to update the plugin.

Thanks.

Sorry for the multiple notes, but I found another issue with the comments around the IE conditionals. They are showing in the W3C validator as “Bogus Comments”, so I made the following change in the /kitchenbug/KB/Users.php file, starting at line 94:

This is the original:

public function ie_conditional_comments($tag, $handle)
	{
		if ($handle === 'wiki-bubble-ie8')
		{
            $tag = '<!--[if lt IE 9]>' . $tag . '<![endif]-->';
        }
		else if ($handle === 'wiki-bubble')
		{
            $tag = '<![if gte IE 9]>' . $tag . '<![endif]>';
        }

		if ($handle === 'recipe-explorer-ie8')
		{
            $tag = '<!--[if lt IE 9]>' . $tag . '<![endif]-->';
        }
		else if ($handle === 'recipe-explorer')
		{
            $tag = '<![if gte IE 9]>' . $tag . '<![endif]>';
        }

        return $tag;
	}

This is the correct version:

public function ie_conditional_comments($tag, $handle)
	{
		if ($handle === 'wiki-bubble-ie8')
		{
            $tag = '<!--[if lt IE 9]>' . $tag . '<![endif]-->';
        }
		else if ($handle === 'wiki-bubble')
		{
            $tag = '<!--[if gte IE 9]>' . $tag . '<![endif]-->';
        }

		if ($handle === 'recipe-explorer-ie8')
		{
            $tag = '<!--[if lt IE 9]>' . $tag . '<![endif]-->';
        }
		else if ($handle === 'recipe-explorer')
		{
            $tag = '<!--[if gte IE 9]>' . $tag . '<![endif]-->';
        }

        return $tag;
	}

Thanks.

I found a similar error in the same file on line 214:

wp_enqueue_style( $name, $path . '/style.css', $dependency, $this->kitchenbug->config['plugin']['version'], $isFooter);

The $isFooter variable only makes sense in the wp_enqueue_script() function, so it should be

wp_enqueue_style( $name, $path . '/style.css', $dependency, $this->kitchenbug->config['plugin']['version']);

Thanks.