siteorigin / theme-build Goto Github PK

One thing I can see coming up a lot is contributors not wanting their full emails in the contributors.json file. We could just as easily work with the md5 hashes of contributor emails.

So ideally the contributors task should take a config option that lets us store the hashes of the emails instead of the full emails in the json file.

At the moment the .pot file build date prints as follows:

"PO-Revision-Date: 2018-MO-DA HO:MI+ZONE\n"

If possible, let's get the month and day printing.

@braamgenis Do you think we can add Sass source maps to the dev build process?

http://thesassway.com/intermediate/using-source-maps-with-sass

It would be super helpful. Especially when jumping back into a theme you haven't been actively working on.

If possible, prevent Sass Maps from adding a comment to each main scss file and each css file:

/*# sourceMappingURL=sass/maps/style.css.map */

See comment: #1 (comment)

Hey @braamgenis. .org allows us to use minified CSS files if we include the unminified version, just as we do with JS files. Add minification would help all of our users that don't use performance plugins.

Task: Add CSS minification to the build in exactly the same way that we're currently handling JS min.

Add a new constant:

define( 'SITEORIGIN_THEME_CSS_PREFIX', '' );

We'll then change the theme CSS enqueue to:

wp_enqueue_style( 'siteorigin-unwind-style', get_template_directory_uri() . '/style' . SITEORIGIN_THEME_CSS_PREFIX . '.css', array(), SITEORIGIN_THEME_VERSION );

In the build:dev task we'll use the unminifed version and in the build:release task we'll use the minified version.

An additional task is doing the same for other CSS files. For example, in North we have https://github.com/siteorigin/siteorigin-north/blob/develop/css/north-icons.css. The same process should ideally be run on this file too.

Let me know if you'd like to run over any of these points. Cheers :)

Add live reload to build:dev.

This is a copy of siteorigin/siteorigin-unwind#211

There's an issue caused by our minify system where it's renaming a correctly named animation name (stickyMh) to a. This normally would be fine but Media Elements (which is included in the core) uses that exact animation name also so it results in the menu rotating as soon as the sticky menu is added to the page. To replicate this issue, you simply need to add a video to the page and have the sticky menu enabled.

Video of what this issue looks like (sorry for the low frame rate - I forgot to increase it)

Here's a copy of the CSS from the core that's causing the rotation.:

@-webkit-keyframes a {
    to {
        -webkit-transform: rotate(1turn);
        transform: rotate(1turn)
    }
}

@keyframes a {
    to {
        -webkit-transform: rotate(1turn);
        transform: rotate(1turn)
    }
}

Taken from wp-includes/js/mediaelement/mediaelementplayer-legacy.min.css

If possible, add livereload for JS files.

If the no video flag is set to true the theme screenshot should link to the theme page. At the moment it is but it's adding the video query to the url.

When using build:dev with vantage, I noticed that the any changes made to style.less automatically gets compiled whenever I save changes. However, the build task does not automatically run every time I save changes to the imported files. I have to stop and restart the build task to compile them.

@braamgenis Would it be possible to expand CSS minification to files in sub-folders. Here is our config:

    css: {
        src: [
            'style.css',
            'woocommerce.css',
            'woocommerce-rtl.css',
            'woocommerce-smallscreen-rtl.css',
            'css/flexslider.css',
            'css/north-icons.css',
        ],
    },

It doesn't seem to be outputting the files in the css folder but did so in earlier iterations of the build CSS minification. Thanks man.

If we want to use contributors.json in the theme, we'll need to make use of the WordPress filesystem, which is sometimes not available. To get through the review queue, themes also can't use file_get_contents which would make working with the json file easier.

So there should be a config option that allows us to convert the contributors file into a php file instead. Something along the lines of

return json_decode( 'JSON CONTENT', true );

That way we could just have $contributors = include get_template_directory() . '/contributors.php'; in our code, which is legal by the theme review guidelines.

We'd like to create a competition where we reward community contributions to theme projects. I know lines of code isn't the best measure of contributions, but it's a good way to test out this community contributions idea.

So the idea is to create a gulp task that goes along with the build script. The task should be configurable so that we can choose which files are part of the contribution calculation. This would allow us to remove things like 3rd party library files from the calculation.

We should also be able to add an array of ignored commits to the config array. This would allow us to do things like ignore an initial commit by adding its SHA to the array. Ignoring the initial commit would be useful, especially if we're just adding _s as the starting point.

Measuring Contributions

For this, it seems like git blame would work well. This gives fairly detailed output for each line of code in a file. We should also use something like gulp-strip-comments to remove comments and empty lines from the contribution calculation. Then we'd just need to match up the lines from git blame to the remaining lines from gulp-strip-comments.

Contribution Algorithm

At the most basic level, we could start by simply counting lines of code of contribution. It'd be ideal to take the following into account:

• Age of the contribution: Older contributions should count less. This would be to encourage continued contributions. Perhaps a half life of 1 year for a line of code's score would work.
• Complexity of the line: Not 100% sure on this, but maybe offering a slight score bump to a line of code based on how complex it is would work. For example, the line } should count a little less than a complex if statement.

Matching to Contributors Affiliate Codes

As a reward for contributing to the codebase, we'll use a contributor's affiliate code in the theme. We'll store a mapping of contributor emails from git, to their SiteOrigin affiliate ID in a file called contributors.txt in the root directory of the theme.

Full Name <[email protected], [email protected]> [aff_id]

It's possible that a single contributor might contribute from several Github emails, so we need to be able to handle a comma separated list of emails. It'll be up to the contributor to add their contributor information in their first PR.

Final Output

The task should then output a PHP file that returns an array where the key is the contributors affiliate ID and the value is their contribution score.

<?php
return array(
   'aff_user_1' => 0.5,
   'aff_user_2' => 0.25,
   /// etc.
)

The theme will then use this to add the affiliate ID to any links to the premium upgrade page. They would be assigned using a simple weighted random algorithm.

Hey @braamgenis. I can't seem to get the version number to print in style.css or style.min.css for the release task. Could you perhaps, take a look?

Add the Google fonts array updater to the release build process. FTW.

Version and js suffix constant replacement doesn't support spaces.

Correct WP PHP spacing would be:

define( 'SITEORIGIN_THEME_VERSION', 'dev' );
define( 'SITEORIGIN_THEME_JS_PREFIX', '' );

Currently, script supports:

define('SITEORIGIN_THEME_VERSION', 'dev');
define('SITEORIGIN_THEME_JS_PREFIX', '');

I'm working on a new branch that includes an about page in Vantage. The about page is being handled by the settings framework.

https://github.com/siteorigin/vantage/tree/feature/about-page

When I make a change to the about page settings, the build script in build:dev mode enters an infinite loop. Eventually it quits out with a segmentation fault error.

You just need to enter build:dev mode, then make a change to inc/settings/css/about.scss to trigger the error.

When using build:dev, it's possible that a SCSS error might come up while you're writing code. The issue is that this halts the Gulp script.

[18:24:39] Starting 'sass'...

events.js:141
      throw er; // Unhandled 'error' event
      ^
Error: sass/woocommerce/_archives.scss
Error: style declaration must contain a value
        on line 71 of sass/woocommerce/_archives.scss
>>                  pointer-events:;
   -------------------^

    at options.error (/Users/gpriday/Dropbox/Sites/dev/wp-content/themes/siteorigin-north/build/node_modules/gulp-sass/node_modules/node-sass/lib/index.js:277:32)

Ideally it should handle this error and continue running in the background. Maybe just displaying the error in the command line.