For a recent project, I had a need for a pretty simple workflow. I had a couple of image sizes, which I added with the add_image_size function which required a hard crop to a certain aspect ratio. The workflow for authors I was looking for was:

1. Upload Image
2. Edit the crop for these special sizes if they feel like
3. Insert into post

All of this on the same screen. After installing and downloading a bunch of different options, I’m going to formally recommend Manual Image Crop.

It’s not the prettiest option (that’s Post Thumbnail Editor), but it is the simplest and most flexible. It has a few options for each image size, but basically once you upload your image you can select the “Crop Image” option and then automatically create a new image crop for each size. And everything is brought into a pop-up window so you never have to leave the Media Uploader.

...]

I use Bootstrap as a starting point for a lot of the themes that I build as a great starting point for reusable components. But one of the problems I’ve run into is trying to integrate Gravity Forms with Bootstrap. By default, Gravity Forms does not include Bootstrap classes, so the two don’t end up working very well together.

Fortunately, with a little bit of elbow grease, there’s a way to tweak Gravity Forms markup and styles to match a default Bootstrap form. The solution I’ve found is a combination of a single hook and some SASS / CSS tweaks to get everything off the ground.

For reference, a typical Bootstrap form should be marked up something like this:

<form> <fieldset class="form-group"> <label for="formGroupExampleInput">Example label</label> <input type="text" class="form-control" id="formGroupExampleInput" placeholder="Example input"> </fieldset> <fieldset class="form-group"> <label for="formGroupExampleInput2">Another label</label> <input type="text" class="form-control" id="formGroupExampleInput2" placeholder="Another input"> </fieldset> <button type="submit" class="btn btn-primary">Submit</button> </form>

I’m using version 4 of Bootstrap, but things are pretty much the same in older versions of Bootstrap as well. There are really two things that are important in this markup. The first is that [...]

In the WordPress community there’s this elephant in the room that no one really likes to talk about (understandably). For some reason, there’s a lot of developers that really don’t like using WordPress. Need proof? Stack Overflow just released the results of their 2016 survey. And as Ryan McCue pointed out on Twitter, 74% of developers dreaded the idea of using WordPress. I get it, results are biased, and Stack Overflow tends to skew towards trends. But still. It’s a sentiment we’re all well aware of.

Back to McCue:

We *have* to do something about this. It is so insanely unbelievable.

— Ryan McCue ⍨ (@rmccue) March 17, 2016

Agreed.

On the flip side of the equation, the most loved technologies of this year are things like Rust, Swift, React and Node. Here’s the thing. I know we don’t want WordPress to be as decoupled as Node, or to ditch backwards compatibility like Rust. We don’t need WordPress to be at the top of the list, and it’s unrealistic to think it ever could. What we want is for WordPress to sit right in the middle, alongside other technologies that people enjoy using, but don’t [...]

I recently ran into a problem when using the Advanced Custom Fields plugin which is a bit esoteric. In the previous iteration of the site I was working on, fields were registered programmatically, using acf_add_local_field_group and acf_add_local_field. In the new version, we decided to move these back into the GUI on the admin panel.

For most of the fields, all we had to do was replicate the field group and field names / labels and everything worked fine, even on existing posts. However, repeatable and flexible fields would not show up for posts that had already been created.

The problem was with the field keys. When I created the fields in the admin panel, they were assigned a different field key, and thus existing content didn’t work anymore.

I found a post that outlined a fix on the plugin’s forums and it actually worked pretty well. Basically, you can go into the edit screen in the admin, and inspect element or use firebug to open up the HTML source. Find the HTML element that the repeatable parent field or flexible field is wrapped in, and remove the “meta” class from this. Then you can find the hidden field that has a the field key in [...]