Taking Back Our Privacy

There’s a lot I like about Anna Wiener’s look at Moxie Marlinspike and Signal, and she frames it in a modern context couched in the beliefs of Marlinspike, who has done some great things. There’s a lot of strong assertions about privacy which are needed. But I was struck by this passage, which is kind of mentioned in passing:

What we didn’t necessarily anticipate, when everyone was so optimistic, was how little it would change things. The dream was always that, if someone in the suburbs of St. Louis got killed by a cop, immediately everyone would know about it. At the time, it was a sort of foregone conclusion that that would be enough.” “Enough for what?” I asked. “To prevent that from happening,” he replied, flatly.

The Hidden Power

I recently had a chance to go back and read Jane Mayer’s incredible profile on David Addigton, Cheney’s right-hand man during the Bush years. She outlines the power-play that Cheney and Addington engaged in, pulling from a Reagan era playbook to expand the powers of the Presidency to extralegal judicial rulings and commissions, and even to spying on U.S. citizens. An incredible read.

Link

Looking for Social Media WordPress Plugin

There was this WordPress social media plugin from a couple of years ago that used Zapier templates to pull things in (or push them out, can’t remember). Anyone know what I’m talking about? #lazyweb

Accessing the Web in 1994

Step by step guide to using Mosaic for Windows circa 1994. Crazy amount of steps. Make sure you edit that Mosaic.ini file. https://practical-tech.com/1994/07/02/putting-the-pieces-together-mosaic/84/

Editing Crop in WordPress Images Before Upload

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.

Screen Shot 2016-04-13 at 3.46.00 PM

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.

Screen Shot 2016-04-13 at 3.46.58 PM

So anyway, if you’re looking for a good post thumbnail crop editor, try out Manual Image Crop.

Using Gravity Forms with Bootstrap Styles

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 a class of form-group is used on an input’s wrapper element (fieldset in this case). The second is that a class of form-group is added to each input. Cool, let’s step through this.

The first step is to wrap inputs in an element with a class of form-group then. That’s actually pretty simple. There’s a Gravity Form filter called gform_field_container that can be used to change the markup of the list item for each input. So all we have to do is ensure that the form-group class is added here, which we can do with a simple one-line function:

add_filter( 'gform_field_container', 'add_bootstrap_container_class', 10, 6 );
function add_bootstrap_container_class( $field_container, $field, $form, $css_class, $style, $field_content ) {
  $id = $field->id;
  $field_id = is_admin() || empty( $form ) ? "field_{$id}" : 'field_' . $form['id'] . "_$id";
  return '<li id="' . $field_id . '" class="' . $css_class . ' form-group">{FIELD_CONTENT}</li>';
}

Now each input will be wrapped in the proper form-group class, along with any classes Gravity Forms wants to add.

The second part, adding a form-group class to every input element, is a little trickier. There are actions that let you edit the actual markup of inputs, but there’s nothing that just lets you filter input classes, which means you’ll end up rewriting the entire input function. Things get complicated fast, and I just haven’t found that to be a very smart way to go. Here’s the solution I’ve found works best: Instead of adding Bootstrap classes to Gravity Forms, we customize Gravity Forms classes to match Bootstrap classes.

If you’re using SASS, this is super easy thanks to @extend, which allows you to apply styles from one class to another. So we just need to extend Bootstrap styles to the Gravity Form’s CSS. Which looks like this:

.gform_fields {
  @extend .list-unstyled;
  @extend .row;
 
  input, select, textarea {
    @extend .form-control;
  }
 
  textarea {
    height: auto;
  }
 
}
 
.gfield_description {
  @extend .alert;
}
 
.validation_error {
  @extend .alert;
  @extend .alert-danger;
}
 
.validation_message {
  @extend .alert;
  @extend .alert-success;
}
 
.gform_button {
  @extend .btn;
}
 
.gfield_required {
  color: $alert-danger-text;
}
 
.gform_wrapper ul.gfield_radio li, .gform_wrapper ul.gfield_checkbox li {
  @extend .form-check;
}
 
.gform_validation_container {
  display: none;
}
 
.gfield_error .ginput_container {
  margin-bottom: 10px;
}

This will apply the styles from Bootstrap classes to the proper elements inside of Gravity Forms and make everything look just as it should. You may need to tweak a bit here and there on individual elements but this tends to get things working pretty well.

Looking for the fully compiled, vanilla CSS version of this? I set up a gist for you to drop into your project.

Note: Updated on August 22, 2016. Thanks to Josh Cranwell for some much-needed additions!

That Time the Internet Broke

RE: The Plight of NPM, etc.

I won’t pretend to be an expert on NPM, package managers or open source. But last week, something really interesting happened. And it brought into view two issues that have been swirling around in the ether: the dependency tangle that is the Node / Javascript community and the problems that arise from private vs open source projects.

Here’s what happened. Azer Koçulu announced that he was removing all of his publicly available modules from the NPM registry after his module Kik was removed, against his wishes, by the NPM team. See, NPM is a private company, owned in part by Isaac Z. Schlueter. And when lawyers from the app Kik came knocking, Isaac was quick to comply over Azer’s head.

In Azer’s words:

This situation made me realize that NPM is someone’s private land where corporate is more powerful than the people, and I do open source because,Power To The People.

So Azer goes and removes his 273 modules from NPM, including some pretty global sounding ones like “map” and “attr” and, most importantly, “left-pad”. And just like that, a giant section of the Internet just flat out breaks. Why? Because thousands and thousands of developers had one of these libraries as a dependency for their app. Or maybe one of their dependencies had one of these dependencies. Or maybe one of their dependencies’ dependencies had one of these libraries as… well, you get the point. As The Register puts it:

Unfortunately, one of those dependencies was left-pad. The code is below. It pads out the lefthand-side of strings with zeroes or spaces. And thousands of projects including Node and Babel relied on it.

In the Javascript community, we’ve taken the concept of micro-packages to an unreal extreme, to the point where our careful web of dependencies can unravel at any moment. There are no standard libraries or robust toolkits, everything’s a tiny dependency bundled alongside a hundred others. So when one thing breaks, everything breaks. We like to think that we’ve created this neat, decoupled architecture but all we’ve proven is that things rely on external libraries that much more. And it’s way too easy for things to break.

I think David Haney probably had the best perspective on this whole problem:

On what possible plane of existence is this a better solution to past problems? How are hundreds of dependencies and 28,000 files for a blank project template anything but overly complicated and insane?

Or put simply:

Every package that you use adds yet another dependency to your project. Dependencies, by their very name, are things you need in order for your code to function. The more dependencies you take on, the more points of failure you have.

Honestly, Haney’s viewpoint on this whole thing is the most practical I’ve read so I’d recommend giving it a read.

And then there’s the whole issue of open source libraries being hosted and distributed on a closed-source, private package manager. Because  rather then take a second to see why this might be a problem, the NPM team simply reacted by removing the ability to unpublish packages altogether. Which does not sound very open-source friendly to me. Legally, it’s well within NPM’s rights to do what they did, and I actually think they made the right call with the situation they had, but it points to a bigger issue. There’s really no truly public place for open source. Without this, we rely on the wills and whims of individuals to manage the needs of entire communities.

From Dave Winer:

I worry about GitHub. It plays such a central role. But eventually the VCs are going to want an exit. Then what happens?… We need a framework, legal and social, for projects that are not “owned” but are just there.

This whole thing might seem ridiculous, and it is. But it might spark some interesting conversation. For now, it’s worth keeping an eye on. If you have some time to kill, there’s an interesting conversation about it over on Hacker News as well.