Add starter child theme WPCS compliant

[ThierryA]

Here is the first commit with the child theme WPCS compliant as well as the Travis and Dev Lib setup.

[hellofromtonya]

I'm not a fan of using closures as the hooked callback. Why?

Our code provides an example of how to build code. And in some cases a closure is fine. But in most others it is not because it cannot be unhooked.

Here, one could argue that this callback will never be unhooked. But in many other cases, you may build a plugin that needs to unhook another part of your theme. If you use a closure, that is no longer possible, well unless we use beans_add_action.

Choices:

Option 1

Use the standard function as the callback.

add_action( 'beans_uikit_enqueue_scripts', __NAMESPACE__ . '\enqueue_uikit' );
/**
 * Enqueue LESS and CSS style to the UIkit compiler.
 *
 * IMPORTANT: The function below enqueue both the style.less and style.css to the UIkit compiler. Remove one of the
 * two enqueuer according to your needs
 *
 * To make sure the compiler re-compile your LESS or CSS on the fly (on page reload), make sure to enable development
 * mode via the Admin->Appearance->Settings option.
 */
function enqueue_uikit() {

Option 2

Use beans_add_action() with the closure, thereby, giving the ability for a plugin to modify or remove the closure.

/**
 * Enqueue LESS and CSS style to the UIkit compiler.
 *
 * IMPORTANT: The function below enqueue both the style.less and style.css to the UIkit compiler. Remove one of the
 * two enqueuer according to your needs
 *
 * To make sure the compiler re-compile your LESS or CSS on the fly (on page reload), make sure to enable development
 * mode via the Admin->Appearance->Settings option.
 */
beans_add_action( 'beans_child_enqueue_uikit', 'beans_uikit_enqueue_scripts', function() {

[ThierryA]

The thinking behind is that Child Theme are not meant to be extendable to a certain extent, but I am definitely in a agreement that it can be the case sometimes. I think using beans_add_action() is a good showcase of how closure can safely be used with Beans.

[hellofromtonya]

Why call get_stylesheet_directory_uri() twice? It's more performant to store it in a variable and then use that variable, like this:

	$uri = get_stylesheet_directory_uri();

	// To remove if you are using style.css only.
	beans_compiler_add_fragment( 'uikit', $uri . '/style.less', 'less' );

	// To remove if you are using style.less only.
	wp_enqueue_style( 'child-style', $uri . '/style.css' );

[ThierryA]

Because one of the too calls below are meant to be removed. Either users choose LESS or CSS but not enqueue both. Then users will most likely leave the function assigned to the variable unnecessary.

[hellofromtonya]

@ThierryA We should rename this repository to the name of the child theme, i.e. tm-beans-child. Why? In doing so, people can download or clone the repository without having to rename the folder.

[hellofromtonya]

I'd suggest that we set up this composer.json with the same dependencies and scripts as in Beans. It would then give a developer the environment, s/he needs to start building a theme and writing tests.

We could think of the child theme as the starting development environment for a new theme.

[ThierryA]

@ThierryA We should rename this repository to the name of the child theme, i.e. tm-beans-child. Why? In doing so, people can download or clone the repository without having to rename the folder.

Because we plan on removing to tm- prefix on Beans and while we can automate the process as much as possible upon update on the framework, there is no update on the child theme so users would have to do it manually. Unlike plugins, child theme folder order doesn't matter so I think we are good to go. I renamed the repo to beans-child.

[ThierryA]

The Integration Tests setup needs a bit more work on this one since Beans parent theme has to be installed on travis 😞