Today we did our first Google Day. For those of you who don’t know the 20% time offer, Google offers her employees 20% of their time to work on side projects. We decided that the side projects we work on are preferably projects that benefit the company in the long run, but can be anything.
At first I wanted to (finally) dive into some other programming language, like Ruby or finally get my hands on some Node.js. None of this all happened though, as we discovered during some discussion that we really needed a project management tool and we never took the time to properly set things up. Continue reading “Our first Google Day”
I see this question over and over again. With the amount of PHP frameworks being available, it’s not hard to imagine how confused a learning PHP developer must feel when they try to pick the right framework. While in reality, it doesn’t really matter what PHP framework you choose. Laravel, Symfony, Zend, all are really well thought out and maintained frameworks. They are different, of course, but you won’t hurt yourself by picking one over the other. Continue reading “It doesn’t matter what PHP framework you choose”
Earlier this year, I made the decision to stop doing full time WordPress work. In my new day job, I still work with WordPress though. The big difference is that I now have a bigger toolbox to select the best tool for the job at hand from.
Working on just WordPress projects for a couple of years was great. In fact, I would do it again right away if I had to. For me it was great though, to step out of the WordPress bubble and start using different frameworks and technologies that are better suitable for the project. Continue reading “Why I don’t do full time WordPress work anymore”
Last night I published my first ever vlog. After discussing it with them for a while, Daniel Espinoza and Matt Stauffer had started publishing their first vlogs already, so it was time for me to step up and do what I announced earlier.
Making this video was the most awkward thing I have done in a long time, but I’m happy it’s out there now. It feels like future videos will be easier to make now this first one is done. Continue reading “My first ever vlog…”
For a while now, I’ve been trying to think of ways to do more with video. At the top of my todo list is something called “the vlog experiment”.
I asked on Twitter why I didn’t know of any developers who post vlogs. I got a lot of responses, but nobody was able to name someone. Finally, Jeffrey Way’s response gave me the push I needed. The fact that there are no developers out there posting vlogs, probably means that there is room for someone to start doing this (or it means that it’s a bad idea, but let’s not assume that’s the case…). Continue reading “Vlogging as a developer”
We’ve been telling customers to always be on the latest and greatest version of everything WordPress related. It has become the de facto answer to any bug report: “Are you running the latest version of plugin x and y?”. That’s fine, for most use cases. But what if I’m in a situation where I can’t be at the latest version? Or what if I find a bug in the latest version and have to restore to an older version?
I’m not a sysadmin by any means, but I like to think that I know how to setup a little server environment. Having used Vagrant for a long time now helps, it definitely lowered the bar of getting into it.
One thing that has puzzled me for quite some time, is so silly that I wanted to document it. Maybe I can have a good laugh about it when I look back at this in a couple months. Long story short: PHP uses a different php.ini file for each program it loads in. This can be in the command line, or anything really.
So if you want to install the mcrypt extension for example (in my case on Ubuntu: sudo apt-get install php5-mcrypt) and wonder why it isn’t loading when you use PHP on the command line; make sure the extension is loaded in /etc/php5/cli/php.ini. In case you use PHP-FPM as well, make sure to load the extension in /etc/php5/fpm/php.ini as well.
I have spent hours to find it, only to forget this is a thing a couple weeks later when it showed up again. Call me silly, but a quick Google search learned me that lots of people are struggling with this issue as well. If this post isn’t just going to give me a good laugh when I find it in a couple months, maybe it will help someone who stumbles upon it.
Ever since Barry announced that he’s working on a related posts plugin, I’ve been keeping track of the project. Now that it’s available, the reviews for the free plugin have been five stars all the way, so there must be something good in it, right?
The one thing that has always been a challenge for related posts plugins, is performance. Related Posts for WordPress makes a bold statement about that:
Related Posts for WordPress won’t lag your server!
We don’t think having related posts should slow down your website. That’s why Related Posts for WordPress creates its own cache and does all the heavy lifting in the admin panel, keeping your website fast as it should be!
Andrey Savchenko, better known as Rarst, announced that he’s removing all his WordPress plugins from the official repository. He’s been talking about it for a while, but now finally pulled the trigger on this decision.
Things like the mandatory support forum for each plugin, without the option to disable it or use an external support system, is something that has been bugging me a lot. Now WordPress core will start accepting pull requests on GitHub (as announced in Matt’s Town Hall talk at WordCamp San Francisco), the version control state of the plugins repository becomes even more painful:
While SVN is usable it is hardly pleasant or popular for modern development, lacking in newer distributed version control paradigms, performance, and other conveniences. More so WordPress actively discourages using its repository for active development, reducing it to storage mechanism with updates only happening for release versions.
I agree on a lot of Rarst his points, but am not really at the point of removing my plugins from the repository myself. What I do hope, is that decisions and bold statements like this post can become a catalyst for all the changes in the WordPress ecosystem.
Yesterday, Sucuri published a very detailed document about a critical vulnerability in the Slider Revolution plugin. This is a vulnerability that’s about as bad as they can get. It allows access to files like wp-config.php and makes it fairly easy to compromise a website.
This wouldn’t be so bad if it wasn’t the case where the plugin author decided to not disclose the vulnerability and patch it without notifying their users:
The problem was fixed 29 updates back in 4.2 in February. We were told not to make the exploit public by several security companies so that the instructions of how to hack the slider will not appear on the web.
Right now, the exploit is being actively exploited and lots of websites are compromised because of it. But it gets worse. This plugin is bundled in a ton of themes sold on the internet, including some very popular themes on ThemeForest and other marketplaces. All of those sites are probably vulnerable to this exploit and can be compromised within seconds.