stephen.news

hypertext, words and more

Composer

  • Danny Elfman is a musical genius. The man really needs no introduction. But, for those who are unaware, a small sampling of his talents includes: The Simpsons, Nightmare Before Christmas, several Tim Burton films, Mission Impossible, Spider-Man, MIB, hundreds of collaborators, and that’s just abridged resumé. Batman (1989) was a groundbreaking movie at the time, and the score is iconic to say the least.

    I saved an excerpt from his interview with GQ on the Batman score below because it’s simply amazing. Warner Bros. Studios wanted Elfman to collaborate with Prince to make a score for Batman. I don’t hate it, but it would have changed the movie in unimaginable ways I can’t even fathom:

    I’ve never done anything harder than Batman because first off, I had to prove myself. You know, it’s like, okay, he’s the quirky comedy guy, and here I am doing like this Batman movie. Understandably, I think they were like, “uh, we need somebody who knows how to do this kind of music.” But, nobody knew what kind of music it was. There really was no superhero music. There was just Superman. And, we said we know we don’t want it to be Superman — John Williams.

    And, then there was an element with the producer in the studio of wanting it to be a pop score. There was definitely this moment of like, “Danny, we want you to collaborate with Prince and co-write the score.” And I go, I can’t do that. People go, “you really said that?” I love Prince, but not for that score. I already knew what the score was, and I knew that if I collaborated, he’d be writing tunes, and I’d be orchestrating his tunes, and I would be essentially a glorified arranger rather than a composer, you know. Because he was world famous, and I was still nothing.

    I had to walk away. I was so depressed. I felt like I just blew up my own career. And then a month later I got the call saying, Danny, you’re back on. It’s like this gamble paid off. But, it was a miserable period of time. On the other hand, I already heard the music in my head. I knew what it was, and I was determined that that was gonna be the score. The producer was so hard on me, John Peters, and then [they’re finally] he’s in — I think it’s the third presentation. And, I didn’t know how to do presentations.

    I was playing this weird music stuff that was all like inspired, you know, crazy. And then Tim says, play the March, “play the March, play the march!”
    [That’s] what he called the titles. I go, “oh yeah, I got this piece here.” And of course, now I know, you lead with your headline, obviously. I didn’t really know, or understand that back then. And I put this piece of music on, and John starts conducting in his chair. And then at a certain point he stands up,
    and he’s going like this. [Danny waving his arms like a conductor] Tim looks at me and he’s like [Danny laughing], “yeah, we got it.”

  • Want to checkout the latest version of WordPress? Or Gutenberg? Just swap your WordPress version in your composer file with the dev-master. Caveat: it requires the wordpress-core dev-master. Could prove useful for testing.

    ...shortened for brevity...
    
    "johnpbloch/wordpress-core": "dev-master",
    "johnpbloch/wordpress": "dev-master",
    
    ...
    
  • We’re going to setup a remote server (say hosted on DigitalOcean), with Trellis’ automated deployments. It’s magical. Oddly enough, as of 2018, this guide is still pretty much up date and relatively unchanged.

    We started by getting our local environment setup but now we need to get our production environment setup so we can get deploys going from our local machine. With Trellis, provisioning and deploying occurs from the trellis directory.

    Remember our structure?

    example.com/      # → Root folder for your project
    ├── trellis/      # → You'ver clone of Trellis
    └── site/         # → A Bedrock-based WordPress site
        └── web/
            ├── app/  # → WordPress content directory (themes, plugins, etc.)
            └── wp/   # → WordPress core (don't touch!)
    

    1. Copy group_vars

    Copy your wordpress_sites from your working development site in group_vars/development/wordpress_sites.yml to the production environment group_vars/production/wordpress_sites.yml.

    Modify your site and add the necessary settings for remote servers:

    • repo – URL of the Git repo of your Bedrock project (required)
    • repo_subtree_path – relative path to your Bedrock/WP directory in your repo (above) if its not the root (like site/ in roots-example-project)
    • branch – the branch name, tag name, or commit SHA1 you want to deploy (default: master)
    • env – environment variables (very important)
      • auth_key – Generate (required in vault.yml)
      • secure_auth_key – Generate (required in vault.yml)
      • logged_in_key – Generate (required in vault.yml)
      • nonce_key – Generate (required in vault.yml)
      • auth_salt – Generate (required in vault.yml)
      • secure_auth_salt – Generate (required in vault.yml)
      • logged_in_salt – Generate (required in vault.yml)
      • nonce_salt – Generate (required in vault.yml)

    You’ve’ll want to make sure that you change all instances of example.local (in your production vars) and switch it to example.com Otherwise you may get some errors.

    2. Setup Hosts and Users

    Create a Digitalocean droplet configured for Ubuntu 16.04.1 in whatever size you may need.

    screen-shot-2016-10-09-at-4-55-18-pm

    Once you get your droplet setup, you’ll need to SSH into the server to change the default password DigitalOcean emails you.

    Next, add your server IP (from the droplet) to your hosts/<environment>. Specify public SSH keys for users in group_vars/all/users.yml so Trellis can access your droplet. See the Trellis’ SSH Keys docs for more information.

    3. Provision

    Run ansible-playbook server.yml -e env=<environment>. and Hopefully you get a green light and no errors. If you do get errors, troubleshoot and try again. Trellis has verbose warnings and errors so they don’t leave you high and dry.

    4. Deploying

    To deploy, ensure that your site folder is in a public repository on Github.

    Next, run ssh-add -K, this will add you SSH key to your shh-agent (if you’ve created one, also it’s good practice to add your keys to your Github account). Then, from the Trellis directory, run ./bin/deploy.sh production example.com and watch as your terminal deploys your most recent commit.

    Previous: The WordPress Roots Stack
  • Okay, so it’s been a while since last time I wrote about Roots (shoutout to Rob for pointing it out). The last time I wrote about the Roots Stack, things were more or less the same. But I felt compelled to write this guide ever since Sage got a version bump.

    Secondly, no one enjoys spending precious hours configuring their local setup using a MAMP GUI or fucking up your machine’s hosts file or deliberating on how to fix the dreaded error establishing a database connection. What I love most about Roots is the priority on convention over configuration. 

    It’s literally a playbook taken from Rails. The net gain of this philosophy is twofold:

    1. Lowered barrier to entry for beginners
    2. Productivity bonus, spend more time hacking and less time crying

    The Roots framework has huge benefits for beginners, and even bigger returns for WordPress veterans. Mainly because you’ll no longer have to FTP your deployments like a goddamn barbarian. But I’ll go into more detail on remote server setup in my next post.

    Before I get side-tracked, let’s just dive right in shall we?

    Requirements

    Let’s talk about requirements and assumptions. I’m assuming you’re using Sublime Text 3 (all other versions make sure you have this enabled) and you understand how to use your terminal. Follow the links below and install the following software.

    Installation

    Below is what we want our project too roughly look like:

    example.com/      # → Root folder for the project
    ├── trellis/      # → You'ver clone of Trellis
    └── site/         # → A Bedrock-based WordPress site (cloned as well)
        └── web/
            ├── app/  # → WordPress content directory (themes, plugins, etc.)
            └── wp/   # → WordPress core (don't touch!)

    Create a Sites folder if you haven’t already. I typically put all of my web projects in a Sites folder in my home directory on my Mac. To get started, we’re going to make a directory called example.com — you can name yours whatever project name you’d like:

    cd ~/Sites && mkdir example.com && cd example.com

    You should be inside the example.com directory at this point. Next we’re going to clone Trellis:

    git clone --depth=1 git@github.com:roots/trellis.git && rm -rf trellis/.git
    

    Then we’re going to clone Bedrock (which contains WP Core and our web app, etc.):

    git clone --depth=1 git@github.com:roots/bedrock.git site && rm -rf site/.git
    

    At this point, our example.com directory should look like this:

    example.com/      # → Root folder for the project
    ├── trellis/      # → You'ver clone of Trellis
    └── site/         # → A Bedrock-based WordPress site (cloned as well)
    

    You’ve’re doing great!

    Trellis vars

    Now let’s get into something a bit more challenging. We’re going into the Trellis directory and need to edit some variables to bring this local WordPress installation to life. I’m assuming you have Sublime Text 3 installed and you’re still in the root of example.com

    Edit the wordpress_sites.yml file first:

    subl trellis/group_vars/development/wordpress_sites.yml
    

    Then just make sure it looks like this. Replace example.com with the name of the project you have chosen. This is pretty important at this point, as we start getting into the nitty-gritty.

    # Make sure your file looks like this
    wordpress_sites:
      example.com:
        site_hosts:
          - canonical: example.test
            redirects:
              - www.example.test
        local_path: ../site # path targeting local Bedrock site directory (relative to Ansible root)
        admin_email: admin@example.test
        multisite:
          enabled: false
        ssl:
          enabled: false
          provider: self-signed
        cache:
          enabled: false
    

    Now go ahead and edit the vault.yml file as well:

    subl trellis/group_vars/development/vault.yml
    
    # Make sure the site name (`example.com`) must match up with the site name
    # in the file we previously edited: `group_vars/development/wordpress_sites.yml`
    # By default Trellis will provision a user `admin` too, below you can set a different
    # password if you'd like
    vault_wordpress_sites:
      example.com:
        admin_password: admin
        env:
          db_password: example_dbpassword

    Don’t worry about the other .yml files in the development folder for now.

    Vagrant

    Vagrant is our savior. It sits between us and the VirtualBox, and does most of the talking. To get our machine running our new local setup we configured (in the wordpress_sites.yml and vault.yml files), we have to go down into our trellis directory and get vagrant running:

    cd trellis && vagrant up
    

    By now you should see this a few commands trickling in. At some point vagrant will ask for your sudo password because it needs root permissions.

    Enter your password and vagrant will begin installing, provisioning and start running tasks your virtual-machine.

    At this point, take a break and chill. The total installation/provision time varies from machine to machine, but it takes around 10-15 minutes on a mid-2015 13″ MacBook Pro. Once the provisioner is done (provided that no errors stopped the installation), you can open your browser and navigate to example.test and you should see this:

    Getting started with theme development with Sage

    Now that we have a local development environment setup and running, we can move onto creating our first theme! The Roots team put together an awesome starter-theme to speed up development.

    Remember our project structure? We’re going to cd our way into the themes directory:

    example.com/      # → Root folder for the project
    ├── trellis/      # → Trellis
    └── site/         # → A Bedrock-based WordPress site
        └── web/
            ├── app/  # → WordPress content directory (themes, plugins, etc.)
            |   ├── mu-plugins/  # Must-use plugins live here
            |   ├── plugins/     # Plugins live here, managed by composer.json in the `site` folder
            |   ├── themes/      # We're going to create our theme HERE.
            |   └── uploads/     # WordPress will put uploads here (I wouldn't mess with these)
            |
            └── wp/   # → WordPress core (don't touch! Like ever!)
    

    Once we’re in the themes directory, we’re going to run a composer command:

    composer create-project roots/sage example-theme 8.5.3

    Basically, the previous command says:

    1. create a composer project with the the roots/sage package
    2. name the theme, “example-theme”
    3. choose the 8.5.3 version of the roots/sage package

    As of October 17, 2017 the LTS Sage version is at 8.5.3 which is why I chose that version. You should see composer downloading the packages (be patient, sometimes composer can be slow)

    Sage requires Node.js to function. Make sure you are up-to-date.

    npm install -g npm@latest

    We’re going to use Gulp to build assets (styles, scripts, etc) and Bower will handle any front-end packages such as Bootstrap or Flickity. To get started, cd inside our new theme example-theme. We’re going to install Gulp and Bower globally (if you haven’t already)

    npm install -g gulp bower

    Now, were’ going to install all the dependencies listed in the package.json

    npm install && bower install

    Next, let’s open our manifest.json in Sublime Text and configure BrowserSync to proxy our dev URL

    subl assets/manifest.json

    Make sure the devURL reflects the canonical hostname we wrote in wordpress_sites.yml earlier since our vagrant machine will be listening for traffic at that URL.

    ...
      "config": {
        "devUrl": "http://example.test"
      }
    ...

    At this point, we can go to example.test/wp-admin, and login. From the dashboard, choose Appearance > Themes. Pick your Sage Theme and Visit Site. Everything will look broken now, as no styles exist 🙁

    But don’t fret! Next, we go back to the terminal (make sure you’re still in the new theme directory), and run gulp watch. A new tab should open on your browser. That’s BrowserSync loading style changes in real-time (no more ⌘R in Chrome). Save any of the SCSS files in the assets/styles directory and your webpage should reload with the changes. Also watch your terminal 👀

    Gulp literally watches all PHP, SCSS and JS files changes. And BrowserSync will reload your browser window. Pretty nifty. Assuming you didn’t get any errors, your homepage should load with basic styles thanks to Normalizer and Bootstrap.

    From here on out, the world is your oyster!

    Sage doesn’t give you everything you need for WordPress development but it’s speedy, it’s git-friendly, and it’s modern. I’m not kidding when I say this… the Roots Stack is literally my favorite way to interface with WordPress. Any other way just feels primitive and old.

    It gets even better with deployments and remote provisioning which I will cover in my next post. 

    Further Reading:

    Next: Remote Server Setup with Trellis
  • Wouldn’t it be neat to embed your Unsplash photography on your WordPress site?  Unfortunately, there’s no WordPress plugin available. If you’re not familiar, Unsplash is a huge library of photographs for commercial and noncommercial purposes. It’s an awesome resource for designers, prototypers, and developers alike. 

    If you have a profile with Unsplash, you should check out their API docs. The devs provide some wrappers too. There’s a PHP, Ruby and JS wrapper. Which all-in-all, are pretty fucking dope.

    So yeah, I figured it would be cool to add a showcase of my Unsplash photos on my website. Upon closer inspection of the Composer wrapper, it looked like it was overkill for my use. But if you’re gonna make a WordPress plugin using Unsplash, you’ll want to use it.

    So I began here — first I made a quick blueprint on how I wanted this to go down:

    Just a simple page, and a two column grid layout of my photos.

    Next, I took a looked through the Unsplash API docs again. Created an application, and received my Application ID. Very important step. The docs even had an example for listing a user’s photos. Hell yeah 😎

    From Unsplash’s Documention

    Seems easy yeah? Next, I went to check out what kind of HTTP Response I get from the API with hurl.it and everything is looking hunky-dory so far.

    So at this point I realized a few things:

    1. I need to make a simple HTTP request
    2. Decode the JSON
    3. Loop through the array and echo the goodies

    I decided on making a simple snippet below:

    If you leave line 19 uncommented, you can see the full array and figure out what you want to use from the HTTP request. You can copy/paste that snippet in any template or PHP file and it should work. NOTE: make sure to replace my username and swap YOUR_APPLICATION_ID for your actual App ID from Unsplash.

    After a few layers of paint my Photography page now looks like this:

    It’s quick and dirty, but at least I won’t have to upload my Unsplash photos to my website manually anymore. It’s all programmatic baby! I’m really happy how this turned out. I tried to make this as simple as possible and under 15 lines of code I think this rocks. But I hope someone else finds this useful!

    Let me know how if you have any feedback, improvement or philosophy on this implementation in the comments below. 🙂