After some digging around and troubleshooting, I managed to fix the DsgnWrks Instagram Importer WordPress plugin on my site. It turns out quite a few people had an issue with it, which started back in September/October of last year (2017). The solution, they say, is just to remove the authenticated Instagram user from the plugin settings, and add it again. I’m not quite sure if that’s the only thing that helped, as I’ve adjusted quite a few other things all around (HAProxy timeouts, Nginx timeouts, PHP maximum execution time, etc). But it seems like the right thing to start with.
Keep in mind that you should backup the current user’s settings for the plugin (screenshot or save the page as HTML or just copy-paste them somewhere), because they will be reset to the defaults when the user is re-added.
I have just now imported about 40 Instagram pictures that weren’t synchronized since the last September. Enjoy!
Here are some very exciting news from the WordPress fronts: WordPress 5 will feature the built-in Gutenberg project. Gutenberg is a complete rebuilt of the WordPress administration and content publishing experience, with much faster and cleaner user interface and a whole array of new features, such as “page builder” functionality.
Here are a couple of links with more information on how to get yourself ready in time:
My WordPress radar noticed a new website – wpplugincheck. This website provides in-depth reviews of WordPress plugins. I’ve checked a few of those and they seem solid – honest and to the point.
There’s a gadzillion of websites online that review WordPress plugins (occasionally including even my own blog), but most of those either get too commercial with sponsored posts, or turn into collections of “5 best of this” and “7 awesome of this”. I hope the site continues and gets into a routine of publishing reviews of the new and updated plugins, especially focusing on the areas where there are a lot of choices, or not enough.
WordPress is an excellent system for a whole lot of different projects and needs. It’s widely used, fast, and flexible. However it does show its age in many ways. One of the areas where things could be a lot better and simpler is the WordPress plugin development.
WordPress plugins are still non-trivial to develop. This is mostly because WordPress is behind the current technology in many ways: new features of PHP programming language, such as Object-Oriented Programming (OOP), namespaces, dependency management with composer, unit testing, etc. There are good reasons for this, but those don’t help WordPress plugin developers.
What does help is, for example, this WordPress Plugin Boilerplate, which is a standardized, organized, object-oriented foundation for building high-quality WordPress plugins. Using it still requires a bit of effort and dumb find-replace changes. But it saves a tonne of time, as well as trial and error, especially for those people who are working on their first or second WordPress plugin.
The other day I came across this blog post by Mark Jaquith, who is one of the lead contributors to WordPress, in which he describes his process of updating WordPress plugins with WP-CLI and Git. I think a lot of people these days are trying to use Git for version control and automate their deployments, so WordPress developers aren’t an exception, and Mark’s post is a useful resource for that.
With that said, however, I think there is a better. At work, we’ve been dealing with quite a few WordPress-based projects, and automation of builds and deploys is very important to us. So we’ve taken a different approach.
The initial inspiration for our approach was taken from this blog post by Scott Walkinshaw of the amazing Roots team.
Yes, that’s right, we use Composer to manage the WordPress, plugins and themes, both during the initial installation and the upgrades later. But we’ve taken it a step further by also integrating the WP-CLI to our setup, which you can find in our project-template-wordpress GitHub repository.
I have oversimplified both the development and deployment process below, mostly for clarity. (We do a lot more automation for our needs.)
During the development:
- Configure Composer to install WordPress into the webroot/wp folder.
- Configure Composer to install plugins and themes into webroot/wp-content folder. (Notice: we use a different wp-content folder location from the default WordPress one).
- Adjust wp-config.php for the new paths and drop it into the webroot/ folder.
- Add Composer’s vendor/ folder, and both webroot/wp and webroot/wp-content to .gitignore.
- Add all required themes and plugins to the composer.json.
- Run composer update to create or update the composer.lock file.
- Commit both composer.json and composer.lock, as well as .gitignore and any other files you modified.
- Add a WP-CLI script that automates activation of plugins and sets the current theme.
- Push your changes to the git repository.
During the deployment:
- Clone or pull the changes from the git repository.
- Run composer install to fetch and install specific versions of WordPress, plugins, and themes, from the composer.lock file.
- Run the WP-CLI script to finalize the installation or update with the plugin activation, theme selection, etc.
While it might look a little bit more complicated than what Mark and Scott described in their respective blog posts, I think this is a better approach for the following reasons:
- Use a specialized tool to solve each problem. Git is great for version control, so that’s what it should do. Composer is great for managing dependencies, and that’s what WordPress and its themes and plugins are for your project. WP-CLI is great for automating WordPress tasks.
- Keep the git repository clean and simple. When working on a project, we never ever modify the code of the WordPress or any of its themes or plugins. And our setup enforces this approach. If you need to change the WordPress source code for a particular project, you are probably doing something wrong. If you need to change the plugin’s source code or the theme’s source code, you are probably doing something wrong again. Instead create child theme or your own version of the plugin and install those with Composer, keeping the plugin or theme related code changes in a separate repository.
- Easily extendable and customizeable. Git, composer, and WP-CLI are great tools and we love using them. But the world is moving forward and there are constantly more and better tools to help with the complexities of the web development. Our setup expands and extends to welcome any tools that we find useful. For example, we have integrated with Robo, PHPUnit and PHP Code Sniffer, TravisCI, BitBucket Pipelines, and many other tools over time. We’ve also said good bye to a few that became obsolete or to which we found better alternatives.
Anyways, project-template-wordpress works quite well for us and I hope you’ll find it useful. Give it a try and let us know if you find any issues or improvements. Pull Requests are welcome. :)
I’ve done a little spring cleaning of some plugins installed and activated on this site. You shouldn’t notice much of a difference, except, maybe, fewer quirks and issues. Here are some of the plugins that were removed:
- Smart YouTube Pro – it was only used in a couple of posts for easier embedding of YouTube playlists. Since I installed and used this plugin, WordPress got much better at embedding videos, so I don’t need it anymore.
- Smart 404 – I think I used it with one of the previous themes on this site, but I can’t even remember last time I saw it working. The 404 page of the current theme features a search form, which I think is good enough.
- PayPal Donations – this was an experiment I tried ages and ages ago. No need for this at all for quite some time now.
- Related Posts By Tags – I used this with one of the previous themes, but it’s been ages since, and I think even the plugin is discontinued now.
- Social – the plugin has been discontinued and the functionality was moved to JetPack. I had this one disabled for quite some time now.
- WP-Polls – this was yet another experiment I tried years ago. There were a few polls with a few votes, which prevented me from removing this plugin. But today I thought I’d do a compromise. I replaced all polls with the screenshot of voting results for the purposes of data preservation. :) Now I don’t need the plugin anymore and it’s gone.
WPBeginner, a website for beginner guides to WordPress, has published an updated and comprehensive guide to WordPress security – “The Ultimate WordPress Security Guide – Step by Step (2017)“. Most of the things are well known to seasoned WordPress users – keep things updated, use strong passwords, remove unnecessary plugins, make sure to pick the right hosting, add security enhancing plugins, etc. But it’s a good place to start for people who are not too technical and those who don’t think about security implications of having a publicly accessible website on a daily basis.
There are plenty of questions, answers, simple explanations, and links to other resources in the article. So even if you are an experienced WordPress user, you might find a useful thing or two in there.
You might also want to checkout my earlier blog posts:
Supercharge your ecommerce is a collection of reviews of some of the best ecommerce plugins for WordPress. It covers a variety of options from the most famous like WooCommerce to some less known ones. Here’s a list of of what’s reviewed:
As described in “Introducing WP Image Processing Queue – On‑the‑Fly Image Processing Done Right“, Image Processing Queue plugin tries to solve several issues with On-The-Fly Image Processing (OTFIP) in WordPress. Some of the things that it improves are:
- Response times for pages with non-yet generated thumbnails.
- Server CPU spikes for pages which use a lot of images on sites with a lot of configured thumbnail sizes (49? really? WOW! I don’t think I’ve seen more than 10 in the wild, which is still a lot).
- Server disk space issues caused by removed images and leftover thumbnails.
This is a very useful direction and I hope all the necessary bits will make it into the WordPress core. But even for those who don’t use WordPress, the whole discussion and implementation are a handy reference.
WP-CFM is a WordPress plugin which helps to manage and deploy WordPress configuration changes between different sites. I haven’t tried it myself yet, but it looks super useful as it allows to separate the configuration options from the content, both of which are stored in the database. The cherry on top here is the support for WP-CLI, command line interface to WordPress, which is frequently employed for automatically deploying WordPress to different servers and environments.
I have a feeling this plugin will be making its way into our project-template-wordpress setup pretty soon.