git clone git@github.com:YOUR-USERNAME/YOUR-FORKED-REPO.git
cd into/cloned/fork-repo
git remote add upstream git://github.com/ORIGINAL-DEV-USERNAME/REPO-YOU-FORKED-FROM.git
git fetch upstream
/* | |
Make the Facebook Like box responsive (fluid width) | |
https://developers.facebook.com/docs/reference/plugins/like-box/ | |
*/ | |
/* This element holds injected scripts inside iframes that in some cases may stretch layouts. So, we're just hiding it. */ | |
#fb-root { | |
display: none; | |
} |
<?php | |
/* | |
Plugin Name: WooCommerce Attribute Links | |
Description: Display product attribute archive links on product page, right below the add to cart button. | |
Version: 1.0 | |
Author: Coen Jacobs | |
Author URI: http://coenjacobs.me | |
*/ |
I have always struggled with getting all the various share buttons from Facebook, Twitter, Google Plus, Pinterest, etc to align correctly and to not look like a tacky explosion of buttons. Seeing a number of sites rolling their own share buttons with counts, for example The Next Web I decided to look into the various APIs on how to simply return the share count.
If you want to roll up all of these into a single jQuery plugin check out Sharrre
Many of these API calls and methods are undocumented, so anticipate that they will change in the future. Also, if you are planning on rolling these out across a site I would recommend creating a simple endpoint that periodically caches results from all of the APIs so that you are not overloading the services will requests.
⇐ back to the gist-blog at jrw.fi
Or, 16 cool things you may not have known your stylesheets could do. I'd rather have kept it to a nice round number like 10, but they just kept coming. Sorry.
I've been using SCSS/SASS for most of my styling work since 2009, and I'm a huge fan of Compass (by the great @chriseppstein). It really helped many of us through the darkest cross-browser crap. Even though browsers are increasingly playing nice with CSS, another problem has become very topical: managing the complexity in stylesheets as our in-browser apps get larger and larger. SCSS is an indispensable tool for dealing with this.
This isn't an introduction to the language by a long shot; many things probably won't make sense unless you have some SCSS under your belt already. That said, if you're not yet comfy with the basics, check out the aweso
// Global Vars | |
$basefontsize: 16 !default; | |
// Mixins | |
// input pixel value unitless: 8 vs 8px | |
// ex. @include rem(padding, 8 12 16 24) | |
@mixin rem($property, $px: $basefontsize) { |
Update 03-03-2015
I've moved over to a new MacBookPro running 10.10.2. I think I'm going to leave POW off this machine. I've been trying to use more Vagrant VMs in general, but the Localhost is so fast for just getting something in the browser, especially when testing things out on the front end in the browser. One thing I'm noticing about the 2nd approach is that the build with a vhost works great, but just getting the .git setup was a little tricky. I had to make the main directory, the build directory and git init
in each. Then, I added the remotes from the working (development) repository for the source and the staging server repo for the build. Looks like I might install Passenger on this new machine so that I can use a vhost for the source files. Otherwise I need to use the http://0.0.0.0:4567/
or http://localhost:4567/
which isn't a bad thing vs installing Passenger?
Udpate 03-03-2015
Wow, just installed Phusion Passenger in about 15min using the g
#! /usr/bin/env bash | |
### | |
# | |
# install_mysql.sh | |
# | |
# This script assumes your Vagrantfile has been configured to map the root of | |
# your application to /vagrant and that your web root is the "public" folder | |
# (Laravel standard). Standard and error output is sent to | |
# /vagrant/vm_build.log during provisioning. |