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.
Hey akarmenia,
Thanks getting back at me. First and easiest step would probably making a sprite of the images. I took the initiative to combine them to for you, but I’m sure you are more than capable of doing that as well if you want to make it the way you like.
http://i.imgur.com/bTAv5z8.png normal size ones
http://i.imgur.com/bLmC6ZG.png double size ones
http://i.imgur.com/vOw5cfd.png all of them
Now for the tricky part. Since you are using a custom font I don’t think there is an easy way around the .wolf files. Maybe if the default configuration didn’t involve a font that forced an 20kb request ? That way the users will still have the option to choose a custom font if they wanted to and the default settings will not cause the server to load a 20kb file as soon as the plugin is installed. So basically letting the user choose between beauty and performance with performance as the default option. Although since a lot of plugins don’t use a custom font I’d say it won’t look that bad.
The crayon.js request is acceptable so I don’t think you will need to do anything about it. Is it necessary for util.js and jquery.popup.js to load separately ?
And finally the .css files. With the default settings my website loads 4 .css files, is it possible to cut down on the number ? The current files that are being loaded in my case are:
classic.css
monaco.css
crayon_style.css
global_style.css
As soon as you give me a bit more input as to why some files need to be loaded separately I will try to think if there is a valid work around for it. But as you can see, even with the default settings and “Attempt to load Crayon’s CSS and JavaScript only when needed” checked the plugin loads 6-8 images separately, 3 javascript files, 4 css files and a font (.wolf) file.
Also something you might want to look into is that a lot of your links in the options are broken as they point to “http://error404.000webhost.com/?” (I’m assuming the place you were hosting the documentation files no longer exist ?).
Waiting for your response 🙂
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.
Great job, glad to see you are actively working on improving your plugin 🙂
I’ve reinstalled your plugin trying to work around some of the issues above myself till you find the time to work on them yourself.
Another easy request. Is it possible to make the margin settings to accept negative values ? Margin of 0 doesn’t behave the same as WP-Syntax (the old addon I was using) since it’s still leaves a space of around 10px whereas previously the code in the post was just below the paragraph.
Also something I noticed a few days ago is that when I reinstalled the plugin, a few posts (namely the last two current posts) didn’t get affected by crayon’s styling. If I simply copy/paste the post into a new one then it works properly. There is nothing in the logs that can indicate what the problem is either.
edit: Fixed the above issue. Seems I had to use “Refresh” in the plugins options.
That means that the list of posts containing Crayons needs updating.
http://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.
Good job, I’m sure a few others would fall into that trap at some point 🙂
Please “fix” the margin as well, so it can accept negative values. I’m assuming it should only take a few minutes. Currently if you use a negative value it converts it to a positive one.
Then as soon as you can find the time to remedy some of the issues we mentioned on the starting posts I will be out of suggestions as I will be fully satisfied with everything this plugin has to offer 🙂
Do you really want negative margin values? That’ll cause it to move upwards. I suppose since it’s perfectly valid CSS it’s arguably valid to have though.
Please download the beta and check if it works for you: https://github.com/aramkocharyan/crayon-syntax-highlighter/
Ideally I wouldn’t mind avoiding negative values, although it’s not that bad it’s not a recommended practice. But for some reason magin of 0 doesn’t behave as it should.
Example:
<p style="margin-bottom:0px">test paragraph</p>
<pre lang="php">test code</pre>
The above example behaves properly with other code highlighting plugins (namely wp-syntax that I was using before) but with Crayon’s the same above code still behaves like it has a margin of 5-10px.
edit: The beta version accepts negative values properly, thank you. Also, after testing a bit, it seems like margin (top) with value 0 (or any other value below 12) behaves like margin 12 (the default).
I’ll take a look at that. In the meantime, I’ve added a branch for minifying and you can test it here:
https://github.com/aramkocharyan/crayon-syntax-highlighter/tree/minify
All the JS on the front end, and part of it on the admin, is now minified with Google Closure (there’s also a build script in js/).
Tested it – margin is set properly by Crayon. It’s just that due to the paragraph tag above it, there’s still 18px above it. Use the negative values to reduce that if you like.
Yea but since we are setting the paragraph margin-bot to 0 and Crayons top to 0 shouldn’t that make them be exactly close to each other ? The odd thing about it is that (at least in my case, not sure if your tests show the same results) regardless if you set margin-top to 0/2/5/10/12px the distance between the p element and the code is always the same.
As you mentioned the css does change accordingly to what you set the margin, based on what inspect object shows, but visually there is no difference. Also higher values than 12px show properly, the same with negative values.
In other words, I’m trying to figure out why this happens since the css values look to have been set correctly.
p elements margin-bot is 0
crayon-<random id> margin-top is 0 (when set to 0)
So in theory that 18px above the code shouldn’t exist isn’t that right ?
Not sure about that. Using a negative margin worked, but there shouldn’t be any spacing if both margins are 0. Ensure this is the case in the chrome inspector and check some other properties to find the culprit.
I am assuming you are not having the same issue in that case ?
I just noticed in the source code that for some odd reason there is another <p> element above the pre tag which shouldn’t be there. So I’m not sure where that one comes from but it explains the issue since my <p> tags have a default bottom margin. I’m not sure where that extra paragraph comes from as it’s not in my post code.
Does Crayons adds an extra <p> element above the ‘pre’ div ? Since all my posts have an extra <p> tag above the ‘pre’ tags now which shouldn’t be there.
