Editing WordCamp CSS Locally with Git

One of the Improving WordCamp.org projects is to let organizers develop their CSS locally, and then commit it to a version control system like Git, and have it automatically updated on their WordCamp.org site. This is the project that I think will make the most impact for organizing teams with experienced developers.

The benefits are that:

  • You avoid all of the pain points of editing CSS in a browser.
  • You can use whatever IDE and other tools that you normally use.
  • You get all the benefits of a version control system, like easier/safer collaboration, history, and a structured approach.

So, I’d like to discuss the best way to implement a system like that.

Implementing a solution

After thinking about it for awhile, this is the best approach I’ve come up with:

(Note: This process has been updated since it was originally published, to incorporate feedback from the comments.)

  1. Add a new wp-admin screen under the Appearance menu, called something like “Remote CSS”. It will have a field where you can enter the URL for a CSS file, and a button to pull CSS from that repository and enqueue it locally. The CSS file can be in a source control repository like Git, but it doesn’t have to be.
  2. The CSS file can be named anything, and it can be built from supporting SASS/LESS/etc files, but only the CSS file will be used by WordCamp.org; everything else will be ignored.
  3. The contents of CSS file will be passed through Jetpack’s CSS sanitization functions, and if there’s anything left, the safe CSS will be cached. If there are any errors while fetching the file, the process will abort to avoid overriding the known-good version that’s already stored on WordCamp.org.
  4. When front-end pages are loaded, the cached CSS will be enqueued as a extra stylesheet, similar to how Jetpack’s Custom CSS is enqueued.
  5. To automate updates, there will also be an endpoint listening for webhook notifications of pushes to source control repositories. If the files changed in the pushed commits include the CSS file, the plugin will automatically fetch the latest version, sanitize it, and cache it. Updates will be limited to once every 3 minutes, to prevent abuse. Rate-limited notifications should be queued and acted on once the limit has expired.
  6. If the fieldon the Remote CSS screen for the CSS file is empty, we’ll display step-by-step instructions for setting up the CSS file, webhook, and a local WordCamp.org sandbox. If the file is hosted on GitHub, we’ll also recommend enabling two factor authentication, to mitigate the risk of a compromised account leading to CSS defacement or other malicious changes.
  7. A new meta box could be added to the Appearance > Custom CSS page to advertise the option of using a remote repository.

Does anybody see any problems with that approach, have a different idea, or have any other feedback?


#git, #improving-wordcamp-org, #jetpack-css-editor, #official-websites, #wordcamp-org