akarmenia

I’ll check it out now – since it’s a PHP plugin, bugs can cause it to throw fatal errors which deliver no content from WordPress.

Hi, can you share a URL where the problem is occurring so I can diagnose it?

Fixed in the latest beta, will release today!

Juanfra, could you please specify a URL so I can test it out?

Fixed in the beta, will release shortly!

That means that the list of posts containing Crayons needs updating.

https://aramk.com/crayon/internal-post-management-crayon/

If you write more posts and then enable Crayon, it won’t automatically refresh this list. But I can make it do so after an activation/install. Nice catch, I’ll remember to look into this also.

Thanks for all your help! I’ve released 2.1.3 which fixes several issues, and I’ll be working towards a fix for these issues in the next week. I’ll update here on my progress.

I’ve added it in this commit:

https://github.com/aramkocharyan/crayon-syntax-highlighter/commit/2ab6afe6c81ba7fd101dc7398e256fbec9b10bfe

It’ll be released shortly with the next version. You can enabled it with the “Capture < code > as Inline Tags” setting.

Hi there,
That’s understandable. I did a quick test on my own site:

With Crayon: 36 requests, 3.76 seconds
With Crayon: 37 requests, 5.66 seconds

Without Crayon: 30 requests, 3 seconds
Without Crayon: 30 requests, 2.46 seconds

But if I turn off caching it takes about 9-14 seconds without and with Crayon.

So Crayon seems to add about 1-2 seconds for the 7 extra requests on my own site if I’ve enabled my browser cache.

One way this could be improved is to create a sprite of the images for the toolbar. For the other requests however, it’s not as straight forward:

The themes and fonts are loaded dynamically – minifying them together woud be infeasible due to their many combinations, but they can be minified separately.

Some scripts only load when they are needed – such as the tag editor on the front end. Should I minify those individually, or minify all their permutations: with tag editor, without tag editor?

If I get a reply here to which approach is desired I’m happy to pursue this and compile all my scripts into minified js each time they are modified.

< code > looks distinct from a < pre > in that it’s inline, but you can also enable the Tag Editor for use in the comments box by enabling TinyMCE in Crayon settings. This will let users add Crayons to their posts without typing html tags.

If you really wanted to get < code > appearing like a Crayon, you’d need to write a filter to change it into a < pre > so Crayon can capture it as code. Of course, capturing them as inline Crayons is certainly an option. I’ll look into it.

Also check out the spec here: https://aramk.com/projects/crayon-language-file-specification/

Thanks, I’ll keep a look out! I try to highlight as generically as possible in the language file rather than compile lists to reduce the number of files and improve maintenance. E.g. mark all capitalised words are constants rather than have a long list of existing capitalised constants. For keywords and statements however I use lists.

I believe I’ve fixed it in the latest beta: https://github.com/aramkocharyan/crayon-syntax-highlighter

It seems yours occurs in the footer before the < /body> so that might be why – can you get it working with the default wordpress theme? If so, then the issue is likely your plugins. If not, then it’s likely the plugins. That’d be my first approach to debugging the issue since it’ll split the problem in half.

I suspect the older version of WordPress is the reason. Can you update to 3.5? I’ll investigate the issue in any case.

I’m afraid that’s the auto-expand failing. Turn off auto-expanding as a temporary fix while I resolve the js issues.