Now that Gutenberg supports registering color palettes how could we integrate this into the build system too?

We could add colors to a json file and use something like this: https://github.com/Updater/node-sass-json-importer (thanks @m-e-h).

That way colors would only need updating in one place.

https://github.com/justintadlock/mythic/blob/master/resources/scss/utilities/_alignment.scss#L52
calc( doesn't get closed )

viewBox should not be removed when running npm run build. viewBox is needed for consistent styling.

Just leaving the notice here, debug later.

Just opening this topic to keep a running list of tutorial ideas on things related to Mythic, which includes Hybrid Core and other add-ons.

• Full tutorial on using Hybrid Breadcrumbs. (Tutorial)
• Full tutorial on using Hybrid Carbon. (Tutorial)
• Registering custom widgets the Mythic/OOP way. (Tutorial)
• Cover using the build scripts in more depth.
• Working with the Mythic\Customize\Customize class.
• Using the hybrid-customize project.

Leave other ideas below.

I was trying to add before_page_number to pagination like this:

posts_pagination( [
	'prev_text'          => __( '← Previous', 'uuups' ),
	'next_text'          => __( 'Next →', 'uuups' ),
	'title_text'         => __( 'Posts Navigation', 'uuups' ),
	'container_class'    => 'pagination pagination--posts',
	'title_class'        => 'pagination__title screen-reader-text',
	'before_page_number' => '<span class="meta-nav screen-reader-text">' . __( 'Page', 'uuups' ) . ' </span>',
] );

But it outputs:

<li class="pagination__item pagination__item--number"><a href="http://foxland-products.local/page/2/" class="pagination__anchor pagination__anchor--link">&lt;span class="meta-nav screen-reader-text"&gt;Page </a></li>

I'm not sure where the escaping function kicks in for <span.

It's not in the theme yet, but we need to have Gutenberg block styles ready to go out of the box.

Folder

A resources/styles/blocks folder is going to be in the theme. That's a definite. Everything else below is what we need to figure out.

Files

We could populate the blocks folder with a simple _index.scss for theme authors to get started with a completely blank slate. Or, we could add the files right off the bat.

Here's a look at most (not sure if I've got all yet) blocks and a proposed file naming system for core blocks:

/blocks
	/_wp-block-button.scss
	/_wp-block-categories.scss
	/_wp-block-code.scss
	/_wp-block-columns.scss
	/_wp-block-cover-image.scss
	/_wp-block-embed.scss
	/_wp-block-file.scss
	/_wp-block-gallery.scss
	/_wp-block-image.scss
	/_wp-block-latest-posts.scss
	/_wp-block-preformatted.scss
	/_wp-block-pullquote.scss
	/_wp-block-quote.scss
	/_wp-block-separator.scss
	/_wp-block-subhead.scss
	/_wp-block-table.scss
	/_wp-block-verse.scss

Default styles

Do we include default styles for Gutenberg? These could just be copy-pasted, essentially, from core as a base.

Mythic is 100% designed with the idea that theme authors will be building Gutenberg-ready themes. The question is how far we want to go. We have to balance between getting in the theme author's way and getting them off on the right foot.

In app/functions-assets.php, I have the code for disabling Gutenberg's default styles. This is commented out right now. Whether we uncomment will be largely dependent on whether we package any default styles.

add_action( 'enqueue_block_editor_assets', function() {

	wp_enqueue_style( 'mythic-editor', asset( 'styles/editor.css' ), null, null );

	// Unregister core block and theme styles.
	// wp_deregister_style( 'wp-core-blocks' );
	// wp_deregister_style( 'wp-core-blocks-theme' );

	// Re-register core block and theme styles when empty string. This is
	// necessary to get styles set up correctly.
	// wp_register_style( 'wp-core-blocks', '' );
	// wp_register_style( 'wp-core-blocks-theme', '' );

}, 5 );

Example:

<?php posts_pagination( [
	'prev_text'       => __( '&larr; Previous' ),
	'next_text'       => __( 'Next &rarr;' ),
	'title_text'      => __( 'Posts Navigation' ),
	'container_class' => 'pagination pagination--posts',
	'title_class'     => 'pagination__title screen-reader-text'
] ) ?>

I think here are the reason why it's recommended to remove php closing tag from the end of the file, and sniff includes it.

The first command run when generating a new theme from Mythic is the following:

composer create-project justintadlock/mythic 

The post-create-project-cmd event is executed after that command has run. We should explore using this event to do a complete setup of the theme.

More info: https://getcomposer.org/doc/articles/scripts.md

mythic_compat_message() doesn't cover the case when WP and PHP versions don't meet the requirements. I think it would be friendlier to show a message to upgrade WP and PHP and not have to go through this twice.

I'm fairly certain, we'll be using npm-scripts at this point rather than something like Gulp or Grunt. I'm also fairly certain we'll default to handling SCSS or similar syntax.

The following is a rundown of some of the CSS-related build scripts that we might utilize. These were copied over from our Slack channel discussion.

What we need to do is come up with a solid set of scripts that would be useful in most theme projects.

Working with the styles:

• https://github.com/postcss/postcss-scss
• https://github.com/ai/browserslist
• https://github.com/jonathantneal/postcss-preset-env
• https://github.com/postcss/autoprefixer
• https://github.com/MoOx/postcss-cssnext
• https://github.com/stylelint/stylelint

Working with the files (probably some crossover with JS files):

• https://github.com/jonschlinkert/copy
• https://github.com/sindresorhus/del-cli
• https://github.com/isaacs/rimraf

Most of these should already be covered by the utilities/alignment.scss styles.

https://github.com/justintadlock/mythic/blob/master/resources/scss/blocks/core/_cover-image.scss#L56-L60

https://github.com/justintadlock/mythic/blob/master/resources/scss/blocks/core/_gallery.scss#L19-L23

https://github.com/justintadlock/mythic/blob/master/resources/scss/blocks/core/_image.scss#L17-L20

https://github.com/justintadlock/mythic/blob/master/resources/scss/blocks/core/_latest-posts.scss#L11-L17

https://github.com/justintadlock/mythic/blob/master/resources/scss/blocks/core/_pullquote.scss#L13-L16

Thus far, we've experimented with various build systems and are currently using Webpack. It's the big player in town and is something that's likely going to be used by many people who are building custom Gutenberg blocks.

With that said, we need to decide what's right for this theme.

And, I fully expect there to be forks of this theme with build systems that are suited to individual theme authors. However, I want to have a good base for the majority of theme authors who might not want to delve into all that and just needs something that works.

Defining our needs for assets

The biggest thing we've lacked is a list of actually what our needs are as theme authors to guide us each step along the way. How can we know which tools are needed if we don't clearly define what we're trying to accomplish?

CSS

CSS is the primary asset type in building WP themes. I think we have a pretty clear picture of what we want to do:

• Write in Sass and/or next-generation CSS. transpiling
• Bundle smaller files into one final file. bundling
• Our code checked for errors. linting

JS

• Write in modern JS and have it work cross-browser. transpiling
• Bundle smaller files into one final file. bundling
• Our code checked for errors. linting

Images and SVGs

• Have these files cleaned up and minimized for performance.

How the process should work

The underlying tools (whether it be Webpack, Gulp, Grunt, or something else) shouldn't really matter to theme authors. The theme should define some npm-scripts commands that handle that.

For me, personally, I feel like I want the following things:

// Build everything.
npm run build

// Build only scripts|styles|images|svgs
npm run build:*

// Lint scripts|styles
npm run *:lint

// Watch
npm run watch

// Watch scripts|styles
npm run watch:*

That's a bit of a hierarchy. build handles everything below it and so on.

For those that do want to or must edit

We'll have a base of standard things. However, theme authors will inevitably need to edit something in the build process. That should be simple and not require you to jump through any hoops.

For example, if a theme author needs to add a new stylesheet to be compiled separately, they shouldn't have to import that into something else. They should have a "config" file to define it (or have it done automatically). Same thing with JS files.

That means having a clear organizational structure (I like where we're at right now with this) and having clear docs (we'll get those).

Travis helps test and deploy code. It can run tests we specify by adding .travis.yml file. I especially find it useful when doing PRs for other projects. This is also related to PHP sniffs in #7.

Couple of examples:

• In _s.
• In Foxer a little modified version of that.

Bundling the theme for distribution is probably the last script we need. It should be triggered from the command line like so:

npm run bundle

It should create a new folder in the theme named mythic (theme name) or simply bundle. The idea is that theme authors would want the theme prepared for distribution with only the files that need to be uploaded to the site.

The following should be included:

- changelog.md      (not in the repo yet)
- functions.php
- index.php
- license.md
- readme.md
- screenshot.png
- style.css

- /app
- /dist
- /resources
	- /lang
	- /scripts      (WordPress.org-only)
	- /styles       (WordPress.org-only)
	- /views
- /vendor

WordPress.org requires the original script/style files when minifying them. So, we'll want to have something commented out that theme authors can uncomment for those particular directories.

Wepack config

We could probably do a webpack.config.bundle.js file for this to keep it separate.

Or, if someone knows how to integrate this into the webpack.mix.js and pass in a custom variable from the scripts line in package.json, that'd work. Need something like:

if ( bundle ) {
	mix.copy()...
}

This should be pretty basic. We just need to let theme authors edit what files they might want to include and copy them all over with the bundle command.

@justintadlock

I love the direction this theme is going. I realize it is under very active development right now, but do you have an idea of when you think it would be stable enough for production use?

I'd like to take my first stab at developing with the "hybrid suite" and I'm not sure what direction to go in terms of the starter themes you've developed.

Thanks so much!

Core have added aria-current="page" to pagination but I'm not seeing that in abc/HC.

I initially decided upon Laravel Mix because it was something that most of our primary group of devs agreed upon as a solid solution. It didn't have everything that everyone wanted, but it had enough for us to compromise and close out months of discussion over a build system. This was one of the biggest hurdles for even getting Mythic launched.

While Mix does everything I personally need at the moment, I believe moving to a Webpack-only solution would be beneficial in the long run because it would help developers become more familiar with the underlying technology. Mix is a layer on top of Webpack, which can sometimes hide what's going on. In some cases, that can make it harder to do things.

And, we're still waiting for Mix to catch up with the latest improvements (particularly speed improvements) in newer versions of Webpack.

I'm not convinced we need to change right away. However, I do want to open this ticket so that we can explore this option for version 2.0 or so. Or, at the very least, have some examples for others who want to go down that path for themselves in the meantime.

Right now, I'd love to see others' Webpack-only implementations.

In version 5.0 of Hybrid Core, we no longer provide stylesheets. Therefore, we're missing the default styles for smileys and emojis.

Here's a look at the core styles that HC removes. We need to provide these (minus all the !important bits) in /resources/scss/utilities.

img.wp-smiley,
img.emoji {
    display: inline !important;
    border: none !important;
    box-shadow: none !important;
    height: 1em !important;
    width: 1em !important;
    margin: 0 .07em !important;
    vertical-align: -0.1em !important;
    background: none !important;
    padding: 0 !important;
}

Project code should be checked using PHPCS. In most cases there should be custom phpcs.xml for creating custom ruleset good for project.

Couple of examples:

• phpcs.xml file in _s.
• A little modified version of that.

This way we can also check PHP compatibility for different versions.

In my opinion starter theme should support up coming editor, code name Gutenberg. For me support means:

• Theme support for align-wide.
• Theme support for editor-color-palette.
• Dequeue Core block styles from front-end.
• Adding styles for blocks that needs it. For example <hr>, <tables>, and <blockquote> already have styles.
• Enqueue block related styles back to editor.
• Trying to have system that allows easily adding styles for custom blocks (from public or private plugins).

For organising SASS/CSS I'm thinking that there should be blocks.css imported automatically from SASS files. Then this file can be enqueued in the editor.

blocks.css could have:

• All html elements like <table>, <hr> etc.
• Typography.
• All wp-block-* related styles like for wp-block-button.

These styles might need to be wrapped inside .edit-post-visual-editorclass but this can change.

Current markup: <div class="app-header__description"><?php bloginfo( 'description' ) ?></div>.

Should we roll a template function for this so that description is only shown when there is one. Similar to Underscores.

I was thinking template function if we wan't to avoid if else as much as possible in template files.

I noticed that the /utilities/__a11y.scss file is not (yet?) imported in screen.scss.

Would it also be an idea to add some basic styles to it for .screen-reader-text?
https://rianrietveld.com/2015/04/04/the-screen-reader-text-class-why-and-how/

I see you are using new architectual approaches. What are your reasons behind them? Are you going to elaborate on them somewhere/sometime?

I'm enthousiastic to see this in a WordPress theme and I'm curious to learn more about it. It's good to see some evolvement in theme development.

Because we decided that adding baseline Gutenberg styles into theme was a good idea, we also need to take care of some baseline width, margin, padding, size, and similar values.

For example, take this code from resources/scss/blocks/core/_cover-image.scss:

.wp-block-cover-image-text {
	color:         color( white );
	font-size:     2em;
	line-height:   1.25;
	z-index:       1;
	margin-bottom: 0;
	max-width:     content-width();
	padding:       14px;
	text-align:    center;

	a,
	a:hover,
	a:focus,
	a:active {
		color: color( white );
	}
}

As you can see, the content-width() function will return the theme's content width. However, we should take that further and allow theme authors to plug in other numeric values in /resources/scss/settings. The font-size, line-height and padding values from above could all be replaced with settings.

To do this, we'd need to identify all the places that could use such treatment and establish some standards on how to best handle that.

We could even explore existing packages/libraries that are out there.

When running the rename command, the Mythic namespace is replaced with the theme's new namespace in composer.json. This means that composer dump-autoload needs to be called to regenerate the autoload files.

I've added this extra step to the installation docs.

One proposed solution was to change the rename script in package.json to this:

"scripts": {
	"rename": "theme-claim && composer dump-autoload"
}

My worry with this is that on some setups the composer command is composer.phar.

Perhaps we should just leave it be and keep this in the installation docs. Opening this ticket for discussion.

It seems to be mis-aligned compared to the other blocks, and git confirms when diffing.

After today, WordPress.org will start requiring a readme.txt for themes submitted to the directory. This is for, with any luck, the theme directory behaving a little more like the plugin directory at some point in the future.

Mythic itself mostly tries to be .ORG-compliant with a couple of notable exceptions.

If we do add it, we'll want to build out a basic outline to get theme authors started. If we don't add it, we should note it in the docs.

I don't feel particularly strongly either way about it. I could see it being a nuisance if the majority of folks using Mythic aren't submitting to the directory and end up deleting the file.

This is not priority but would be nice to have a setup script. It would ask your

• theme name.
• theme slug.
• dev URL.

After setup have run, you have a ready to go theme without manually doing any search and replace. One example of setup.sh file.

Sage also have setup process when building from composer. That's another example.

When using CSS variables in Mythic .scss files, the var() declaration is being output twice. I narrowed this down to PostCSS. I wasn't able to alter the behavior via PostCSS config in the mix file.

At Marty's suggestion, I updated the required version of postcss-preset-env in the Mythic package.json file as follows:

"postcss-preset-env": "^6.4.0"

This fixed the issue of duplicate declarations in the CSS output, and should be the default.

Small typo in entry__foooter with triple o.

Everywhere, but particularly with file paths https://github.com/justintadlock/abc/blob/master/resources/build/config.js#L28-L36

Some of these files may not exist on the export https://github.com/justintadlock/mythic/blob/master/webpack.mix.export.js#L23-L31.
I'm getting
Error: ENOENT: no such file or directory, stat '/home/marty/vagrant-local/www/wordpress-default/public_html/wp-content/themes/forsite/readme.md'
cause I'm using the generated README.md from github.

.gitattributesfile still have styles and scripts folder reference.

One thing I've been considering is adding an _index.scss file to each of the subfolders under /resources/styles.

For example, a /components/_index.scss would import all of the other .scss files from /components. Then, in /resources/styles/screen.scss (or elsewhere), we could simply import them all with one line of code:

@import 'components/index';

Anyone see any potential downsides to this? Or, alternative solutions?

Edit: This could potentially be an __index.scss (double underscore) file too to put it at the top of the file list.

At the moment, we're using render() to mean "output" html and fetch() to mean "return" html. Opening this up for discussion for alternatives.

Intentional, or...?

SVG system may or may not be good fit for this project. If you ask me, it is:) I can't remember the last time when SVGs wasn't involved in a project.

What SVG system can mean:

• get_svg() function or similar to injecting SVG icon markup in the template files.
• Social menu links using SVG icons.
• Build tools that minify SVG icons into single SVG sprite file.
• Example file in Foxer.

Now that version 0.1.0 of the WPThemeReview project has been tagged, it's time to start discussing adding this to Mythic.

The goal has always been for this to be the default standards shipped with the theme. The timing just wasn't there when we shipped 1.0.0 of Mythic.

They have instructions to follow, so this should be fairly straightforward: https://github.com/WPTRT/WPThemeReview#installing-wpthemereview-as-a-project-dependency

We have a couple of options:

1. Install this as a dependency (as well as dealerdirect/phpcodesniffer-composer-installer, which is required).
2. Create a separate coding standards repository/package, which can be managed separately.

It'll probably be better to start with option #1 and move to option #2 if things evolve.

Skip to content link is missing from the header/default.php. Ideally it should actually be inside landmark region because all content should be inside a landmark.

I have it inside <header> at the moment. It could be inside it's own <nav> also.

More info about skip links. If you ask me, I'm OK for dropping Javascript for IE11.

I personally use only one h1 per page, it keeps headings hierarchy simple. And is current good practise for HTML5 and accessibility.

Once again I Underscores method is what I recommend. This could also be template function to avoid if else in template files, see also issue #16.

I think it would be nice to add browsersync proxy option into npm run rename or to some other install instruction. Currently it's hardcoded inside webpack.mix.js file as localhost. But usually developers has different local domain for projects

Also I didn't understand why changing css and js files from dist folder has been omitted in browsersync file extensions. Maybe it has some reason?

Adding .editorconfig helps developers define and maintain consistent coding styles between different editors and IDEs.

• More info about editorconfig.
• Plugins for editors.

One example of .editorconfig file, probably needs fine tuning.

To make simpler to change the resources/ directory, we should probably use a variable so it only needs changed in one location.
Finding and replacing resources/ is error prone because that name also exists here vendor/justintadlock/hybrid-core/src/resources/

Found some lonely "double quotes" here https://github.com/justintadlock/abc/blob/master/webpack.mix.js#L149-L151
Also causes problems when doing a find and replace. Should make those consistent.

We have already talked about how crucial good SASS structure is. It's the foundation where big projects can also build upon without losing mind.

Suggested methods are ITCSS and BEM. There is already basic folder structure for it.

Next step is to figure out what to put in which folders. I'll try to work on this and write more ideas this week.

Couple of references:

• InuitCSS.
• Discussion in Underscores, but we need to blow up the SASS/CSS anyways. I would not look much into that.

Value prop: it's one of the main tools of keeping bundle size down. Official Google recommendation https://developers.google.com/web/fundamentals/performance/webpack/monitor-and-analyze#analyze_why_the_bundle_is_so_large

https://github.com/FormidableLabs/webpack-dashboard/

Things like npm run dev turn into node_modules/.bin/webpack-dashboard -- npm run dev

It immediately found bundle duplicates for me.

Just adding this for reminder. Text domain is missing from strings: __( 'Next →' ).

We need to add support for the media-text block: https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src/media-text

Also see: WordPress/gutenberg#9416

This was recently added to Gutenberg, so we need to roll out support.

So not too offend videos, -image was removed from all the class selectors related to the "cover" block.
Now it's just .wp-block-cover and .wp-block-cover-text.

Adding Sass docs might help getting overall picture of used mixins, functions and variables.

Example in Foxer starter theme.