I was recently asked to code review a friend’s first Laravel app, and when I cloned the repository from GitHub I immediately noticed a few big, red flags. Many of these were common mistakes, so I thought I’d take a moment to discuss how we can safely handle credentials and/or sensitive information in our Laravel applications.
Tag: Composer
A WordPress plugin I’ve been working on recently needed to be able to accept configuration in a few different ways: users should be able to define a constant in the wp-config.php file or fill out a form within a settings screen. If the constant is defined, the setting screen should be aware of that and hide the setting, since the constant should take precedence.
This is a pretty common pattern in WordPress plugins, but it can get rather tricky to test; by design, once a constant is defined in PHP, you shouldn’t be able to change its value. PHPUnit has ways to work around this by running tests that define constants in separate processes, but this can seriously impact the performance of your test suite. Furthermore, the WordPress core test suite is pretty tightly coupled, so it doesn’t like when tests are run separately.
Last week, I found myself with two consecutive nights where my wife was busy with client work, so I found myself with some time after we put the toddler to bed. I had also had a stressful few weeks at work, where the things I was supposed to be working on kept getting de-prioritized so I could jump in and help other members of my team. Of course, ever-shifting priorities is nothing new for me (considering all but the last year and a half of my career has been in professional services), but it can still get frustrating when you just want to ship something.
A big part of what I do on a day-to-day basis is centered around WordPress. I work on the product team behind Liquid Web’s Managed WordPress and WooCommerce hosting platforms, and even when I’m writing Laravel applications they’re ultimately designed to support WordPress.
The more you work with WordPress, the more you see the same patterns repeating themselves. Registering scripts and styles, nonce verification, and custom meta boxes are things I can do in my sleep. Dig into third-party code and see yet another written using a Singleton pattern. Maybe the plugin author would appreciate if you refactored it to use namespaces, but of course there are no tests.
Sometimes you need a break, to just dig into something small enough that you can knock it out in a night or two but useful enough that you’re not coding for the sake of coding. That’s what I’ve done with two new micro-libraries: WP Cache Remember and One-Time Callbacks.
If you haven’t heard, Liquid Web is now the first company offering Managed WooCommerce hosting, which is a huge step forward in the world of WordPress-oriented e-commerce. As a result, I’ve been spending a lot of time over the last few weeks working on WooCommerce extensions that help improve the experience and performance of WooCommerce.
One of the main WooCommerce extensions I’ve been working on is WooCommerce Custom Orders Table, which takes the WooCommerce 3.x CRUD concept to its next logical point: storing order data in a custom, flat table instead of scattered throughout post meta. Mindsize worked with other members of my team at Liquid Web to build the initial version of the plugin, then I came in to fix a few bugs.
As you may be aware, I joined a Cincinnati-based startup, Growella, as their Director of Technology in mid-November. Since joining, I’ve been hard at work building our site (which is slated to launch within the next few weeks), building our hosting infrastructure, and generally being the point-person for all things technological at the company.
I’m already learning a lot in my new role, and I wanted an outlet to be able to share those things. I’m also very fortunate that the rest of the company embraces open source software, so I wanted a place (besides this blog) to share what Growella has been working on, the problems we’ve been solving, and any releases of new software.
With all of that in mind, I’m proud to announce that about an hour ago we launched the Engineering @ Growella blog.
Anyone who’s had to do code reviews on a team before can tell you that inconsistent coding standards add a lot of unnecessary noise to the review process. Even minor things like trailing whitespace, spaces v. tabs, code indentation, and whitespace (or lack thereof) around function declarations can cause merge conflicts and increase the time it takes to do a good code review.
Fortunately, coding standards are pretty easy to check, and there are great tools like PHP_CodeSniffer that can scan your codebase for issues with coding standards. WordPress has a well-defined set of coding standards, and there’s even a collection of PHP_CodeSniffer standards for WordPress. With Composer and a little bit of configuration we can check our coding standards, catch common security issues (missing input sanitization, output escaping, etc.), and even validate that everything’s well-documented.
We have the tools to write standards-compliant code, so now we just have to configure them and make them run automatically. That’s where my latest project comes in: I’m happy to announce WP Enforcer is available for your projects!
