On the Delicious Brains site, there's a tutorial posted asking WordPress plugin developers if their code is ready to work with Gutenberg, the next major release of the editor used in the popular blogging tool and content management system.

WordPress 5.0 is right around the corner with the flagship feature, the new Gutenberg editor, set to change the WordPress landscape dramatically. Gutenberg not only impacts how you write content in WordPress, but how developers build plugins for WordPress.

[...] In this post I’ll walk you through the process I took for making Intagrate, my Instagram WordPress plugin, Gutenberg-compatible, which will hopefully get you started on making your own plugins Gutenberg-ready.

The post starts with some general things to consider about Gutenberg's functionality as compared to the classic editor and some key places to check in your own plugins. They then provide a guide to testing your plugin by installing the standalone editor package. It then walks through the three main places to check functionality:

• custom post types
• custom meta boxes
• TinyMCE

The post ends with some suggestions of possible enhancements such as making use of shortcodes and converting custom meta boxes.

Martin Hujer has put together a new post to his site sharing some of the PhpStorm plugins he considers essential for Symfony development, making your life easier as you create applications with this popular framework.

I've been using PhpStorm for quite a while and I'm still surprised now and then when it suggests an auto-completion for something I thought that's not possible.

But there are still many things - usually framework- or library-specific - that PhpStorm cannot do on its own. But there are plugins that can step in place and do the magic for specific framework or library.

Several of the plugins are more for improving PHP development in general but others are more Symfony-specific:

• PHP Annotations
• PHP Toolbox
• Symfony Plugin
• PHPUnit Enhancement
• PHP composer.json support
• Php Inspections (EA Extended)
• Twig Support
• .env files support
• .ignore

Each item in the list comes with a brief introduction to the plugin, links to find out more information, and, in some cases, animations of it in use in the editor.

In a new post to his site Tomas Votruba goes into a "deep dive" of the functionality that the Symfony plugin for PhpStorm provides and some of the functionality it provides.

After very successful PHP 7.3 diffs post, let's dive to gifs of Symfony Plugin. You might know them, but they might surprise you like they did surprise me. Let's go!

He then walks through the installation process and some of the features the plugin includes:

• Enabling the plugin (via the PhpStorm configuration)
• Faster Translation Autocreate (TWIG)
• Autocomplete Translation Key (TWIG)
• Instant Service Autocomplete in YAML (YAML)
• Forget The Tag (YAML)
• Jump from Href to Route (TWIG)
• Instant Route in Controller (PHP)
• Faster Queries in Doctrine Repository (PHP)
• Template Autocomplete (PHP)

For each item in the list, there are animated gifs provided showing it in action. You can find out more about the plugin on the JetBrains site.

On the Delicious Brains site there's a new tutorial posted for the WordPress users out there sharing a case study of the performance impact of WP Offload S3 on the average page load time.

One of the great things about working at Delicious Brains is working on products that I use and love outside of work. I was a WP Migrate DB Pro customer well before joining the team and still use it daily on personal sites and side projects. However, I’ve not often had the need to use our other plugin, WP Offload S3 to offload site media files to Amazon S3.

The post starts with some of the background on why the author chose the WP Offload plugin in the first place and what features it provided. The tutorial then walks you through the installation process and how to have assets served up by Cloudfront correctly. It also includes some things you should consider when figuring out if this setup is for you. It then wraps up with some benchmarks of the results post-implementation, seeing a decrease of almost a second off of the previous page load time.

On the DeliciousBrains.com site they've posted a tutorial showing you how to create a WordPress plugin using Vue.js to make interaction with the page simpler (and nicer than just a normal page reload).

It’s been a while since we’ve played with Vue JS on this blog, so why don’t we take a beginner-focused look at how one might go about building a simple polling plugin for WordPress with Vue.

Why Vue? Vue can scale up to be used for full-blown single page applications, but you can also use it to add small bits of interactivity to sites, pages, or plugins where in the past you may have used jQuery.

[...] Why a polling plugin? There are scores of polling plugins for WordPress, most of them are free, and most of them will be better than the one we’re going to build today, but there is something missing from the current offering of polling plugins: none of them are polka themed…

They start off with the PHP code required to power the plugin (a.k.a. "Pollka King") and load the required resources. They make use of a shortcode to refer to the plugin and show the structure they'd like to use in the editor to create the poll. The backend and frontend code is included along with screenshots of how it should look along the way.

If you're a WordPress user and you've ever wondered about the process of creating your own custom plugin, this new tutorial from Delicious Brains might be just what you need. In it they go through their process for creating a plugin, from the initial ideas to release.

If you’ve been reading our blog for a while, you’ve probably seen some of our tutorials on developing plugins using different technologies like React and Vue. But when not writing examples for blog posts, we rarely if at all dive into creating a new plugin – there’s a lot more that goes into it before we write a single line of code.

In this week’s post, we’ll be taking a look at everything we do to create a new product or WordPress plugin. We don’t adhere strictly to any specific software development process, but the method we’re using currently seems to work well.

They then walk through the process, step-by-step, with a summary of each and helpful hints as you go along:

• Research and Brainstorming
• Wireframes
• Developing the Plugin
• Reviewing and Testing

The post ends with some concluding thoughts about the amount of work required, scope creep and the value of planning/wireframes.

On the Delicious Brains site they have a new post that makes a suggestion to the WordPress plugin developers out there: stop supporting legacy versions of your plugins and move on.

I recently saw this tweet from Danny van Kooten which reminded me of one of the many major gripes developers have with WordPress – supporting ancient PHP versions:

"STOP SUPPORTING PHP 5.2 IN YOUR NEW PROJECTS. No one using it is actively installing plugins, trust me."

Yes, (unbelievably) WordPress still supports installations of PHP 5.2.4! As plugin developers, we can’t change that over night but we have the power to stop supporting these legacy versions in our plugins where we have control over the codebase.

He talks about how, despite the fact that the WordPress project itself strives for ultimate backwards compatibility, it's just not run on older versions of PHP as much. They share some statistics about the number of WordPress installs on each version of PHP starting with v5.2. The results show that the overwhelming majority are on v5.6 with a split between <=5.3 and >=7.0 for the remainder. They also share some statistics from their own plugins finding that the >=7.0 takes the lead.

The post then shares some of the reasons for making the upgrade to only support newer versions of the language including security updates, speed and developer experience. It finishes up with some of the steps to follow to inform users of the intent to deprecate old support and when to make the move.

On the QuickerWP blog there's a new post with some recommendations of plugins and techniques you can use to make your WordPress blog "fly" (increase the overall performance).

WordPress sites are notorious for their poor loading times. The platform itself comes with very few optimizations, and once you start adding plugins, things will only go south from there. [...] Most of the performance penalties actually come from having too many plugins installed, a poorly optimized site configuration, and a theme that does not optimize loading speeds (most of them don’t).

[...] It’s rare to see high marks [on Yellow Lab Tools] (a B or A result), but after applying the tweaks listed here, we’ve managed to get our own site to score an A (92/100) result, and surprisingly low loading times. Try it on your site to see how you fare.

They have a list of seven recommendations:

• Autoptimize plugin
• WP Fastest Cache plugin
• PurifyCSS
• TinyPNG plugin
• Guetzli (for image optimization)
• CSS Sprites
• QuickerWP

Each item in the list comes with a brief description of the enhancement it brings to the table and links to find out more information.

Asmir Mustafic has continued his series looking at building modular applications with part five looking specifically at some of the considerations and ideas to keep in mind when developing your modular applications.

This is the fifth post from a series of posts that will describe strategies to build modular and extensible applications. In this post we will take a general overview on how some popular design patterns and things to keep in mind when creating plugin based applications.

[...] Anthony Ferrara (alias ircmaxell), in this post blogged about the use of software patterns to implement plugin-based architectures. It is a great article and I suggest everybody to read it. As it is clear from the article, each of this software patterns has a specific use case and the choice of which one to use depends on which the of integration we want allow for the future plugins.

The article starts with a brief recap of some of the more common design patterns including the Observer, Strategy, Decorator and Chain of Responsibility. It then covers some quick uses of these patterns and shares two tips when developing a plugin system for the application and links to good examples for reference.

On the Symfony blog there's a post that reminds you, at a time of year when giving is top of mind of a lot of people, to say thank you to the libraries you depend on.

If you're like me, you build apps that depend on a lot of great PHP libraries that are maintained by countless talented developers. That's amazing! The PHP community has come so far! And while I try my best to contribute back, it's tough to show appreciation for all these efforts.

Sometimes, I just want to send some ???? and shout THANKS!

To make it easier, they've released the Thanks composer plugin that will star every package your project depends on automatically to show them your appreciation. It may seem like a little thing to do but project maintainers love to know that their work is appreciated. If you want to show even more appreciation consider emailing the team or individuals working on the project and let them know.

It's easy to get discouraged when working on an Open Source project and hearing back from the users of the library can do wonders for the maintainers and contributors.