wprig / wprig

A progressive theme development rig for WordPress.

WP Rig: WordPress Theme Boilerplate

Your Performance-Focused Development Rig

A progressive theme development rig for WordPress, WP Rig is built to promote the latest best practices for progressive web content and optimization. Creating a theme from WP Rig means adopting this approach and the core principles it is built on:

• Accessibility
• Mobile-first
• Progressive enhancement
• Resilient Web Design
• Progressive Web App enabled

We are trying to be the starter theme for design-focused devs. If you have any ideas, questions, or suggestions for this project or are seeking to get involved in contributing or maintaining, please check out our discussion board on Github and read our contribute page on our website.

Documentation

We have a new Documentation area that can be found on the WP Rig website. If you would like to contribute to our documentation efforts, please submit a request on our contribute page on our website.

Installation

WP Rig has been tested on Linux, Mac, and Windows.

Requirements

WP Rig requires the following dependencies. Full installation instructions are provided at their respective websites.

• PHP 7.0 or higher (PHP 8 recommended)
• npm
• Composer (installed globally)

WP Rig and child themes

WP Rig is built to lay a solid theme foundation, which is excellent for a parent theme but not for a child theme. A child theme is meant to only add on or modify the foundation. As such, WP Rig is not intended for making child themes to extend any themes, whether they were originally built with WP Rig or not.

How to install WP Rig:

1. Clone or download this repository to the themes folder of a WordPress site on your development environment.
   • DO NOT give the WP Rig theme directory the same name as your eventual production theme. Suggested directory names are wprig or wprig-themeslug. For instance, if your theme will eventually be named “Excalibur” your development directory could be named wprig-excalibur. The excalibur directory will be automatically created during the production process and should not exist beforehand.
2. Configure theme settings, including the theme slug and name.
   • View ./config/config.default.json for the default settings.
   • Place custom theme settings in ./config/config.json to override default settings.
     • You do not have to include all settings from config.default.json. Just the settings you want to override.
   • Place local-only theme settings in ./config/config.local.json, e.g. potentially sensitive info like the path to your BrowserSync certificate.
     • Again, only include the settings you want to override.
3. In the command line, run npm run rig-init to install necessary node and Composer dependencies.
4. In the command line, run npm run dev to process source files, build the development theme, and watch files for subsequent changes.
   • npm run build can be used to process the source files and build the development theme without watching files afterwards.
5. In WordPress admin, activate the WP Rig development theme.

Defining custom settings for the project

Here is an example of creating a custom theme config file for the project. In this example, we want a custom slug, name, and author.

Place the following in your ./config/config.json file. This config will be versioned in your repo, so all developers use the same settings.

{
  "theme": {
    "slug": "newthemeslug",
    "name": "New Theme Name",
    "author": "Name of the theme author"
  }
}

Defining custom settings for your local environment

Some theme settings should only be set for your local environment. For example, if you want to set local information for BrowserSync.

Place the following in your ./config/config.local.json file. This config will not be tracked in your repo and will only be executed in your local development environment.

{
  "browserSync": {
    "live": true,
    "proxyURL": "localwprigenv.test",
    "https": true,
    "keyPath": "/path/to/my/browsersync/key",
    "certPath": "/path/to/my/browsersync/certificate"
  }
}

If your local environment uses a specific port number, for example, 8888, add it to the proxyURL setting as follows:

"proxyURL": "localwprigenv.test:8888"

How to build WP Rig for production:

1. Follow the steps above to install WP Rig.
2. Run npm run bundle from inside the wp-rig development theme.
3. A new, production-ready theme will be generated in wp-content/themes.
4. The production theme can be activated or uploaded to a production environment.

Wiki: Recommended code editor extensions

To take full advantage of the features in WP Rig, visit the Recommended code editor extensions Wiki page.

Working with WP Rig

WP Rig can be used in any development environment. It does not require any specific platform or server setup. It also does not have an opinion about what local or virtual server solution the developer uses.

Before the first run, visit the BrowserSync wiki page.

Available Processes

dev watch process

npm run dev will run the default development task that processes source files. While this process is running, source files will be watched for changes, and the BrowserSync server will run. This process is optimized for speed, so you can iterate quickly.

dev build process

npm run build processes source files one-time. It does not watch for changes nor start the BrowserSync server.

translate process

The translation process generates a .pot file for the theme in the ./languages/ directory.

The translation process will run automatically during production builds unless the export:generatePotFile configuration value in ./config/config.json is set to false.

The translation process can also be run manually with npm run translate. However, unless NODE_ENV is defined as production, the .pot file will be generated against the source files, not the production files.

production bundle process

npm run bundle generates a production-ready theme as a new theme directory and, optionally, a .zip archive. This builds all source files, optimizes the built files for production, does a string replacement and runs translations. Non-essential files from the wp-rig development theme are not copied to the production theme.

To bundle the theme without creating a zip archive, define the export:compress setting in ./config/config.json to false:

export: {
	compress: false
}

Gulp process

WP Rig uses a Gulp 4 build process to generate and optimize the code for the theme. All development is done in the wp-rig development theme. Feel free to edit any .php files. Asset files (CSS, JavaScript and images) are processed by gulp. You should only edit the source asset files in the following locations:

• CSS: assets/css/src
• JavaScript: assets/js/src
• images: assets/images/src

For more information about the Gulp processes, what processes are available, and how to run them individually, visit the Gulp Wiki page.

Browser Support

As WP Rig processes CSS and JavaScript, it will support the browsers listed in .browserslistrc. Note that WP Rig will not add polyfills for missing browser support. WP Rig will add CSS prefixes and transpile JavaScript.

Advanced Features

WP Rig gives the developer an out of the box environment with support for modern technologies, including ES2015, CSS grid, CSS custom properties (variables), CSS nesting and more, without making any configurations. Just write code, and WP Rig handles the heavy lifting for you.

Configuring the behavior of WP Rig is done by editing ./config/config.json. Here the developer can set the theme name and theme author name (for translation files) and local server settings for BrowserSync. Additionally, compression of JavaScript and CSS files can be turned off for debugging purposes.

Place your custom theme settings in ./config/config.json to override default settings, located in ./config/config.default.json. Place local-only/untracked theme settings in ./config/config.local.json. For example, if you want to set local information for BrowserSync.

WP Rig ships with advanced features, including:

• Easily add custom Customizer settings using .json file
• Built-in support for the official AMP plugin
• Progressive loading of CSS
• Modern CSS, custom properties (variables), autoprefixing, etc
• Modern layouts through CSS grid, flex, and float

For more information about the advanced features in WP Rig and how to use them, visit the Advanced Features Wiki page.

License

WP Rig is released under GNU General Public License v3.0 (or later).

wprig's Issues

Lazy Loading Makes Custom Logo Invisible Until Scroll

Issue Overview

Note: I'm only experiencing this issue on safari / iOS

Lazy Loading is preventing the custom logo from being displayed in the site header. In its place, you'll see extra vertical white space. Once you scroll, the logo appears and the header adjusts to the appropriate size.

Steps to Reproduce

1. Ensure Lazy Loading is enabled
2. Replace your site title with a custom logo
3. View your site on iOS

Update functions.php to include new Gutenberg features including block font sizes

for reference:
https://github.com/WordPress/gutenberg/blob/master/docs/extensibility/theme-support.md#block-font-sizes

Content width is not using $GLOBALS['content_width'] when set.

Issue Overview

In the function wprig_content_width(), code exists to assign the content's width from the global. However, on the next line, the width is overwritten with a integer literal of 720:

function wprig_content_width() {

	if ( isset( $GLOBALS['content_width'] ) ) {
		$content_width = $GLOBALS['content_width'];
	}
	$content_width = 720;

Expected Behavior

I would expect that we want this to be an either or assignment. Correct? Either the global or the default.

Current Behavior

720 is always assigned prior to the filter.

Possible Solution

I'd propose refactoring the code like this:

function wprig_content_width() {

	$content_width = isset( $GLOBALS['content_width'] )
		? (int) $GLOBALS['content_width']
		: 720;

With this change, are doing the following:

1. If the global exists, we type cast it to integer and then assign it to the variable.
2. Else, we assign a default value of 720.

Potential gulp improvements

Issue Overview

I have some personal gulp preferences from things I learned implementing gulp 4 in other projects. I am not sure if these are welcome improvements to WP Rig or not.

Please let me know if you would consider some, or all, of these changes. If so I am happy to submit a pull request but don't want to spent time doing without validation of the improvement ideas.

Improvement list

Monolithic gulp file

gulpfile.babel.js is a monolithic file that can be modularized

Suggested Solution

gulpfile.babel.js is written in ES6+ and can make use of imports. Here is an example

Manually loading gulp plugins

gulpfile.babel.js manually loads gulp plugins. This currently adds 23 lines to the file.

Suggested Solution

Use gulp-load-plugins to store gulp plugins in a single variable.

Misc ES6+ Syntax updates

The gulpfile.babel.js uses some older conventions, such as concatenating strings with +.

Suggested Solution

Update gulpfile.babel.js to consistently use modern conventions. In this specific example using template literals.

Use pump instead of pipe

gulp 4 suggests the use of pump instead of pipe. See why use pump.

Suggested Solution

Update gulpfile.babel.js to use pump instead of pipe. Here is an example.

Related Issues and/or PRs

Unsure if I should wait for the work in #30 to be merged before starting more gulp work.

Duplicate Page Templates in Selection Picklist (Dev and Verbose)

Question Overview

When selecting a page template, I see three instances of the two page templates I created. When inspecting the select list, I learned that the duplicates are coming from the /dev folder and the /verbose folder.

<select id="template-selector-0"> <option value="">Default template</option> <option value="dev/header.php">Contact</option> <option value="dev/landing-page.php">Landing Page</option> <option value="header.php">Contact</option> <option value="landing-page.php">Landing Page</option> <option value="verbose/header.php">Contact</option> <option value="verbose/landing-page.php">Landing Page</option> </select>

Why is this? Which template should I be selecting?

Rethink drop-down menu, particularly chevrons

Issue Overview

Drop-down menu doesn't work quire right. Chevron shows up where it shouldn't, has minimal functionality. Could use better CSS and possibly retire the whole JS solution.

Editor styles need to be resolved

Gutenberg handles editor styles in an unusual way. The current styles do some of the work, but a full review is necessary to get proper match between back- and front-end.

PNG files cause failures in node_modules/zopflipng-bin/vendor/zopflipng

Issue Overview

Adding specific PNG files to /dev/images causes errors with node_modules/zopflipng-bin/vendor/zopflipng

Describe your environment

Testing server is local hosted vagrant.
Local node environment is MacOS 10.13.6 with node v10.7.0 with npm 3.10.5. Installed with homebrew.

Steps to Reproduce

1. Setup wprig either current branch or v1.1, run 'npm install' and 'npm run build'
2. Add the attached PNG file to /dev/images
3. Boom! Error output, file is not copied.

[09:54:58] Error in plugin "gulp-image"
Message:
Command failed: /Users/webmanager/Desktop/nicholls-vagrant/sites/www/wp-content/themes/nicholls_2018_core/node_modules/zopflipng-bin/vendor/zopflipng -
y --lossy_8bit --lossy_transparent /private/var/folders/3b/_s0mjl790md6vqdsdtl4c5k80000gq/T/78574744-9595-4b4f-9e77-c066f23ac42f /private/var/folders/3b/_s
0mjl790md6vqdsdtl4c5k80000gq/T/398ee317-3c1e-4e82-8c00-c9543ab42a0c

Optimizing /private/var/folders/3b/_s0mjl790md6vqdsdtl4c5k80000gq/T/78574744-9595-4b4f-9e77-c066f23ac42f
Encoding error 82: color conversion to palette requested while a color isn't in palette

Decoding error 82: color conversion to palette requested while a color isn't in palette
There was an error

Details:
code: 1
killed: false
stdout: Optimizing /private/var/folders/3b/_s0mjl790md6vqdsdtl4c5k80000gq/T/78574744-9595-4b4f-9e77-c066f23ac42f
Encoding error 82: color conversion to palette requested while a color isn't in palette
Decoding error 82: color conversion to palette requested while a color isn't in palette
There was an error

stderr:
failed: true
signal: null
cmd: /Users/webmanager/Desktop/nicholls-vagrant/sites/www/wp-content/themes/nicholls_2018_core/node_modules/zopflipng-bin/vendor/zopflipng -y --lossy_8
bit --lossy_transparent /private/var/folders/3b/_s0mjl790md6vqdsdtl4c5k80000gq/T/78574744-9595-4b4f-9e77-c066f23ac42f /private/var/folders/3b/_s0mjl790md6v
qdsdtl4c5k80000gq/T/398ee317-3c1e-4e82-8c00-c9543ab42a0c
timedOut: false

Expected Behavior

Expected to optimize and move files to /images

Current Behavior

Error thrown and files not copied.

Possible Solution

So far solution is to find another image. I've made PNG images with Photoshop and Gimp and the file continues to have problems. So far I've seen this with 3 separate PNG files.

Little Question mark PNG that fails is below... its small with a transparent background.

question.png

How to move dropdown-symbol inside the '<a>' tag in navigation?

Issue Overview

How can I customize the navigation and drop-down-menus? Currently, the symbol icon or the toggle-button for drop down is outside "" tag in the link.

this makes problem on mobile menu. I mean the symbol shift to the right and the menu at left. It makes it hard to position it right beside the drop-down item.

Overall, I want to customize the navigation structure. where I can I change all those behaviours.

Thank you :)

Describe your environment

Steps to Reproduce

Expected Behavior

Current Behavior

Possible Solution

Screenshots / Video

Related Issues and/or PRs

Recent changes to style.css made the theme out of sync with the tutorial video

Great job here and with the video series.

Issue Overview

The tutorial video gives an example of editing the CSS by making some changes to the menu. However, there were changes to the menu CSS a few days ago: "Optimizing main menu to be accessible". Now the github version and the tutorial example are out of sync.

Possible Solution

There may not be anything that could be done about this, but perhaps a note under the video or something might help avoid confusion for those doing the tutorial.

Screenshots / Video

Related Issues and/or PRs

gulp issues when set compress to false

Issue Overview

When I checkout v1.1, and set compress: false for export in the config file, it throws the following error:

The following tasks did not complete: bundleTheme, bundle
Did you forget to signal async completion?

Could this have something to do with the gulp improvements commit, @ataylorme?

Describe your environment

Running branch v1.1.

Steps to Reproduce

1. Checkout v1.1
2. Run npm install.
3. Change compress: false for export settings
4. Run npm run bundle.

Expected Behavior

Current Behavior

Possible Solution

Screenshots / Video

Related Issues and/or PRs

Fatal Error when activating wprig theme

Issue Overview

I've got a local development environment set up on a Windows 10 PC using WampServer and VSCode, and when I log in to my WordPress admin and attempt to activate the wprig theme (which I've named "wp") .. I'm getting the following fatal error:

Fatal error: Cannot redeclare wp_scripts() (previously declared in C:\wamp64\www\wp\wp-includes\functions.wp-scripts.php:21) in C:\wamp64\www\wp\wp-content\themes\wp\functions.php on line 292

I've tried downgrading the PHP versions from 7.x down to 5.x, .. but I still get the same error.

I've followed all of the instructions, have all of the necessary settings properly configured in VSCode, was able to run "npm run build" without any issues and have BrowserSync up and running. But the fatal error I'm getting is preventing me from going any further. Any ideas as to what might be happening?

• Yvan

Creation of new WP templates

Hi, this rig is perfect for theme development. Also a BIG thanks for the tutorials on LinkedIn Learning. There is one thing I need to ask you though. Is there a plan for a tutorial on hoe to create new WP templates (like WooCommerce pages etc...)?

I know I can add these easily, but I don't want to loose all the WP Rig goodies in the process of creating these.

Thanks.

Error on npm run build

Hi,

I would love to chechout/use this theme. I managed to update to Gulp 4 and did a succesfull npm install but am getting an error when trying to run npm run build

Failed to load external module @babel/register
[15:16:46] Requiring external module babel-register
/Users/tibor/Sites/wprig/wp-content/themes/wprig/node_modules/matched/lib/promise.js:8
module.exports = async function(patterns, options) {
                       ^^^^^^^^
SyntaxError: Unexpected token function
    at createScript (vm.js:56:10)
    at Object.runInThisContext (vm.js:97:10)
    at Module._compile (module.js:542:28)
    at Module._extensions..js (module.js:579:10)
    at Object.require.extensions.(anonymous function) [as .js] (/Users/tibor/Sites/wprig/wp-content/themes/wprig/node_modules/babel-register/lib/node.js:152:7)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)
    at Module.require (module.js:497:17)
    at require (internal/module.js:20:19)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] build: `gulp`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] build script.

Can't really figure out what's happening that causes this error, so hoping for suggestions :-)

Thanks in advance!

Cheers , Tibor

Error in navigation.js

Issue Overview

Javascript error prevents navigation from working correctly. The slug is not replaced correctly.

Describe your environment

macOS. I get an error [13:51:10] Failed to load external module @babel/register [13:51:10] Requiring external module babel-register but that's unrelated, right?

Steps to Reproduce

1. clone wp-rig
2. edit themeConfig.js, change slug & name
3. run npm build

Expected Behavior

return e.classList.add("dropdown-toggle"), e.setAttribute("aria-expanded", "false"), e.setAttribute("aria-label", **myThemeName**ScreenReaderText.expand), e

Current Behavior

return e.classList.add("dropdown-toggle"), e.setAttribute("aria-expanded", "false"), e.setAttribute("aria-label", **myThemeName - theme**ScreenReaderText.expand), e

Add integration tests for functionality

Issue Overview

While themes generally should not contain too much functionality (plugin territory), they always do contain some functionality (and they have to), for example to define the theme behavior, to register sidebars, customizer integration etc.

Just like plugins, this functionality should be tested. As a first step, I suggest adding an infrastructure for integration tests, which work relatively similar to how WordPress plugins are commonly tested: WordPress is loaded in a specific version, and then the theme's individual functions are checked for whether they interact with WordPress in the way they should.

Actual unit tests would also be useful, however that should be part of a separate issue. Integration tests are already widely known and used for WordPress plugins, so we can do this as a first iteration.

Possible Solution

I have recently set this up for a theme I have developed. I use a similar technique like the typical plugin tests (see https://make.wordpress.org/cli/handbook/plugin-unit-tests/):

• PHPUnit is used to initialize the test suite and run tests.
• The WordPress core test suite is loaded (detected via environment variable, or a fallback assuming that the theme is actually in the themes directory of the tested WordPress instance).
• Per a custom theme tests bootstrap script, WordPress is tricked into thinking that our theme is the currently active theme.
• We can now run tests with the theme being active, using WordPress core functionality.
• Integration tests should be run in CI as well. I suggest we introduce a new .travis.yml environment variable INTEGRATION, and if that is set (via INTEGRATION=1), PHPUnit is installed, the WordPress core development version is downloaded, and our tests are run. The WordPress version should be dynamically set via another WP_VERSION environment variable.
• In terms of the test matrix, I think two new setups should be used: Both on the latest PHP version, both with INTEGRATION=1. One should then use the minimum required WordPress version of the theme, the other the newest version the theme has been tested with.

Aside: Before working on a PR for this, I'll wait until the existing related PRs have been closed, in order to not run into too many merge conflicts later.

Coding standards check - don't use WordPress

Issue Overview

Hi!

I saw that you are using 4 rulesets in the phpcs.xml.dist

wprig/phpcs.xml.dist

Lines 36 to 39 in acae4c3

	<rule ref="WordPress"/>
	<rule ref="WordPress-Core" />
	<rule ref="WordPress-Docs" />
	<rule ref="WordPress-Extra" />

Loading the WordPress coding standard will load WordPress-VIP, Core, Docs and Extra and that is not necessary for the themes on wordpress.org.

Possible Solution

We are currently working on WordPress-Theme standard, which will soon be separated into its own standard, that is meant just for the theme checking. So you can use this one for the time being. I think you'd only need to add this to your composer

"repositories": [
  {
    "type": "vcs",
    "url": "https://github.com/WPTRT/WordPress-Coding-Standards"
  }
],
"require": {
  "wp-coding-standards/wpcs": "dev-feature/theme-review-sniffs",
  "wimg/php-compatibility": "*"
},

and you can then use it as <rule ref="WordPress-Theme"/> in the ruleset :)

[Question/Feedback] Good tools, why so opiniated ?

Issue Overview

Not an issue but a question.
WPRig is very good boilerplate with useful tools to create a good theme and thanks for that; but why stylesheets are so much opiniated ? (fonts, colors, header).
I think, before test it, I saw it more like a starter theme, without decorative styles.

Handle replacement of theme name separately from the slug

Issue Overview

By default, the current codebase uses wprig as both the theme slug and the theme name. This is however an unlikely scenario for most themes (consider twentyseventeen vs Twenty Seventeen for example), so these two should be handled separately when making replacements.

Steps to Reproduce

1. Set the theme name to a proper theme name, such as a string containing spaces and uppercase/lowercase.
2. Run gulp build.
3. The code will not work since function names suddenly look like My Theme_setup() for example.

Expected Behavior

Theme name and slug should be two separate things. By default wprig should be the slug and WP Rig the name.

Possible Solution

A new key theme.slug should be added to the config in dev/config/themeConfig.js, with the value wprig. The theme.name value should be changed to WP Rig. All occurrences where wprig is actually used as theme name should be manually replaced with WP Rig too. Then, in the gulp scripts, always replace both values appropriately.

javascript compilation question – browser support

Issue Overview

Is wprig supposed to compile js for the browser specified in themconfig.js "browserlist"?

Describe your environment

Steps to Reproduce

wprig1.03 without any modifications.

		browserslist: [ // See https://github.com/browserslist/browserslist
			'> 1%',
			'last 2 versions'
		],

Expected Behavior

Navigation dropdown should work in IE/Edge

Current Behavior

Javascript Error on Edge40, IE11

Object doesn't support property or method 'forEach'
navigation.js (1, 217)

Possible Solution

Screenshots / Video

Related Issues and/or PRs

Helpful documentation for Virtualbox/Vagrant using BrowserSync

Issue Overview

Just some possible documentation help. This only works on my MacOS environment, but may be useful elsewhere. I know advanced users probably know about port forwarding already, but this single line helped BrowserSync work on my Vagrant setup.

# trying to fix browsersync
config.vm.network :forwarded_port, guest: 80, host: 3000, auto_correct: true

Describe your environment

Based on my really low-fi Vagrant setup at: https://github.com/ev3rywh3re/vagrant-wp-simple
MacOS 10.13.6
VirtualBox 5.2.14
Vagrant 2.1.2

Steps to Reproduce

1. Setup Vagrant/VirtualBox (advanced topic anyway...)
2. Setup wprig.
3. Run 'npm install' and 'npm run build'
4. Browsers won't work on localhost and don't reload while working on wprig.

Expected Behavior

Browsers reload as wprig is developed

Current Behavior

Depending on your system and your Vagrant setup, BrowserSync probably won't work.

Possible Solution

Adding the following line to my Vagrantfile worked like a charm. With BrowserSync working on http://localhost:8181 with the BrowserSync UI available at http://localhost:3001

# trying to fix browsersync
config.vm.network :forwarded_port, guest: 80, host: 3000, auto_correct: true

Don't style classes used for structured data

Classes used for structured data should not be part of the stylesheet. Having structured data or not should not have an influence on the appearance of the site.

Related issues from Underscores:

• Don't style hatom classes
• Remove Microformat Classes from CSS

Merge conflict in /v1.1/gulp/php.js#L65

Issue Overview

This is about the v1.1 branch.
A merge conflict was left/appeared in https://github.com/wprig/wprig/blob/v1.1/gulp/php.js#L65 causing the Gulp task to error.

Describe your environment

Windows 10 (not WSL)

Steps to Reproduce

1. Checkout the v1.1 branch
2. run npm install
3. ignore that Guetzli doesn't seem to build on Windows 10.
4. run npm run build

Expected Behavior

The Gulp tasks run.

Current Behavior

Gulp errors.

Possible Solution

Remove the merge conflict.

Screenshots / Video

Related Issues and/or PRs

Enhancement: Support HTTPS

Issue Overview

Currently Browser sync only supports http

Describe your environment

local dev environment running nginx via hombrew in macOS. Using a local SSL cert (not self-signed)

Steps to Reproduce

Possible Solution

gulp.task('browser-sync', function() {
    browserSync.init({
        proxy: projectURL,
        https: {
            key: keyPath,
            cert: certPath
        }
    })
})

where keyPath and certPath are user variables for the respective paths. projectURL I believe is same as current proxyURL in the config.

I'd guess a simple check for those variables from themeConfig.js and then passing them into the https key for browserSync should work.

Does that sound logical and if so, I can take a stab at a PR.

Update to WordPress Coding Standards 1.0.0

https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards/releases/tag/1.0.0

Enhancement: Add support for microformats(mf2)

Adding mf2 to themes would allow easy integration with Webmentions and greater IndieWeb

WPRig has a lot of cross over with a project I’ve been working on and if could get mf2 in wprig, I would mothball my project. I’m offering to work on a PR, but wanted to gauge interest before embarking on it.

Add Stylelint

Issue Overview

Feature request to add Stylelint, CSS linter.

Thanks for the project. It is awesome, that you promote ESLint for JS code quality control. Maybe we should do the same for CSS?

Stylelint right now is the most powerful and the most popular CSS linter.
https://stylelint.io/

There is even Stylelint config from WordPress team
https://github.com/WordPress-Coding-Standards/stylelint-config-wordpress

Expected Behavior

Use Stylelint to lint CSS

Current Behavior

Only ESLint for JS

Possible Solution

Add Stylellint

Use a theme slug that is more than one word

Issue Overview

We need to consider whether the theme slug in themeConfig.js will always be the only parameter that needs to be covered when making initial naming replacements. The slug at the moment is only a single word, however what happens if the the slug would be something consisting of two words? If I want to have my-theme, this would only work as a textdomain replacement, but no longer as function name prefix replacement (we'd probably need to sanitize it to my_theme there. If the code at some point includes classes or namespaces, we would also need to account for My_Theme.

Possible Solution

I think the starter theme would be better off using distinct wp_rig and wp-rig strings, possibly even WP_Rig. That would make replacements in such cases easily possible while at the moment it uses the simplest use-case.

Related Issues and/or PRs

This came up during #31.

Suggestion: Ignore composer.lock and package-lock.json files.

Issue Overview

The problem:
The composer.lock and package-lock.json files are updated based upon the local environment's stack.

Why?
Each contributor will have a different tech stack with different versions of composer, PHP, node, and npm.

When a contributor is using a different version of node, npm, or PHP, the dependency versions are updated. Therefore, when the contributor commits a change, the new lock file is also committed.

These lock files are required for development purposes and are not part of the prod theme.

Steps to Reproduce

1. With npm version 5.6.0 and node v9.0.0, we get a different package-lock.json file when running npm install.
2. With running a different version of PHP, we can get a different composer.lock file if dependency versions are different, such as when we add tests.

Expected Behavior

I would expect that each contributor runs the proper setup process of npm install upon the first setup which installs the node modules and then runs composer install.

I would expect in some cases that the package-lock.json file changes based upon the local stack.

I would expect running composer update and npm update to also change the files.

I would not expect these updated lock files to be committed for each developer when opening a PR or pushing a hotfix.

Current Behavior

When I run npm install on my machine, the package-lock.json is modified. Running git diff, here are the first page of results:

diff --git a/package-lock.json b/package-lock.json
index 678ccf5..a8bd62b 100644
--- a/package-lock.json
+++ b/package-lock.json
@@ -10,11 +10,11 @@
       "integrity": "sha1-z6I7xYQPkQTOMqZedNt+epdLvuE=",
       "dev": true,
       "requires": {
-        "acorn": "^5.0.3",
-        "css": "^2.2.1",
-        "normalize-path": "^2.1.1",
-        "source-map": "^0.5.6",
-        "through2": "^2.0.3"
+        "acorn": "5.5.3",
+        "css": "2.2.3",
+        "normalize-path": "2.1.1",
+        "source-map": "0.5.7",
+        "through2": "2.0.3"

Notice the changes. That means when I make a commit, the new lock file will be tracked and included in the commit.

Possible Solution

I propose that we:

1. remove them from the repository.
2. ignore both in the .gitignore file.

Add phpcbf to help fix minor errors automatically

Issue Overview

Setting up a theme from other existing files, I am getting a ton of phpcs warnings on rebuild.

Describe your environment

MacOs High Sierra, php7.1.7, WP 4.9.7, mysql 5.6.37, nginx

Possible Solution

Add in a gulp task to run phpcbf and fix errors

Overall I am loving wprig in general. Thank you for making such a great modern wp starter!

Make the theme actually require PHP 7.0 with graceful fallback

Issue Overview

As stated in the project readme, the theme requires PHP 7.0. We should be enforcing that so that we can securely use also PHP-related modern practices, and do this gracefully though so that users are notified about the requirement being insufficient instead of encountering a WSOD.
The WordPress theme repository will soon support a new header too in which the minimum required PHP version can be specified (this is already the case for plugins and for themes it has been agreed on as well, just needs to be implemented).

Possible Solution

• We should move all actual functions out of functions.php into subfiles in the inc directory that will then be included. This will make the "bootstrap" file plain and simple and in the process also likely improve file organization (most of the code could probably go into a file inc/setup.php).
• By having functions.php only contain inclusions of other files, we can now theoretically use PHP 7.0 code in all other included files. Only functions.php must remain parseable by PHP 5.2.
• What we need to do then is implement a inc/back-compat.php file which also needs to be parseable by PHP 5.2. That file should add the necessary hooks for when the PHP version is insufficient, notifying the user of that requirement and stopping related functionality in a graceful way.
• That file should then be included by functions.php if the PHP version is lower than 7.0. If it is, after including that file we should simply put a return statement, in order to prevent the other (regular) files from being included.

The above is already an established practice for ensuring the minimum WordPress version requirement is met, used for example by Twenty Seventeen. I also have it implemented in my own boilerplate, and it would be easy to adapt it to work for the PHP version instead of the WordPress version.

Help Wanted: Restarting Workspace

If I quit the wprig project, shut down MAMP and restart mac are there any requirements (EG Terminal Commands) when I next continue with development?

npm update failed

I have followed the steps that tell me to install the development theme but I get this notice and does not change the style.css data or I do not know what else does not change

Improve logic in wprig_scripts()

Issue Overview

In wprig_scripts(), a conditional check for the return of wprig_is_amp() is done, and loads the scripts only if AMP is not active.

Possible Solution

The logic would be better by inverting the conditional check, returning early if AMP is active, and then doing all the enqueuing.

Related Issues and/or PRs

Upgrade to replace cssnext with postcss-preset-env

Issue Overview

cssnext has been deprecated for postcss-preset-env (see official post). cssnext should be replaced with postcss-preset-env.

Update must account for current variables behavior.

Add on/off option for PHPCS in Gulp process.

Add a true/false trigger for PHPCS to run in the Gulp process. If a developer already has PHPCS integrated with their code editor, it is superfluous to run it again during the build process.

Related Issues and/or PRs

#42

[Questions/Suggestions] WooCommerce compatibility..?

Issue Overview

Hi,
Apologize if i post it on the wrong sections. Do you plan on adding Woo Compability on this Build?

Thank you.

Notice: add_theme_support() was called incorrectly.

Setting colors using multiple parameters is deprecated. Please pass a single parameter with an array of colors. See https://wordpress.org/gutenberg/handbook/extensibility/theme-support/ for details.

In dev/functions.php around line 104.

Notice: add_theme_support() was called <strong>incorrectly</strong>. Setting colors using multiple parameters is deprecated. Please pass a single parameter with an array of colors. See https://wordpress.org/gutenberg/handbook/extensibility/theme-support/ for details. Please see <a href="https://codex.wordpress.org/Debugging_in_WordPress">Debugging in WordPress</a> for more information. (This message was added in version 3.4.0.) in C:\wamp64\www\ptplayground\wp-includes\functions.php on line 4161
Call Stack
#	Time	Memory	Function	Location
1	0.0005	428904	{main}( )	...\post.php:0
2	0.2829	27623112	apply_filters( )	...\post.php:155
3	0.2829	27623512	WP_Hook->apply_filters( )	...\plugin.php:203
4	0.2829	27624904	gutenberg_init( )	...\class-wp-hook.php:286
5	0.2837	27659896	require_once( 'C:\wamp64\www\ptplayground\wp-admin\admin-header.php' )	...\gutenberg.php:191
6	0.2848	27669272	do_action( )	...\admin-header.php:97
7	0.2848	27669648	WP_Hook->do_action( )	...\plugin.php:453
8	0.2848	27669680	WP_Hook->apply_filters( )	...\class-wp-hook.php:310
9	0.2959	27723200	gutenberg_editor_scripts_and_styles( )	...\class-wp-hook.php:286
10	0.3764	29145880	_doing_it_wrong( )	...\client-assets.php:1157
11	0.3764	29146888	trigger_error ( )	...\functions.php:4161

Also editor-color-palette arrays are missing the slug eg:

array(
			'name'  => 'Dusty orange',
			'slug'  => 'dusty-orange',
			'color' => '#ED8F5B',
		),

SVG sprite generation

I've added a task to the gulpfile to watch for SVG images in mytheme/dev/sprite and create a single SVG sprite from them in mytheme/sprite. The sprite contains symbols with IDs generated from the SVG filenames.

Is this something you would be interested in adding to wprig, or is it outside the scope?

It uses svgmin, svgstore and path:

export function sprite() {
	return gulp.src(paths.sprite.src)
	.pipe(svgmin(function(file) {
		var prefix = path.basename(file.relative, path.extname(file.relative));
		return {
			plugins: [{
				cleanupIDs: {
					prefix: prefix + '-',
					minify: true
				}
			}]
		}
	}))
	.pipe(svgstore())
	.pipe(gulp.dest(paths.sprite.dest));
}

I'm happy to submit a pull request, but I'm new to Gulp4 so I'm sure my code could be improved (for example, spaces in filenames need to be converted to hyphens in the symbol IDs).

Notice: is_amp_endpoint was called incorrectly

Issue Overview

When the AMP plugin and the lazy-loading feature are activated, the following notice is issued:

Notice: is_amp_endpoint was called incorrectly. is_amp_endpoint() was called before the 'parse_query' hook was called. This function will always return 'false' before the 'parse_query' hook is called. Please see Debugging in WordPress for more information. (This message was added in version 0.4.2.) in /www/wp.test/wp-includes/functions.php on line 4161

Describe your environment

WP Rig 1.0.2
WordPress 4.9.7
Apache/2.4.33 (Unix)
PHP/7.2.4

Steps to Reproduce

1. Set the define('WP_DEBUG', true); in wp-config.php;
2. Activate the AMP for WordPress plugin;
3. Activate the lazy-loading feature;
4. Visit any AMP page.

Possible Solution

The function wprig_lazyload_images(), which calls the wprig_is_amp() function inside, must only be called after the parse_query action.

Only run styles process on changed files

Issue Overview

When the styles process runs, it runs through all CSS files every time. This adds unnecessary lag in the system.

Possible Solution

Use newer in combination with some logic to run the styles process on changed files only. Probably something similar to the logic around the php task created by @hellofromtonya.

Caveats:

Some conditions need to be accounted for:

• First run (process all SCSS and CSS files)
• Changes to /dev/config/cssVariables.json (process all SCSS and CSS files)
• bundle script (process all SCSS and CSS files)

Related Issues and/or PRs

Issue came up during testing around #42

Slick Slide Integration

Issue Overview

Slick Slide is one of the most used carousel/slideshow outhere.
Which is the the best way to integrate it in WP Rig?

Expected Behavior

Slick Slide should be loaded only where is used.

First, I tried to include slick.min.js, only for certain page template:
if ( is_page_template( 'page-with-slick.php' ) ) { wp_enqueue_script( 'wprig-slick-slide-script-min', get_theme_file_uri( '/js/slick.min.js' ), array(), '20180626', true ); }

Unfortunately, the conditional is_page_template is not working for me in wp rig.
However, ( is_page(ID) ) is working (slick.min.js is loaded only on page with ID 41). A more general solution is ideal (like is_page_template).

the same in css case:
// Preload css for slick slide if ( is_page_template('page-with-slick')) { $preloads['wprig-slick'] = wprig_get_preload_stylesheet_uri( $wp_styles, 'wprig-slick' ); $preloads['wprig-slick-theme'] = wprig_get_preload_stylesheet_uri( $wp_styles, 'wprig-slick-theme' ); }

autoprefixer not working

Issue Overview

Autoprefixer does not seem to run

Describe your environment

wprig 1.03

Steps to Reproduce

1. Edit browserlist:

		browserslist: [ // See https://github.com/browserslist/browserslist
			'> 0.5%',
			'last 2 versions',
			'Firefox ESR',
			'not dead'
		],

2. npm run build

Expected Behavior

Prefixes for IE11 added in style.css

Current Behavior

No prefixes added.

Add the ability to generate an SSL certificate with gulp

See #57 for background information. Generating SSL certs requires specialized knowledge and can be cumbersome to get correct. By creating a gulp task that automates generating an SSL certificate we can take this burden off WP Rig users.

Additionally, the gulp and BrowserSync config can be updated to automatically turn on HTTPS when a generated cert is present in the default directory. The step of trusting the cert will still be manual, however.

Is this method for testing AMP plugin activation still accurate

wprig/dev/inc/template-tags.php

Lines 10 to 20 in a237423

	/**
	* Determine whether this is an AMP response.
	*
	* Note that this must only be called after the parse_query action.
	*
	* @link https://github.com/Automattic/amp-wp
	* @return bool Is AMP endpoint (and AMP plugin is active).
	*/
	function wprig_is_amp() {
	return function_exists( 'is_amp_endpoint' ) && is_amp_endpoint();
	}

I have a feeling the answer is 'no'. Can someone verify / change?

@westonruter
@amedina

Faster Browser reload?

Issue Overview

After any change, browser reloads itself in 5 to 10 seconds

Describe your environment

Win 10; I5 CPU; 16Gb
WAMPSERVER 3.1.3 64bit; (PHP 7.2.4; MySQL 5.7.21) Visual Studio Code 1.24.1 (fresh install, no extensions)

Steps to Reproduce

1. dev/style.css
2. search for .site-header
3. add background: orange
4. CTRL+S
5. Chrome windows reloads in 5 to 6 sec

Expected Behavior

When working with _S & Prepros, window reloads instantly

Current Behavior

Time: 352ms; Memory: 10Mb [13:24:10] Finished 'styles' after 3.18 s [13:24:10] Starting 'reload'... [13:24:10] Finished 'reload' after 1.95 ms [Browsersync] Reloading Browsers...

Fix array to string conversion error

When debug is set to true, the following error appears:

Notice: Array to string conversion in /.../wp-content/themes/wprig/functions.php on line 256

The line in question:

		$font_families[] = "{$font_name}:{$font_variants}";

in the function:

foreach ( $fonts_register as $font_name => $font_variants ) {
	if ( ! empty( $font_variants ) ) {
		$font_families[] = "{$font_name}:{$font_variants}";
	} else {
		$font_families[] = $font_name;
	}
}

Extend cssVariables to include all colors

Issue Overview

Currently, the only color variable is global-font-color Was there a decision to not extend that to the rest of the colors used or is that open to a PR?

Re-running npm run build does not rebuild the PHP files

Issue Overview

After you've run npm run build, running it again after changing the slug in themeConfig.js does not rebuild the PHP files.

Why is this a problem?

Imagine that a developer makes a typo in the slug or wants to change its name. The assumption is the theme is regenerated. But that's not completely true. Instead, the developer is left to either search/replace to rename or delete all of the theme files and start again. Bummer.

@ygagnon notes this problem in issue #29 where he named the theme's slug wp and then needed to change it. It will happen for other developers too. Shoot, it'll likely happen for all of us where at some point we want to rename.

Steps to Reproduce

1. Clone wprig and then navigate into the folder.
2. Open wprig/dev/config/themeConfig.js.
3. Change the theme's slug.
4. Save the file.
5. In terminal, do: npm run build. Everything is cool and happy.
6. Repeat steps 2-5.

Whoops, the PHP prefixes and DocBlocks are not updated.

Expected Behavior

Regenerate the theme include the PHP files.

Current Behavior

Re-running npm run build after changing the theme's slug do the following:

T-iMac:hello hellofromtonya$ npm run build
> [email protected] build /Users/hellofromtonya/Sites/sandbox/app/public/wp-content/themes/hello
> gulp

[15:54:21] Failed to load external module @babel/register
[15:54:21] Requiring external module babel-register
[15:54:23] Using gulpfile ~/Sites/sandbox/app/public/wp-content/themes/hello/gulpfile.babel.js
[15:54:23] Starting 'default'...
[15:54:23] Starting 'php'...
[15:54:23] Finished 'php' after 119 ms
[15:54:23] Starting 'scripts'...
[15:54:23] Starting 'jsMin'...
[15:54:23] Starting 'jsLibs'...
[15:54:23] Finished 'jsLibs' after 11 ms
[15:54:23] Finished 'jsMin' after 18 ms
[15:54:23] Finished 'scripts' after 20 ms
[15:54:23] Starting 'sassStyles'...
[15:54:23] Finished 'sassStyles' after 5.54 ms
[15:54:23] Starting 'styles'...
[15:54:23] dev/style.css
[15:54:23] dev/css/comments.css
[15:54:23] dev/css/content.css
[15:54:23] dev/css/editor-styles.css
[15:54:23] dev/css/front-page.css
[15:54:23] dev/css/sidebar.css
[15:54:23] dev/css/widgets.css
[15:54:24] Replaced: "wprig" to "foo" in a file: style.css
[15:54:24] Replaced: "wprig" to "foo" in a file: style.css
[15:54:24] Replaced: "wprig" to "foo" in a file: style.css
[15:54:24] Replaced: "wprig" to "foo" in a file: style.css
[15:54:24] Replaced: "wprig" to "foo" in a file: style.css
[15:54:24] Replaced: "WP Rig" to "Hello from Tonya" in a file: style.css
[15:54:25] Finished 'styles' after 1.61 s
[15:54:25] Starting 'images'...
[15:54:25] Finished 'images' after 11 ms
[15:54:25] Starting 'serve'...
[15:54:25] Finished 'serve' after 8.57 ms
[15:54:25] Starting 'watch'...
[Browsersync] Proxying: http://foo.test:8888

Notice the following:

1. The PHP files are not rebuilt.
2. The current gulp workflow is pull from dev folder and then rename wprig to foo in this case. That makes sense.

Possible Solution

If this is how we want it to work, then the solution is to document it for developers when they want to rename the theme after building it.

If we want it to re-build/re-generate, then we'll need a solution that let's us rename functions and DocBlocks. How? Good question.

Deleting all of the generated PHP files and then re-generate solves the root problem. BUT it creates a new one when a developer has customized a file or multiple files. That's not an ideal solution.

The other way is add an alternative workflow in gulp to use the existing files and then do the renaming process. That would need some validation work to it.

Issues/concerns with theme slug and name replace

Issue Overview

We might need to re-think the global search/replace of the theme slug and name. OR at least give some documentation/instructions in the config file.

For example, be clear if the slug should have no dashes or underscores or spaces.

Example of an issue:

We use "wprigScreenReaderText" as a JS variable in our navigation script. But the "wprig" gets changed in the gulp php and scripts search/replace. I had an issue where my slug had underscores and it was causing issues because that was setting the name of a JS variable.

Related to #43.

Describe your environment

Steps to Reproduce

Expected Behavior

Current Behavior

Possible Solution

Screenshots / Video

Related Issues and/or PRs