ryelle codes

Note from 11/2019 — this approach should still work, but the recommended WordCamp.org dev environment has shifted to use docker instead of the full VVV + meta environment setup. There are instructions in the .docker folder in the repo. Join us in #meta-wordcamp on slack if you have questions 🙂

An important aspect of running a WordCamp is having a good website. That’s where all your attendees, speakers, sponsors, and volunteers will interact with you before and at the event. We’re lucky to have a number of tools built into the WordCamp environment, but the “locked-down” nature of the sites can make it hard to customize.

I’ve worked on the WordCamp Boston sites for the last 4 years: 2016, 2015, 2014, 2013. Each year, more tools are released, and I learn more about the WC environment. This year, everything came together to make it much easier to do development locally, and set up github so that anyone in the community could help out.

At the end of this walkthrough, you should have a local copy of WordCamp.org, a site for your WordCamp, and a github repo for your custom CSS. This will work best if you already have a live WordCamp.org site for your camp.

These are the steps you’ll follow. Feel free to jump to a section if you already have part of this set up.

• Step 1: Install the meta environment
• Step 2: Create your site
• Step 3: Set up your theme
• Step 4: Set up a Github repo
• Step 5: Deploy your CSS
• Step 6: Updating your site

Step 1: Install the meta environment

Update, June 2020: Follow the directions in the WordCamp.org repo to use Docker, it’s much easier this way. This will only install the WordCamp environment.

You can now skip to step 2, the rest of this step is only saved for transparency.

---

This is a meant to be installed into a Varying Vagrant Vagrants www folder, so make sure you have VVV installed first.

The WordPress meta environment contains all the WordPress.org-related sites:

• api.wordpress.org
• buddypressorg.dev
• jobs.wordpressnet.dev
• translate.wordpressorg.dev
• wordcamp.dev
• wordpressorg.dev
• wordpresstv.dev

But if you only care about WordCamp.org, this can seem like overkill. You can pull out just the wordcamp site by creating a directory www/wordcamp.dev/provision with the content from the meta environment github. You’ll also need helper-functions.sh in www/.

Now when you vagrant up, the wordcamp site will be created with central.wordcamp.dev, 2014.new-site.wordcamp.dev, 2014.content.wordcamp.dev, 2014.misc.wordcamp.dev, and 2014.seattle.wordcamp.dev. Seattle is set up as a clone of the 2014 seattle site, while misc and new-site are blank sites.

Step 2: Create your site

You can use one of the created sites, or create a site by adding a new WordCamp in central.wordcamp.dev/wp-admin.

Step 3: Set up your theme

You’ll use one of the existing themes for your WordCamp site, but you can customize it using widgets and custom CSS. For local development, so that I can use my own text editor, I ended up creating a child theme of the “CampSite 2017”. This one is the most flexible, with plenty of widget areas to allow for unique layouts.

You can also customize any of the core default themes using this process.

For Boston & WCUS, I set up a sass folder so I could use multiple smaller files, and a style.scss which combined them all. Then with Gulp, I combined them all down into the theme’s style.css. You can check this setup out on github.

If you want to add-on to the parent theme’s styles, make sure you’re enqueuing or importing them in your child theme. I’m using a really simple function in functions.php.

Now that you have a theme, you can go in and activate it (don’t forget to enable it for your site first).

Step 4: Set up a Github repo

Hopefully I don’t have to say much here. You can put your theme on github, and let others follow these steps to also work on styling your WordCamp site. Community members and fellow organizers can create issues, PRs, etc for the website.

Step 5: Deploy your CSS

WordCamps have a tool called “Remote CSS”, which lets you set a URL for CSS to be imported into the WordCamp site. You can read more about it on the make/community site. When you save the URL, the WordCamp server downloads the CSS and processes it for security reasons – which means there are some things it strips out (most notably, browser prefixes for flexbox, but also other @import statements).

You can use the URL to the CSS on Github as your Remote URL. It’ll look something like this:

https://api.github.com/repos/bostonwp/wordcamp-2016/contents/style.css

For this reason, you’ll want to commit the compiled CSS into the repo, even if you’re using Sass or LESS.

Remote CSS also lets you pick whether to “add-on” or “replace” the existing theme’s CSS, so pick whichever applies.

But what about custom fonts?

The Remote CSS tool strips @import, and you can’t add script tags for Typekit, how can you get custom fonts loaded? By using the WordCamp admin “Fonts” page. You can add a google fonts URL, a typekit ID, font awesome, or dashicons to your theme. You’ll need to set this up twice, on your local and live sites.

And keeping content synced?

There are a few content hiccups, some expected, some not. You’ll need to set up widgets on both your local site and the live site. You can use import and export to keep your page content synced — for example, when you select your speakers & sessions, you can export those to your local site to style the session & speaker lists, and the schedule.

I tended to go a little nuclear with WP-CLI when syncing, and totally emptying the site before entirely re-importing:

wp site empty --yes
wp import <file> --authors=skip

I did have public_html/wp-cli.yml set up to help:

path: wordpress
url: http://boston.wordcamp.dev
user: admin

The other issue I ran into had to do with features that are only enabled for newer WordCamps, and the switch to enable these features is based on the site ID being higher than 463 (or 699)… and since the meta environment is much smaller, your local site likely falls under that, while the live site is higher. This leads to some markup differences, unless you whitelist your site.

You can see I whitelisted the site with ID 47 in functions.php. Now I have things like the speaker name on the session descriptions, among other features – which existed on the live site, but not locally.

Step 6: Updating your site

Remote CSS can also be set up to listen for changes in your repo. There are instructions for adding a webhook to your Github repo. Check out the contextual help on your WordCamp site for instructions. All of this can be found at:

https://[YEAR].[CITY].wordcamp.org/wp-admin/themes.php?page=remote-css

If you use Github, and have set up the webhook correctly, you should be able to push a CSS change to your github repo and have it automatically deployed to the WordCamp site.

You’re done!

Now you have a local copy of your WordCamp site! Maybe we’ll see even more creative WordCamp sites now 🙂