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 š
[…] Local Development for WordCamp Websites […]
This was awesome. Trying to piece together items in other places was a pain. Thanks