Monday, 17 June 2013

Free tools are appreciated but bugs are annoying

This morning I was trying to fix a problem where paragraphs aren't saved when editing a page in Wordpress' visual editor. In the visual editor the page appears formatted correctly, but when you save or preview the page / post, the paragraph spacing is stripped out, resulting in extremely long blocks of text.

Searching, it seems that this is a common problem. One solution said to install the TinyMCE Advanced plugin. So I did this, and in the settings it has the following:

Stop removing the <p> and <br /> tags when saving and show them in the HTML editor. This will make it possible to use more advanced coding in the HTML editor without the back-end filtering affecting it much. However it may behave unexpectedly in rare cases, so test it thoroughly before enabling it permanently. Also line breaks in the HTML editor would still affect the output, in particular do not use empty lines, line breaks inside HTML tags or multiple <br /> tags.

So, unfortunately this fix isn't that great for me. It does work in making it so that paragraphs and line breaks in the visual editor are saved. But the fact that it adds <br /> tags to new lines in HTML is the problem. In HTML (Text) view I want what I type to be saved without being manipulated by WP. Still, it is the best fix I have found so far.

If you're wondering why I would want to use the Visual and Text views when editing, I like to only use the text view. But this particular site is meant for use by other editors as well, and they are unlikely to want to learn HTML, and so will want to use the visual view.

Another problem I had was that whenever I uploaded a file (using WP's page editor interface, not via FTP), the file would be put into an old date folder. The date folder it would go into was based on the date that the page the file was being added to was originally created. So, if I created a page in Oct 2005, and then uploaded a new file to that page (using 'Add media'), the new file would be placed in /wp-content/uploads/2005/10/filename.ext.

Obviously, when you have a page where you're regularly replacing old 'media' with new 'media', the new files being put into the old date folder isn't great. It makes it look like the file might actually be really old rather than current. One solution to this is to not upload media via the page / post editing interface. This isn't great though, as it involves a number of extra steps, and also means that you must remember not to upload media when editing a page.

The other solution is simply to turn off the option Organize my uploads into month- and year-based folders in Settings > Media. I decided to go with this solution.

Quite a bit of the afternoon I played on Animal Crossing: A new leaf, which we received today. Unfortunately Billy had already been on it and bought the tools, so I couldn't do much other than shake trees and talk to people. I got stung by bees twice when shaking trees, but also found quite a few 100 bell coins.

As part of the replacement for yuicompressor (which is now deprecated), I tried setting up CSSMin today. It took me some time to get it working, mainly because I wasn't quite sure on the exact syntax to get it working from the command line. When I did get it working, I found that it had a bug where it only removes the start and end of comment blocks (/* and */), and not the actual comment content.

Obviously not ideal, since the content of the comment is then no longer a comment, and will mess up the CSS. (It won't validate and could possibly cause other problems depending on the comment content). I checked if this is a known issue, and it is: CSSMin: Comments not completely removed. The bug was opened in April 2012, so is over 1 year old.

I tried to see if there were any recommended alternatives to CSSMin, but it seems that CSSMin is the industry standard. So until that bug is fixed, I will just have to stick with yuicompressor for my CSS minification.

No comments: