Tag: development

Updating Bower with Grunt
The goal of automation is to make the annoying stuff I don’t want to have to remember to do easier to do. Bower is useful for updating things. Grunt is useful for running a series of commands. Using them together makes life easier.

In my little world, everything lives in a folder called ‘assets’ and its very simple.

Add a Package to Bower and call it in Grunt

First I have a .bowerrc file which very simply says this:
```
{
   "directory": "vendor"
}
```
That tells Bower where to install things. So when I run bower install jquery-backstretch --save in my asset folder, it saves backstretch to the vendor folder.

In my gruntfile.js, I have this to pull in my backstretch arguments and the main file into one file, uncompressed, a folder level up:
```
		concat: {
			// Combine all the JS into one
		    backstretch: {
		    		src: ['js/backstretch.args.js', 'vendor/jquery-backstretch/jquery.backstretch.min.js'],
				dest: '../js/backstretch.js',
		    },
		},
```
Just like magic.

Tell Grunt to Update Bower

But while Bower pulled in the packages, I don’t want to have to tell Bower ‘Hey, make sure everything’s up to date!’ every few days. I want to make sure I’m on the latest version of a branch most of the time, for security reasons at the very least. That means I have this in my bower.json file:
```
  "dependencies": {
    "bourbon": "~4.2.3",
    "neat": "~1.7.2",
    "jquery-backstretch": "~2.0.4"
  }
```
So if I run bower update I would get this:
```
bower jquery-backstretch#~2.0.4 cached git://github.com/srobbin/jquery-backstretch.git#2.0.4
bower jquery-backstretch#~2.0.4         validate 2.0.4 against git://github.com/srobbin/jquery-backstretch.git#~2.0.4
bower bourbon#~4.2.3                      cached git://github.com/thoughtbot/bourbon.git#4.2.3
bower bourbon#~4.2.3                    validate 4.2.3 against git://github.com/thoughtbot/bourbon.git#~4.2.3
bower neat#~1.7.2                         cached git://github.com/thoughtbot/neat.git#1.7.2
bower neat#~1.7.2                       validate 1.7.2 against git://github.com/thoughtbot/neat.git#~1.7.2
bower jquery#~1.9.1                       cached git://github.com/jquery/jquery.git#1.9.1
bower jquery#~1.9.1                     validate 1.9.1 against git://github.com/jquery/jquery.git#~1.9.1
bower neat#~1.7.2                        install neat#1.7.2
bower bourbon#~4.2.3                     install bourbon#4.2.3

neat#1.7.2 vendor/neat
└── bourbon#4.2.3
```
Cool. But who wants to run that every day?

Instead, I ran npm install grunt-bower-update --save-dev to install a new Grunt tool, Bower Update. With that code added to my gruntfile.js, every time I run my grunt update command, it first updates my libraries and then runs the processes.

There is a downside to this. I use git to keep track of my work and either track the vendor packages in my repo (which can make it a little large) or I can remember to install the packages. There are other ways around this, like using grunt-bower-task to set up things to install if not found, update if they are found. I went with including them in my repos, which makes the git pull a bit large (it added about 6000 files), but since I properly delete my assets folder when I deploy from git, it won’t impact the size of my server’s package.

Register a New Bower Package

Randomly, when I initially tried to install backstretch, I forgot it was named ‘jquery-backstretch’ and did this:
```
$ bower install backstretch --save
bower                        ENOTFOUND Package backstretch not found
```
Obviously the right fix is to use the right repo name (and bower has a great search tool to help me to that). But what if I did want to package it up as backstrech? Or if I wanted to add my own repo? Well I would have to register that package first. And that’s pretty easy:
```
bower register backstretch git://github.com/srobbin/jquery-backstretch.git
```
Your Tricks?

Do you have Bower tricks?
6 July, 2015
Bower To The Master

I recently mastered using Grunt to handle automation.

And then I was handed some Bower code by Carrie Dils. I’m up for a challenge, I muttered under my breath. I already have Node and NPM and Git, so this shouldn’t be too terrible.

Turns out I didn’t need to change a damn thing!

First off, Carrie and I are on the same wavelength, having named our files nearly the same and separated them the same. Second, I had been incredibly brilliant and put all of my code in separate files (my.css, my-config.php, etc etc). Third, I had documented everything that I had changed in all of my files in a my-readme.txt file.

But if I’m using Grunt, what am I going to get out of Bower?

Bower is a ‘front end’ package manager.

To install packages, I make a folder for my work and I go there in a command line, I type this:

$ bower install jquery

That would install bower into my folder. It’s dependency aware as well, so if I install Bourbon, it will include Neat. This is much the same as Grunt, which can install its plugins and dependencies, but where Grunt is for installing Node modules, Bower is for js and CSS and html as well.

Grunt is for running tasks. Bower is for managing components. They’re friends.

Bower lets me set up all the required components for my site (jquery for example). Grunt lets me compress, join, minify, and automate the deployment of those components.

I tell Bower to get the files and what versions they could be. I tell Grunt to combine all my mini-js files into one, combine them, compress them, and put them in another location. That means I tell Bower to bring in jquery, but it puts it in a development folder. Grunt takes that and copies it to the js folder.

Personally I take it a step further and, when I use Git to push my code, I tell it to delete the development folder off the server. I also do as Chase Adams does, and I don’t version control my dev packages. I may define jquery’s version, but I dont worry about capturing that in my repositories.

You don’t have to use Grunt. You could use Gulp. I had a sticker for Grunt on my laptop from a friend, so I tried it first and found I liked it.

Taking all this a step further, there are tools like Yeoman that will let you kickstart a project by saying ‘yo’ and telling it what kind of project you want to make. Yes, there’s a WordPress project called YeoPress.

The point of all this is that automation is the queen of development. Don’t do manually what you can safely, reliably, and responsibly automate. Like the Queen on the chessboard, strike out in all directions and control the board. Use the tools to repeat the hard work, to keep dependencies up to date, and to automate the annoying work.

15 June, 2015
Design for Multisite or DIE

I don’t mean you need to design all your code to have special Multisite features. I mean that if you’re not writing code to work on multisite, you’re probably doing a lot of things non-optimally and not fully WordPressy. When you write your code with Multisite in mind, you’re actually writing it with the basic tenants of WordPress itself. It forces you to think about how WordPress is used, how it might be used, and how you can be flexible and extendable.

Let’s throw out the idea of network options and activation for a moment and consider the ways we can write our code to make it work for Multisite and the world. The truth is that if you’re coding ‘for Multisite’ in many ways your coding for WordPress in the best way possible.

Calling Files

There’s a time and a place for ABSPATH but it’s as a last resort. There’s a time and a place for get_bloginfo('url') but it’s not to call .'/wp-admin/admin.php either. Did you know admin_url() will get the url to the admin area using the right protocol (http or https) for you? And it works for Multisite. Instead of hardcoding your paths or assuming everyone has WordPress installed in the root of their website (they don’t), use the functions and template calls WordPress has created.

Oh and stop supporting the old WordPress 2.x ways of determining folders. It’s 2015. We’re good.

Saving Files

Saving data to the disk means everyone can read it. Duh, right? Well, where do you save uploaded files? You use wp_upload_dir of course. That works on Multisite just fine. Instead, if you hardcode in /wp-content/uploads/myplugin/ then you’re saving things for everyone. If you’re not using the WordPress options to grab the upload directory, then your code won’t work on Multisite and everyone will be sad.

This extends to where you save your cache files. Did you know there’s a plugin that saves the cache to the plugin folder itself? Besides the fact that the cache didn’t have a way to flush and grew to 700megs over the year the person used it, that cache was for all the sites in the network. All. Saving the cache to a unique location (I suggest /wp-content/pluginname-cache/siteID) prevents cross contamination of cache.

Saving Options

If you write a plugin that, to save its data, it creates a new DB table and saves it there, that can be okay. But if your plugin on update then drops that table and recreates it… That was not pulled at random, by the way, I was reviewing a plugin that did that. Instead he should have been using the function update_option() to create (and update) the options. And yes, it knows.

But that’s an extreme, I admit. What isn’t an extreme is people creating their own tables. It happens a lot. And when they do, they often forget that we have $wpdb->prefix which means they force create wp_mypluginname instead of $wpdb->prefix . "mypluginname" … guess which one’s smart enough to know it’s on Multisite?

(If you want to make a network table use $wpdb->base_prefix and use update site option for network wide options, yes, we know the naming conventions are weird.)

Theme Customizer

Not everyone can edit theme files. Not everyone can make child themes. On a Multisite, the only person who can do that is the Super Admin. Site Admins have no access to edit files or upload themes. Worse, if you make a change to a theme, everyone who uses that theme gets the change. What happens when a site wants a special header and your theme doesn’t allow those to be edited via the customizer? The customizer is there for a reason. Use it. At the very least make things hookable to allow plugins to do simple things like change footers. Please. Please. That’s one of the things that themes get wrong constantly.

What Else?

What do you think would be improved if people ‘coded for Multisite’?

1 June, 2015
Coding My Own Dogfood

I say no to a lot of pull requests on code.

This is because I write plugins, not something massive and monolithic and used on a million websites. I’m a sole developer for my code, for the most part, and while pull requests are always welcome, the main reason I reject them is because I eat my own dogfood.

Back in March of 2015, I decided to start using CloudFlare because we, at DreamHost, parter with them, so I should, you know, use them. It’s the same reason I use PageSpeed so much. And WordPress. I use what I use because I need to use it to be good at it.

You cannot possibly be expected to write code for WordPress and support it if you don’t use it.

I say this over and over again when I’m training people on WordPress. If you want to get good at supporting and fixing WordPress, then you need to use it and fix it. A lot. Every day. You need to use it so you know where everything is and can recognize what it should and should not do. You need to fix it so you know how to make it go back to looking like it should.

If you’re writing code for WordPress, you need to do that too.

Here’s my bottom line. If I’m writing a plugin, it’s going to be because I need what it does. If I’m writing a plugin, it’s because I’m going to use it. If there’s a feature I disagree with, I won’t add it in. If it’s something I will never use, it’s not going in. If it’s code I cannot test, I will never, ever, add it.

That last one gets people mad at me a lot.

The reality is that if I add in a feature for you and it doesn’t work, I can’t fix it because I don’t have the access needed. I cannot reproduce the error. If I can’t do that, how can I possibly fix it? I’ll have to work with you, via posts and emails, if you can’t fix it yourself.

Pull requests are a wonderful thing, but if you’re making a pull for a new feature that’s something I can’t validate and test, then you’re also taking on the responsibility I did for the community. You’re promising to help me test it, develop it, future proof it. You’re promising to be there when I want to release a new version for everyone else. You’re promising to help support it and help others debug it.

Are you ready for that?

22 May, 2015
Underscores (A Plugin We Need)
Look. I still hate Your frameworks.

I really do. They’re a decent idea with a terrible reality. The concept of ‘a plugin to build other plugins’ is nothing at all like a Parent Theme. A plugin that builds other plugins is synonymous with a theme framework or, perhaps you’ll understand this better, a starter theme.

Have you met _s?

_s (aka underscores) is a starter theme. Themes are built from it. In and of itself, it’s not a theme you’d see on WordPress.org because in and of itself, it’s useless. It’s not a parent theme, it’s not even a ready to use ‘drop this theme in and you have a site’ sort of thing. No, in fact if you installed it, it would look terrible.

Because the point is not to use it as a theme, but to use it to build your theme. No one in their right mind uses Underscores as a parent theme. No one uses it as a drop-in to their themes. It’s a, literal, framework where you say “This is my Theme Name, this is my slug.” And then it drops out the code for you to start plugging into.

What do the existing framework plugins do?

The problem isn’t what they do it’s how they do it. They’re not frameworks. They’re libraries. A library is like the AWS SDK library. It’s a vendor based addition to your code that enables it to do ‘a thing’ but, in and of itself, doesn’t do anything. A library is a great tool and lets you include code that you’re going to use but don’t want to reinvent the wheel. I love them. Another example would be that Font Awesome is a library.

But we don’t allow libraries, themselves, in the repo. That means if you write a Font Awesome plugin, it has to actually do something besides just include Font Awesome.

And the point here is that a plugin, like a theme, has to be usable. It has to stand up on it’s own and do something.

Is a library perfect?

Once you take your framework plugin out of the repo, how do you handle upgrades?

Obviously you can run your own upgrader (which we’d encourage) but if the plugin is folded into another plugin, you’re not able to just upgrade YOUR portion. So you have to wait (and trust) the plugin dev will update their plugin and include your latest version.

Mind you, this is an existing problem with plugins and libraries and, in a way, is related to why we don’t allow you to use your own copy of jquery. Conflicts! Yay!

How does _s handle updates?

This is something Konstantin’s thought about before. Funny thing, Underscores is versionless and it doesn’t update often.
Here is a list of reasons why you should not update your _s-based theme with our changes to _s:
- Most likely your theme code will have evolved to a degree where merging _s changes would lead to conflicts. They also won’t be applied to anything you created on top of it.
- We are in the unique situation to not having to worry about backwards compatibility when we commit changes. And we don’t!
- Once you release your theme, you’ve probably fixed all the things in _s that needed fixing for your case. Just because we push an update to _s, it does not necessarily mean it applies to your theme.
Basically there should be no updates to your framework.

And that terrifies a lot of people. Because the extant framework plugins update a lot. In fact, some of them want to be in the .org repository specifically because they update a lot.

They shouldn’t. And that’s why I think they’re doing it wrong.

Be a Starter Plugin

Stop trying to be a framework. They don’t work, they’re not sustainable, and they’re problematic.

Be a starter plugin. Be a plugin that I can download. Use that underscores form so I can download everything set up for ‘me’ right away, no search and replace needed. Have a template settings page that creates basic options, just like a theme. Except that plugins are not themes. And there’s the real issue. A theme is ‘easier’ (and this is subjective) because it only has one interface: The customizer.

Plugins can add a menu section, they can add an option to an existing area like discussion, they can be silent and have no information and just work. Plugins can do anything and in any way. There’s not a ‘standard’ because there really can’t be.

Is There An Answer?

I think the starter plugin would work, if it came with options. It would more likely be a workflow. Where do you want your menu? Will you connect to an API? Will you need settings?

If someone can boil that down, it would all be better.
18 May, 2015
If You Call Yourself a Developer You Should …

Sometimes people scare me. Mostly it’s people who start a conversation with some variant of “I’ve been a developer for X years and I’ve never experienced a conversation like this…”

It tends to come up when I kick someone’s code back and remark “Remove your own jQuery, delete the demo folders, and your domain name is a problem so change X to Y.”

They get upset because I’ve not spelled out, specifically, to the letter, what’s wrong and where. I’ve had those conversations with everyone from a mom-and-pop shop coder to Microsoft and it really only bothers me when people are running dev companies and ask things like “How do I find that?” or “Where is that code?”

So here are my rules of what a Developer should know:

Know Logic

You should understand logic. Not Spock Logic. Math Logic. And Computer Logic. Don’t worry. I don’t think you need to be a math rock star to write code. I think that if you understand basic algebra, which you may be surprised to know you do, then you’re okay. But you have to understand the most basic of logic gates:

Can you look at that and understand the differences? Great. Write some code. Understanding the elementary building blocks of circuits, the A or B, the Yes or No, is the crux of programing. If you can’t logic that out, you should stop and read up on it. Most self-taught programmers have intuited that, but at some point they had a class in Boolean Algebra and learned this. Maybe it wasn’t called that, but most of us had that class in at least High School. You’ll need it.

Know Grep

You need to know how to search all the files in your code. If you’re on a linux flavor, grep or ack are your best friends. So when someone says “I see you’re calling domain.com in your code, why?” you know how to find that, even if they don’t give you a line.

Know What You’ve Got

You need to know all the packages added to your code. Did you add a library or a sub-module? This is your responsibility to know what they are. That way, when someone tells you to ‘remove the X module’ you’re not surprised. If it’s in your code, you should know what it is.

Know What You Need

You need to know what those packages are adding to your site. Did you download a whole jQuery library with all the demo files and a version of jQuery and the help docs? Do you really need all that? Dollars to donuts, you don’t. Don’t let your code be cluttered by what you don’t need. It’s more work to maintain it, and if there’s a security hole in it, you still have to be aware of it. Save yourself time, effort, and a hack. Leave out what you don’t need.

Know What To Use

You need to know how to edit the various filetypes. Personally I don’t care what you use. I like Coda. My friends like Sublime. I don’t care. Just make sure you use something that works for you and helps you work better. While you can do all your programing in Notepad, I wouldn’t suggest it. You will need tools to help you keep track of the complex world you’re building. Sometimes you’ll have to use a specialized tool.

Know How Your Tools Work

Did you know Github makes a downloadable zip of your code? Did you know that zip doesn’t include submodules? Did you know Github forks aren’t searchable? You should. I have a few awesome tools, like Coda, which lets me search my repositories and find code. I use BBEdit to search zips. I use a new tool to compare folders when I don’t have version control (for whatever reason). But I know how they all work.

What Else?

What do you think is imperative for someone who calls themself a professional developer to know?

13 May, 2015