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. :)