-
Notifications
You must be signed in to change notification settings - Fork 0
Getting Started With Prelude 6
We use prelude-wp as our start point for all of our WordPress projects.
These are the steps you should follow to install Prelude if you are not using our small site blueprint.
Follow the wizard in Local in setting up a new site.
Under the "Set Up WordPress" screen in the wizard, make sure that:
- WordPress username is factor1admin
- WordPress password is factor1dev (at site launch, this will be updated to a secure password)
- WordPress email is [email protected]
Navigate in Terminal to the themes
directory within the site you created in Step 1.
cd ...wp-content/themes
Install Prelude 6 and follow the wizard that appears in Terminal. Fill out the theme name, description, author, author url, and license (GPL-3.0) fields.
npx prelude-wp yourthemename
Once you've completed that wizard, navigate into the new theme directory.
cd yourthemename
From here, you'll need to create a couple files:
touch README.md
touch .env
In the new readme file, place the site name as an H1 (you'll complete the rest of the info once development is complete using our readme template).
In the .env
file, add the WP URL from Local to enable hot reloading functionality during development:
WP_URL="http://local-site-url.test/"
We use Ginger Grid on every project. In your theme directory, run the following command:
yarn add ginger-grid
Copy the contents of node_modules/ginger-grid/settings/_settings.scss
and paste them into assets/scss/settings/_ginger-settings.scss
.
In assets/scss/theme.scss
, paste the following lines after the // Variables
block:
// Ginger Grid
@import "settings/ginger-settings";
@import "./node_modules/ginger-grid/ginger";
Many of these are documented here.
Back in the theme directory, run the following series of commands to install git:
git init
git add .
git commit -m "Initial commit of theme files"
Then proceed to Github and follow the steps to set up a new repo there.
Important! We follow Github best practices to properly document our work and enable collaboration on each project. These include:
-
Never doing any work directly on the master or develop branches. Always make a new branch off of one of these and do work there (ex.
git checkout -b yourbranchname
) - The
master
branch is for the live (production) version of the site. Thedevelop
branch represents the staging site if there is one. If there's no staging site,develop
should be synced withmaster
. - When you are done with whatever branch you are working on and all work is approved, you may merge your branch into either
develop
and/ormaster
(depending on whether your work is moving to production, staging, or both)
Here's an example of merging a feature branch into develop:
git checkout develop
git pull
(Always always always pull. You never know if work has been committed in the meantime)
git merge --no-ff feature/slider
(Use the --no-ff
flag every time. This ensures that each commit is visible on the branch after a merge in case of issues later on)
git push
You'll find the list of plugins we use here. Make sure to install/update to the latest versions.
Visit http://prelude.factor1.org for more documentation.
Feel free to open an issue if you find mistakes, enhancements, or would like to see some new documentation.