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?
Of course, we run our version control for websites. We can restore older versions of plugins after we find a bug. This requires us to have the premium plugin in our own version control, writing our own history. While this works fine, there are a couple really big downsides to this. Continue Reading…
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!
So it’s free, gets five star reviews all the time and is not making my site any slower? Sounds too good to be true? Well, the new premium version of the plugin adds even more juice. It offers related posts for all (including custom) post types, support for all (custom) taxonomies and themes for the output of the related posts (no coding required). Continue Reading…
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.
The good news is, there is a patch available. Users of the plugin can just update and the vulnerability will go away and their website will be safe again. There is only one problem. The themes that come with this plugin bundled, probably have no idea this vulnerability even exists and more important: They have no easy way to update the plugin. Yikes. Continue Reading…
I don’t mind people emailing me about issues they are having with my code. Whether it’s some old snippet I posted on a GitHub gist, or when people contact me about something they stumbled upon with WooCommerce (even though I’m no longer working for WooThemes).
Sometimes I know the answer, sometimes I can only point them in the right direction. I my best to make sure they can overcome their issue, whatever it is.
In order to continue doing this, I maintain one strict rule: Explain the issue properly. Emails that just say “it doesn’t work” are likely to get trashed. You don’t drive you car into the garage and tell the mechanic that. Continue Reading…
It’s little over 2 months since I left my job at WooThemes. As I explained in that post, this didn’t mean that I was never going to look at WooCommerce or any other WordPress project again. In fact, I’ve been working on a couple WooCommerce related projects since I’ve started my new job.
With the recent addition of fellow Dutchman Barry Kooij to the team, I’m sure they have enough development power to make sure WooCommerce continues to grow. And because more and more people start to use the plugin (as a developer or a business owner), the ecosystem around it is growing as well.
Being outside of the WooCommerce core development team for 2 months now, made me look at the plugin with a different set of eyes. Continue Reading…
I have some exciting news to share today. This month will be my last month at WooThemes. Starting June, I will be joining Radish Concepts. It’s a new company (note the lack of a proper website ), managed by Richard, David and Arjan, in which I wil be forming the main development team with Gaya and Arno joins as designer. I’m really excited to jump in new challenges, continue to learn and develop my coding skills and work on cool projects.
Over the past months I’ve learned that I wanted to expand my knowledge on other programming languages, frameworks and get a larger toolbox for my web development work. In my spare time, I’ve always been investing in my development skills by coding on various side/test projects, based on different frameworks.
As much as I love WordPress and the growing ecosystem around it, I no longer want to be exclusively developing WordPress products. At my new job, I will be working with various projects, based on Laravel, OpenCart and others, but also WordPress powered projects still. This doesn’t mean I’m saying goodbye to WordPress, but will give me a broader set of tools to work with. Continue Reading…
Some people asked me this question on Twitter and I always pointed them to the support forums we’ve got. When this question got asked for the 10th time this week, I figured I had to check if this was actually any different in WooCommerce 2.1 now. Turns out, it’s not. It still works the same as it did in previous versions.
Hi! In new WooCommerce 2.1.2, how can I change the number of shop columns? All fixes that I can find on Google are not working in this release.
Well, here we go. Let’s debunk this myth that it’s no longer working by showing some examples. Continue Reading…
While I’m sitting in the departure area at Schiphol Airport, sipping on a Starbucks drink, I suddenly realised that it was over three weeks since my last post here. So far so good with my blogging resolutions…
And now there’s a special of the Dutch Webdesigner Magazine being published, with two articles by me in it. To top that off, I’ll be speaking at WordCamp Norway this weekend. People will visit this site and will see a very inactive blog, so this is just a quick update that I’m still alive and will get into blogging more soon.
If you are at WordCamp Norway this weekend, come say hi and we’ll have a chat. I’d love to talk to people using WooCommerce, or about any subject really.