akarmenia

It seems your plugin directory has no read permissions for all users:

https://oriolo.ru/wp-content/plugins/crayon-syntax-highlighter/themes/classic/classic.css?ver=2.1.1

I’m getting 27 js GET errors trying to open it. Change the permissions of the plugins directory and it’ll work.

You could always try with a fresh post to avoid breaking anything on your site. Besides, wordpress has a history of changes you can revert to.

What I did was copy the entire functions.php file in my theme (some 1000 lines of PHP and HTML) and added it in the HTML view. I then switched to Visual and back and did a diff. All that was modified were the spacing between the text and the Crayon tag. The contents of the pre tag containing the code were kept intact.

What WILL break the code is if you start inserting < and > (angular brackets) unencoded into the code. This is not valid HTML! You must encode these as & lt; and & gt; so it doesn’t get picked up as HTML tags itself. The decode:true option in Crayon then decodes them back into <>.

Note that the Tag Editor automatically encodes and decodes the brackets you entered into the dialog correctly – it’s only when you forget and add an unencoded bracket outside the dialog that it can break. It’s best to use the visual editor when possible ??

I believe I’ve fixed the issue. Download the latest beta here: https://github.com/aramkocharyan/crayon-syntax-highlighter/

Fixed here: https://github.com/aramkocharyan/crayon-syntax-highlighter/commit/25839c85cf2896c915f8c8b9b2c684736293ae98

Download the latest zip: https://github.com/aramkocharyan/crayon-syntax-highlighter/archive/master.zip

Can you provide a sample of the HTML code and what happens to it after you switch to the Visual tab and back again?

I’ll be looking into this. The log is harmless but I was getting issues with the upload directory (the uploads folder was null from the wp function) so I’ll look into this and hopefully you won’t get that anymore. I suspect it’s fired only on certain pages/places in the code.

The language is defined in the langs folder, but I’ll also take a look and see the cause of the issue. The “commands” are loaded from list of matches, but if it’s more generic than that a rule is used instead. e.g. all words before brackets are functions.

Try the latest beta: https://github.com/aramkocharyan/crayon-syntax-highlighter/archive/master.zip

TinyMCE is automatically added to the comment box when the Tag Editor is enabled on the frontend

Yeah that’s ok, I’ll add a setting to do this automatically ?? This is caused when you break the structure of the code by removing curly braces or php tags.

Can you enable WP_DEBUG in wp-config and see what errors are printed on the blank screen?

I believe this is now fixed

I have written a way to check the current version on updating and upgrade anything database related that I may need, but I don’t think that would be the actual problem here. I also get issues with upgrading things – I couldn’t upgrade to WP 3.5 without uploading my site manually, and the only way to reduce the time taken is to reduce the number or size of files, make performance improvements in WP or get a better host.

I only have control over the first option, and I don’t think there are any superflous files in Crayon. I had jQueryUI in the first 2.0.0 release, but I’ve removed it since and I’m using the version included with WordPress. I’ve been using the jQuery included with WordPress for about a year or so now, and the only other major script I use is Fancybox.

There are a large number of files for languages and they don’t change very often, so having delta updates for plugins much like they do for core WP would be nice.

No problem!

Great!

Yep, that’s a good find! I’ll add that to the online docs. Instead of printing a <script> tag, register the new jquery with:

wp_register_script('jquery', 'url/of/your/jquery');

Since jquery doesn’t exist as a script, all scripts that depend on it will fail to load. This is done internally in wordpress and I don’t have control over it. I assume it doesn’t want to load just in case it throws errors, but I would rather throw errors that are very obvious and easy to find rather than dying silently, but I guess that fits in nicely with PHP :S