WordPress 4.1 “Dinah” is out and available for download (this blog has just been updated). This release features a new default theme – twentyfifteen, Vine embeds, plugin recommendations, and complex queries for metadata, date, and terms – this one is for developers mostly.
phpdotenv – Loads environment variables from .env file to getenv(), $_ENV and $_SERVER automagically
Documattic – WordPress presentations and resources shared by WordPress.com VIP
PageLines DMS 2 is a drag-n-drop design system with support for all the coolest bells and whistles – responsive design, multiple layouts, support e-commerce, embedded videos, paralax effects, plenty of built-in icons, shortcodes and more!
Just wanted to let you all know that I’ve made a couple of changes recently, which should result in a somewhat faster performance of this site.
Firstly, before the last weekend, I’ve moved all my DNS hosting to Amazon Route 53 service. This should result in faster DNS queries all around the globe and minimize the potential downtimes.
Secondly, I’ve installed and configured the JS & CSS Optimizer WordPress plugin, which now results in much fewer HTTP requests needed to load the page, as well as fewer bytes to be transferred around. I’m still tweaking the settings for this one to see how much I can squeeze out of it, but I already see an improvement.
As always, if you see any issues, please let me know.
WordPress 4.0 Beta 1 is now available! Here are some of the changes:
- Previews of embeds like YouTube and Vimeo.
- Improved plugin installation experience.
- Selecting a language during/for the installation process.
- Improvements to the editor (somewhat needed after the recent upgrade of TinyMCE major version).
- Separate panel for Widgets in the Customizer.
This is a good old case of “Don’t trust any user input”, reinforced with “especially if they are using Microsoft tools”.
I had an interesting problem today. I was uploading a third-party theme to a WordPress hosted on the server that I don’t control and really don’t have much access to. The server had a limitation of the upload size set to 10 MB. Yeah, I know. But not much I could do about that. The theme that I was uploading was packed into an 11 MB ZIP file. The theme itself was rather complicated (one of those commercially developed themes that are based on a framework and bring in a few plugins required for their functionality), so I couldn’t really remove anything from it.
Upon a quick inspection, I realized that more than half of the ZIP weight is due to a multitude of PNG images. And while some image were small and legitimate – like, say, icons – quite a few others were packing lots of bytes for nothing – demos, sample images, and such. Obviously, I wanted to reduce the size of these files significantly.
My usual tool of choice for such tasks is usually ImageMagick. To tell you the truth, I rarely work with PNG images. JPEGs are a more frequent target for me. So, I didn’t realize that ImageMagick handles -quality parameter differently for different image formats as fast as I’d like. But even when I did, the results weren’t all that great. In fact, the file sizes slightly grew in my tests.
Looking for a different approach, I came across this article about a tool called optipng, which can be conveniently installed in Fedora via yum. Unleashing this tool onto my PNG image collection showed me that whoever made the WordPress theme new what they were doing. opmipng reported that all images are already optimized and there isn’t much to do.
That’s when I found yet another tool to play with. This discussion at
StackOverflow SuperUser suggests pngquant, which is also a breeze to install on Fedora with yum. So finally, I did something like this:
$ sudo yum install -y pngquant $ cd folder/with/images $ pngquant --force --ext .png --quality=0-75 *.png
That gave me exactly what I needed – a sufficient enough reduction in file sizes for the ZIP archive to fit into the upload limit set on the server.
I joined Easy Forex back in 2012 to work on a rather complex project – migrate main website of the company from a really outdated version of DotNetNuke to WordPress. WordPress, even though it is an absolutely amazing platform, turned out not to be the right tool for the job. But we’ve managed to deliver anyway. One of the annoying practices that we had to employ though was a semaphore flag for the database changes – only a single developer could work on the database at any given time. (Again, this wasn’t a WordPress limitation, but rather specifics of our environment at the time). That was the time when we introduced the Semaphore Bull to our development process.
It worked out quite well. But being a soft toy, it got abused a lot along the way. It lost a leg, which was screwed in for a while. Then it nearly lost the whole butt. Then the head. Beaten, barely alive, it still stood its ground and did the job! At some point it got so bad, that we’ve had to place it into the plastic container, where it survived for a few more month.
Today we’ve finalized our migration of the main website from WordPress to CakePHP. The system is so simple now that we don’t even need a database anymore. And with that, the job of the Semaphore Bull ends. Gone, but not forgotten though!
Because of its huge contribution to our work, because it saved us from countless painful hours of resolving SQL conflicts, we’ve decided to create a memorial. Ironically, the memorial to Semaphore Bull is built out Semaphore Bull itself, and the container it lived in. For the future generations to remember the deed, we’ve printed out the snippet of the developer’s manual and embedded it into the memorial together with the dates. Here’s how it looks altogether now.
Thank you, Semaphore Bull. You’ve done us a great service. Rest in peace.