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
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/
There’s a lot of truly amazing insights about Biden in here, but this one seems to really drive it home for me. Biden is stuck in an idealistic past that wasn’t all that ideal to begin with. We can do better.
Categories
Reply to Tantek.com
In reply to http://tantek.com/2019/171/t1/happy-14th-microformats-org.
Finally converted my site (https://jayhoffmann.com/) to microformats in celebration! Next step, POSSE 🙂
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:
- Upload Image
- Edit the crop for these special sizes if they feel like
- 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.
So anyway, if you’re looking for a good post thumbnail crop editor, try out Manual Image Crop.
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!
Categories
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.
Categories
Chose Your Metric
I went to Wordcamp Lancaster this year. It was a great time. I gave a talk on Javascript and after the conference, I was perseverating about one of my favorite things: what the f%c Javascript framework should I use. Rami Abraham (who organized the crap of out of WC Lancaster by the way) was quick to point out that we had probably drunkenly discussed this very same topic on no less then seven different occasions. Like usual, Rami was right. Sometimes we do it on Twitter.
I think about this crap a lot and I’ve never really figured it out.
Stop me if you’ve heard this one. I’ve been working on this new project, trying to pull JavaScript and the WordPress API to pull together some pretty cool tools for writers and developers.
Awesome. Crack my knuckles and get started. I know things are going to be heavy on the client-side, but this is a learning opportunity and I want to dive into a solid framework to get me started.
Cool. Angular or Backbone or React or Ember or Vue or Mithril?
Ugh. Okay, forget it. Build process. That’s simple, right? Let’s see…Â Gulp or Grunt or Brunch or Webpack or Browserify?
Wait, module bundling? Should I use ES6 Modules? Or CommonJS? Or AMD?
Well if I’m using ES6, I’ll need to transpile for sure. Traceur or Babel?
Cool, I’ll just need a client-side router, and an http request library, and a solid data store, and I’m just going to stop because this is ridiculous.
I didn’t know where to start. So I did the dumbest thing I could possibly think of. I rewrote the same thing five times with different approaches and frameworks. I doubt very much that I’m the first person to do this. But I’m almost (almost) glad I did this, because I learned two pretty important things.
- Most frameworks do a pretty good job when you’re doing something simple
- And …
Trying to Pick? Choose Your Metric
How do you figure out what that metric is? For me it’s simple. I let the project point me in the right direction.
I’m working with WordPress, which means I won’t be rendering any JavaScript on the server. And these large file size libraries still put me off a bit. So I made my metric pretty simple. File size. So for me, some good options are things like Backbone, or Vue. Both keep things really lightweight purely in terms of initial download size.
Maybe you’re working on a team, so having strong conventions and solid documentation is important. That way any team member can just dive in. Ember’s probably a good choice here. Angular’s not far behind there.
Maybe you have a team that’s transitioning to the client side from a very functional approach to programming. That’s like, exactly what React is built for. It’s what Automattic did to help their PHP developers transition.
There are a ton of comparison posts out there, but at the end of the day all you’re going to do is agonize  over the decision. For me the answer was to find that one principle and let it guide all the decisions that you make. This has the added benefit of connecting up the various bits and pieces of your project very nicely, and will inform decisions you make as you’re building the project.
For me the realization was that you can’t be wrong. You can waste a ton of time. So find your metric. And stick to it.
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 it, and change it to the field key you had registered via PHP. Once that’s done just save the field group. For some reason, that works just fine.
Of course, another solution is to do a search and replace in the database. Just make sure you hit everything in the wp_postmeta table.
The main point is that if you run into a problem with Advanced Custom Fields transitioning from registering via PHP to using the admin panel, the problem with existing posts has to do with the field keys.
I’m an avid reader of Brain Pickings (check it out if you haven’t heard of it), and one thing caught my attention a few weeks ago. In the mid-1930’s a young writer by the name of Arnold Samuelson caught up with his hero, Ernest Hemingway. Rather then cast him away, Hemingway took him on as a sort of protege, and gave him some invaluable writing advice along the way. There was one thing that resonated with me in particular because I find myself in this trap all the time.
The most important thing IÂ’ve learned about writing is never write too much at a timeÂ… Never pump yourself dry. Leave a little for the next day. The main thing is to know when to stop. DonÂ’t wait till youÂ’ve written yourself out. When youÂ’re still going good and you come to an interesting place and you know whatÂ’s going to happen next, thatÂ’s the time to stop. Then leave it alone and donÂ’t think about it; let your subconscious mind do the work.
I mostly write code for a living, not prose. But this rule still applies. I can’t tell you how many times I’ve been coding away when I finally get myself to a good place. Everything’s perfect. The bug is patched, the feature is solid.
Then I go just a little bit further. And that’s when I blow it. I get frustrated and lost. My motivation goes into free-fall and I alternate between my code editor and Twitter every five seconds. And no it’s late. It’s dinner time, or my wife is calling me, or the office is closing.
So don’t be me. Take Hemingway’s advice. It doesn’t matter if you have a little extra time, find that place where you still have some juice left and just stop. If you really need to keep going, go over the code you just wrote and refactor a bit. Or look at the next step enough to get pumped about it, but don’t write any code. When you get up and walk away from your computer, the levers in your brain will keep moving, even when you sleep through the night.
The next morning, when youÂ’ve had a good sleep and youÂ’re feeling fresh, rewrite what you wrote the day before. When you come to the interesting place and you know what is going to happen next, go on from there and stop at another high point of interest. That way, when you get through, your stuff is full of interesting places and when you write a novel you never get stuck and you make it interesting as you go along. Every day go back to the beginning and rewrite the whole thing and when it gets too long, read at least two or three chapters before you start to write and at least once a week go back to the start. That way you make it one piece.
More sound advice. When you start up again fresh, instead of jumping straight into a problem, go back over the work you did the day previous. Take 10 or 15 minutes and tweak little things, just enough to get the ball rolling. When you start developing the next step, you’ll already be in a good place. And by going back over code you’ve written before, you can make sure to keep things fluid and connected.
I’ve started to do this (when possible) and it feels really code. All of this, of course, requires nice blocks of time devoted to your tasks, not distracted by email and social media and meetings. That can be tough, but it is well worth it. You might not write For Whom the Bell Tolls, but your code will be a lot better for it. Give it a go.