Is your enhancement related to a problem? Please describe.

We end up adding an SVG helper to every project, usually a variation of this template tag, and would benefit from a unified approach added the our theme scaffold.

While this helper function works 90% of the time, I think something to consider is that this approach uses file_get_contents for every icon on the page — which can end up in many calls. It also uses inline SVGs, which can be one of the best approaches in terms of performance, but for sites with large or unoptimized SVGs, it's by far the worst - https://cloudfour.com/thinks/svg-icon-stress-test/#breakdown-by-technique.

It's also important to consider how we're rendering icons in other contexts (JS template tags and the block editor). Ideally, we would have approach that can use the same SVGs in every context, so that we don't repeat ourselves.

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Is your enhancement related to a problem? Please describe.

Based on a recent Slack conversation: https://10up.slack.com/archives/G11CA43FW/p1643728684014569
@rdimascio and I believe it would be a great idea to include this boilerplate JavaScript code into frontend.js so that engineers can better work with dynamically imported JavaScript components:

import importAndRun from './util/import-and-run';

const COMPONENTS = {
	'components/accordion-block': {
		selectors: ['.accordion'],
	},
	'components/site-header': {
		selectors: ['body'],
	},
	'components/site-footer': {
		selectors: ['body'],
	},
	'components/story-navigation': {
		selectors: ['.home-nav'],
	},
	'components/service-explorer': {
		selectors: ['.service-explorer'],
	},
	'components/story-comments': {
		selectors: ['.story-comments'],
	},
	'components/social-share': {
		selectors: ['.social-share'],
	},
	'components/child-filters': {
		selectors: ['.photolisting__aside-filters'],
	},
	'components/cookie-consent': {
		selectors: ['#cookie-consent'],
	},
};

const initComponents = () => {
	Object.entries(COMPONENTS).forEach(([key, value]) => {
		importAndRun(key, value.selectors, value.callback);
	});
};

const init = () => {
	window.requestAnimationFrame(() => {
		document.body.classList.add('js-loaded');
	});

	initComponents();
};

/* eslint-disable-next-line @wordpress/no-global-event-listener */
document.addEventListener('DOMContentLoaded', init);

The above allows us to cleanly and easily keep track of components and import / run them as required.
This task would also require us adding the importAndRun utility to a new assets/js/util folder.

It's our hope that this will close the loop on dynamically imported JavaScript as the scaffold already supports Code Splitting out the box.

/**
 * Default callback when using `importAndRun`
 *
 * @param {Object} Module - Factory function or class
 */
const DEFAULT_CALLBACK = (Module) => {
	try {
		const module = new Module();
		module.init();
	} catch (error) {
		// Something failed
	}
};

/**
 * Dynamically import a module if it appears on the page.
 *
 * @param {string} module - Path to module
 * @param {string[]} selectors - List of selectors. Used to conditionally load the module
 * @param {Function} cb - Callback function to run after loading the module
 * @return {Promise} - Returns the dynamic import
 */
export default (module, selectors = ['body'], cb = DEFAULT_CALLBACK) => {
	let shouldImport = false;

	if (Array.isArray(selectors) && selectors.length) {
		shouldImport = Boolean(
			selectors.find((selector) => {
				return Boolean(document.querySelector(selector));
			}),
		);
	}

	if (!shouldImport) {
		Promise.resolve();
	}

	/* eslint-disable-next-line consistent-return */
	return import(`./../${module}`).then(({ default: module }) => {
		if (cb && typeof cb === 'function') {
			cb(module);
		}
	});
};

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

In my testing for the upcoming WordPress 6.0 release at the end of May I've found an issue with how we register blocks within the theme scaffold. In order to even be able to register bocks from within a theme, a workaround was added here:

This worked just fine with all the previous WordPress versions before 6.0 but with some underlying changes (I think this here: WordPress/wordpress-develop@f034bc8#diff-8c99af92e4ec0fdb307ddd9b42be1e1ef1efe4a9f31287c23f346244dddd1ce9R1210-R1246) the filter now breaks some core asset paths.

In order to resolve this issue we either need to somehow modify the filter we are adding to the plugins_url to only alter the path when the path is for the block we are trying to enqueue, and not for any paths.

Or we need to get WordPress core to allow for the inclusion of custom blocks from within themes.

Description
Live reloading works in the current setup, what does a full page refresh when there are CSS changes. The expected behavior, and what worked in the old scaffold, is that CSS changes would be injected without a page reload.

Steps to Reproduce

1. $ npm run watch
2. open localhost:300x
3. Make a css change, save the file
4. See the entire page refresh instead of the css being injected

WordPress 6.0 will likely include the new Webfonts API which will make it much easier to register and load custom fonts. This should be incorporated into the scaffold.

Is your enhancement related to a problem? Please describe.

Currently, the Theme Scaffold encourages the usage and definition of a custom block category to group all blocks into one place in the block inserter. This however is not a great editorial experience because the blocks should really be grouped by the actual categories or custom ones that have semantic meaning about the type of element they are.

For the purpose of also grouping blocks in a way to showcase that they were built as one collection, there is the registerBlockCollection API which allows for blocks to continue to have a semantic category and still shows them in a branded fashion in the inserter.

These two instances should be changed to point to semantics categories in order to lead with example:

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

The wp-scaffold is missing the husky + lint-staged setup which runs eslint and phpcs on every commit.,

I suggest adding that to the package.json at the root so that we have one set up linting both plugin and theme.

Related to #6 but plugin def should not have styleguide related files. These are for styleguide page template that is included within the theme. They are not even enqueued so no point to have this on the plugin.

For all of the files loaded here

$files = [
	'core.php',
	'overrides.php',
	'template-tags.php',
	'utility.php',
	'blocks.php',
];

foreach ( $files as $file ) {
	require_once MCONNECT_THEME_INC . $file;
}

Describe the bug

Steps to Reproduce
npm install
npm install -dev
npm run start

Expected behavior

CSS file not compiling and giving an error you can see the screeshot. It must be compile smothly.Screenshots

Environment information

• Device:
• OS: windows
• Browser and version:
• WordPress version:

• Plugins and version:
• Theme and version:

• Site Health Info:

Additional context

Adding block styles is an extremely common pattern out in the "wild". Block variations are becoming more common as well.

I think it would be valuable to outline structure for core block styles and variations in the new theme.

Perhaps these could live here:

/includes
	/blocks
		/core-blocks	
			/styles
			/variations
			/filters

I think block styles and variations have the same importance as the example-block we're enqueuing. It would be worth adding this structure to pave the way for showing people where to put these things, even if all of the code was commented out.

Describe the solution you'd like
Harry Roberts recently released a great little CSS utility that helps identify performance issues on sites called ct.css.
It is a diagnostic CSS stylesheet that looks something like this: https://csswizardry.com/ct/test/

This has a ton of benefits for adopting a performance culture at 10up where engineers can see with little effort what's being blocked or what can be optimized without adding to JS bloat.

My suggestion here would be to conditionally render ct.css behind a query string, say: ?debug_perf=1 which will trigger the stylesheets load.

The goal here is to quickly be able to diagnose what's blocking the rendering pipeline and solve it efficiently.

Great article at Smashing Magazine about this: https://www.smashingmagazine.com/2021/09/css-head-tag/

Is your enhancement related to a problem? Please describe.
As originally suggested in 10up/plugin-scaffold#100, we might want to consider adding the necessary files to deploy plugins to WP.org. Before I dig deeper into submitting a PR here, is that something that would be desired since this is mostly (only?) useful for publicly released plugins?

Describe the solution you'd like
Likely mimicking most of 10up/plugin-scaffold#104 here in https://github.com/10up/wp-scaffold.

Designs

Describe alternatives you've considered

Additional context
This sort of example boilerplate plugin info has been requested here as well: 10up/action-wordpress-plugin-deploy#11.

This is ment to be a tracking ticket for the different action items that will be needed in order to add support for theme.json in the Theme Scaffold.

The Dev Note on make.wordpress.org says that these are the sideeffects of just adding an empty theme.json file to a theme:

There are some features that are enabled or disabled when a theme has support for a theme.json file:

• The template editor is enabled.
• The default layout and margin styles for themes are not enqueued and the new layout options are enabled instead (see related dev note for layout).
• The inner div for the group block (wp-block-group__inner-container) is removed.
• The default font-family styles for the editor are not enqueued.

https://make.wordpress.org/core/2021/06/25/introducing-theme-json-in-wordpress-5-8/

Tasks:

• Add Theme Colors
• Add Theme Spacing
• Add Theme Fonts

Questions:

• If we follow the IE: This is the End and don't worry about IE11 we can also refactor the colors to use the ones that are enqueued from WordPress Automatically by using the `theme.json. A great article about that can be fund here: https://richtabor.com/standardizing-theme-json-colors/
• Do we want to enable the Block Templates (Template Part Editor) in the default scaffold
  ( can get removed by adding remove_theme_support( 'block-templates' ); in the after_theme_setup hook)
• Do we want to remove the DropCap option by default?

Describe the bug

The .gitkeep file https://github.com/10up/wp-scaffold/blob/trunk/mu-plugins/10up-plugin/includes/classes/.gitkeep contains PHP code.

Is this because:

• the PHP in this file was erroneously added to the existing .gitkeep file instead of creating a new .php file to contain it? In this case, the file should be renamed.
• the .gitignore file was created by copying an existing file elsewhere? In this case, the file should probably have the same contents as other .gitignore files in this repository.

Steps to Reproduce

View https://github.com/10up/wp-scaffold/blob/trunk/mu-plugins/10up-plugin/includes/classes/.gitkeep

Screenshots, screen recording, code snippet

No response

Environment information

No response

WordPress information

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Is your enhancement related to a problem? Please describe.

Enhancement: Add Tailwind v3 support to WP-Scaffold.

A utility-first CSS framework packed with classes like flex, pt-4, text-center and rotate-90 that can be composed to build any design, directly in your markup.

Read more about Tailwind: https://tailwindcss.com/

Note: Opt-in functionality is limited to checking out the epic/tailwind-v3 branch or downloading a zip as described in the PR below

PR

#156

Contributors

@Firestorm980 @Nikki-Jones @dainemawer @iansvo

Designs

No designs required

Code of Conduct

• I agree to follow this project's Code of Conduct

Is your enhancement related to a problem? Please describe.

[email protected] was just released, which upgrades a lot of packages and removes a lot of polyfill code required for IE11. Now that new projects are dropping IE11 support, we can safely upgrade our version in the scaffold. Will probably resolve #71

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Since WordPress 6.0 it is possible to register patterns by just placing a php file into the /patterns directory in the root of the theme. This approach should be adopted by the theme scaffold.

This Issue is meant to be used to track any changes in the upcoming WordPress 6.0 release that might impact the scaffold or how we build themes.

Related Issues:

• #102
• #100
• #99

Currently the scaffolded theme in the scaffold works well when the theme is used as a parent theme, but requires modification to work as a child theme. I'd like to propose we make some minor function changes in the theme to make sure it's ready to be used across a variety of types of themes.

The functions get_template_directory_uri() and get_template_directory() could be replaced with get_stylesheet_directory_uri() and get_stylesheet_directory() to work with child themes.

Is your enhancement related to a problem? Please describe.

Currently, WP Scaffold is used to bootstrap new projects at 10up. After the project is underway it can be useful to re-integrate updates to the scaffold. At the moment, such an update has to be done manually. Similarly it is difficult to pull bug fixes back into the project. Lastly, any new features that are added to the wp-scaffold are not readily available to projects started with an older version of wp-scaffold.

Designs

To address these issues I'm proposing a modular composer based approach outlined below.

1) wp-library composer package

The code inside the wp-scaffold would move to this wp-library repo. For MVP, This can be a GitHub repo with a composer.json. The wp-library would be imported into the wp-scaffold using configuration like this in the composer.json.

{
    "repositories": [
        {
            "url": "https://github.com/10up/wp-library",
            "type": "git"
        }
    ],
    "require": {
        "10up/wp-library": "~1.0.0"
    }
}

In the future we can publish a package to packagist to reduce this to a simpler require,

{
    "require": {
        "10up/wp-library": "~1.0.0"
    }
}

With this in place, projects using the wp-scaffold can upgrade to a newer 1.1.0 release by doing a composer update to that version of the wp-library.

{
    "require": {
        "10up/wp-library": "~1.1.0"
    }
}

2) Scaffold extends Theme

The wp-library would implement a Theme object that provides common functionality refactored from includes/core.php. In the wp-scaffold theme, we can extend the Theme in the wp-library.

class Theme extends \TenUp\Theme {

}

In a project with such a setup, The Theme class methods can be customized per the project requirements while retaining the parent wp-library functionality while still supporting upgrade paths.

class Theme extends \TenUp\Theme {

  public function js_detection() {
    parent::js_detection();

    // adds a has-notification class if the browser supports Web Notification API
    echo '<script type="javascript"> if (window.Notification ) { document.documentElement.className += 'has-notification'; } </script>'; 
  }

}

3) Theme Supports

Once we have a separate wp-library package we can let the wp-scaffolded projects determine what features should be enabled on the Theme using the add_theme_support api.

For instance, in the wp-library we could implement the above javascript detection behind a theme support condition like,

if ( get_theme_support( 'js_detection' ) ) {
  // do js detection here
}

And in the wp-scaffold theme, this can be managed with,

add_theme_support( 'js_detection' );

This approach combined with the composer.json versioning, allows us a lot of flexibility to add & improve features while maintaining backwards compatibility. For instance, if a new version of js_detection needs to be implemented in the same release it can be given a new theme support name.

After upgrading, projects can opt-in to the new release with something like,

add_theme_support( 'experimental_js_detection' );

4) Shared Features

By allowing projects to opt-in to the wp-library features we can introduce other shared features that are used across projects based on type, hosting provider etc.

Examples:

• Fieldmanager based Site Settings
• Newrelic profiling
• Yoast SEO Tuning
• Jetpack Tuning
• ElasticPress Tuning

5) Scaffold extends Plugin

Similarly the wp-library can provide shared functionality to custom plugins while maintaining an upgrade path for bug fixes and improvements.

class Plugin extends \TenUp\Plugin {

}

Describe alternatives you've considered

This approach requires a composer install step to pull in the wp-library dependency. This is something that is typically incorporated into a build step in Gitlab CI, Circle CI, etc. This approach may not be suitable for projects that don't use Continuous Integration.

Code of Conduct

• I agree to follow this project's Code of Conduct

Currently, the scaffold is very light on PHP structure. I think we want to move to more class based approaches. It would be great to get some code in place to start people in the right direction.

Is your enhancement related to a problem? Please describe.

We should use node v16 by default. Internal communications - https://10up.slack.com/archives/C105936H3/p1642701456049200

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Is your enhancement related to a problem? Please describe.

Provide enhancements to the scaffold to enable and manage features of the UI plugin

Examples may include:

• Establishing theme.json defaults
• Enabling php partials from plugin and passing attrs from the theme
• Managing any necessary settings
• Global branding controls and levers (as needed)
• Enabling / disabling sink or component QA/test pages
• Asset management control (css, js, etc - from theme or plugin)

Workflow

1. Pull down feature/101-ui-plugin-support-enhancements as epic branch
2. Merge trunk into feature/101-ui-plugin-support-enhancements to make sure it is up to date
3. Create feature branch off feature/101-ui-plugin-support-enhancements with feature/ui-plugin prefix (example: feature/ui-plugin-add-themejson)
4. Do work in branch and, when ready, push up create a PR against feature/101-ui-plugin-support-enhancements
5. Assign a reviewer
6. Once approved - merge PR into epic branch (feature/101-ui-plugin-support-enhancements)

Designs

N/A

Describe alternatives you've considered

N/A

Code of Conduct

• I agree to follow this project's Code of Conduct

Is your enhancement related to a problem? Please describe.
We have removed prop-types from @10up/eslint-config for WordPress. We should update it here as well.

Describe the solution you'd like
Remove from package.json and the related files in the example-block.

The theme.json mechanism in core allows developers to enable/disable settings like color settings etc. globally or per block.

What if we were to extend the theme.json mechanism to allow us to place our own custom values in it that enable our own custom settings to all blocks.

Two examples that come to mind for this are custom spacing controls or even animation options.

The issue with the core approach to margin is that it exposes raw CSS unit values to the end-user. These have the downsides of both being hard to understand if you are not a developer and not really being responsive.

A much better approach is allowing users to choose from a predefined list of the themes spacing scale. This solves both issues because it is easier to understand and also what the user chooses is not a raw value. So large spacing for example can mean something different on mobile compared to desktop viewports.

Technical Approach

The way this could be approached is by using theme.json to allow theme authors to provide their spacing values in a custom key that gets picked up from our extension of all blocks.

{
    "settings": {
        "spacing": {
            "steps": [
                {
                    "label": "Large",
                    "name: "large",
                    "value": "2rem"
                },
                // ...
            ]
        }
    }
}

From within a plugin, we could then read that setting and if it exists use the values from that key to populate a block extension that gets presented in the blocks inspector controls.

The benefit we get from doing it this way is we can already use the per block overwriting mechanism to change the values on a per block-level or remove the ability to change the spacing from a block altogether.

{
    "settings": {
        "spacing": {
            "steps": [
                {
                    "label": "Large",
                    "name: "large",
                    "value": "2rem"
                },
                // ...
            ]
        },
        "blocks": {
            "core/column": {
                "spacing": {
                   // remove the ability to change the spacing for the core column block
                   "steps": []
                }
            }
        }
    }
}

In our block extension we can use the useSetting hook to access the values of the spacing key like so:

function VerticalSpacingEditor(props) {

    const spacingValues = useSetting( 'spacing.steps' );

    // don't render the setting if the block doesn't provide spacing options
    if ( ! spacingValues.length ) {
        return null;
    }

    return (
        <InspectorControls>
            ...
        </InspectorControls>
    );
}

Is your enhancement related to a problem? Please describe.

One of the common repeatable tasks we face during theme development is the setup of UI components and the creation of supporting assets... partials, CSS, JS etc. Often this takes the form of copy/paste a previous similar example, strip it down and re-factor to our needs.

I believe it would be helpful to include a method to rapidly scaffold out these common assets in order to:

• Shave off the time this takes, whether from scratch or copy/paste/re-factor
• Avoid incremental deviations from intended patterns and copy/paste errors
• Provide a source of truth for intended patterns in the context of the longer term project lifecycle

In addition there is currently a drive to embrace the use of style guides as part of the engineering workflow. One common barrier to adoption seems to simply be time necessary to put these examples in-place, often seen as overhead. I believe we can extend an approach to rapid UI scaffolding to incorporate setup of the necessary style guide assets and examples.

On a recent project I've had success with this using PlopJS.
@brentvr and @joesnellpdx have expressed an interest in seeing how this could be integrated in the scaffold.
@rdimascio and @ian-pvd have also I believe been looking at similar approaches and expressed an interest.
To that end I've setup a PR (currently draft) #89 for review and further discussion.

This is not currently intended to include rapid scaffolding of blocks however, I would be keen to see how we could extend this perhaps as a subsequent issue.

Note: #79 could potentially benefit from the availability of this enhancement.

Designs

N/A

Describe alternatives you've considered

I have looked at alternatives to PlopJS however, I've not as yet found one that is as simple and easy to adopt at all experience levels.

One strong contender was Hygen however, Plop does provide a super useful menu to select a generator allowing for a single npm script and contextual menu, whereas Hygen relies on directly running individual generators.

Code of Conduct

• I agree to follow this project's Code of Conduct

Theme directory does not have a eslintignore at the moment. Plugin directory has one (/mu-plugins/10up-plugin/.eslintignore) so copy this one over to the theme?

Also, remove webpack.config.babel.js on /mu-plugins/10up-plugin/.eslintignore since it's no longer needed.

Screenshot of eslint showing errors for a third party file placed within vendor folder:

Is your enhancement related to a problem? Please describe.

Block patterns can consist of a lot of markup and it is rather difficult to manage that using the plain string of markup like it is currently done here:

Proposed Solution:

Create a "block-patterns" folder in the theme where PHP files for each pattern can be located. These files can then get included as the HTML string using a helper function.

block-patterns/buttons.php:

<!-- wp:buttons { "align": "center" } -->
<div class="wp-block-buttons aligncenter">
	<!-- wp:button { "backgroundColor": "very-dark-gray", "borderRadius": 0 } -->
	<div class="wp-block-button">
		<a class="wp-block-button__link has-background has-very-dark-gray-background-color no-border-radius">
			<?php echo esc_html__( 'Button One', 'my-plugin' ); ?>
		</a>
	</div>
	<!-- /wp:button -->
	<!-- wp:button { "textColor": "very-dark-gray", "borderRadius": 0, "className": "is-style-outline" } -->
	<div class="wp-block-button is-style-outline">
		<a class="wp-block-button__link has-text-color has-very-dark-gray-color no-border-radius">
			<?php echo esc_html__( 'Button Two', 'my-plugin' ); ?>
		</a>
	</div>
	<!-- /wp:button -->
</div>
<!-- /wp:buttons -->

blocks/register-paterns.php:

/**
 * Get Pattern Content.
 *
 * @param string $name Pattern name.
 * @return string
 */
function get_pattern_content( $name ) {
     $path    = "block-patterns/{$name}.php";
     if ( file_exists( $path ) ) {
         ob_start();
         require $path;
         return ob_get_clean();
     }
}

register_block_pattern(
    'my-plugin/my-awesome-pattern',
    array(
        'title'       => __( 'Two buttons', 'my-plugin' ),
        'description' => _x( 'Two horizontal buttons, the left button is filled in, and the right button is outlined.', 'Block pattern description', 'my-plugin' ),
        'content'     => get_pattern_content( 'buttons' );
    )
); 

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

One thing I've noticed again and again over the past few years is that the default values in the manifest.json file don't get changed. Most sites don't require it and don't get built as PWA's at this point. And since more browsers started using the theme_color for styling bits of their UI this can lead to unfortunate visuals.

iOS	macOS

If used correctly the theme_color is very useful. But currently, I think that it more often gets "forgotten" and stays with the default value which is creating a bad experience.

Enable automated performance monitoring in the scaffold

One option is to utilize Perfume.js, but others should be explored.

Perfume.js tutorial

Alternatives? - needs exploration

WordPress Core automatically enqueues frontend assets like the viewScript only on pages where the block is actively being used for static blocks. Dynamic blocks currently need to handle that step manually.

Proposed Solution:

Since WordPress already registers all the assets we can add a check whether an asset exists and then automatically enqueue it from within the render_callback function.

By default, there are no Jest tests for the example-block. To encourage testing, I want to add some basic tests for the React components that are used to make the block. I am mainly adding snapshot tests, as those will be useful immediately on the project and will be easy to update.

I am working on a PR, but ran into #26

Plugin is bloated with theme specific files that should be removed. For example, both the theme and plugin are adding normalize which means that out of the box, 10up WP Scaffold will load normalize two times on a site. This should only be included within the theme.

Describe the bug

Since most WordPress projects will have multiple plugins, running phpcs . from the wp-content directory will run out of memeory.

Steps to Reproduce

1. Install a few plugins
2. Run composer run lint
3. See error when it runs out of memory

Code of Conduct

• I agree to follow this project's Code of Conduct

Is your enhancement related to a problem? Please describe.

Script loading in WordPress really sucks. We have a few options available to us:

1. We can place scripts in the <head>
2. We can place scripts before the </body>
3. We can use the filter script_loader_tag to append async and defer onto scripts.

None of the options above, considering the WP ecosystem really has a huge effect on performance.
I would like to suggest that we build our own function which sits on top of wp_enqueue_script, very much like NextJS handles their next/script component: https://nextjs.org/docs/api-reference/next/script

In NextJS scripts can apply "strategies":

(from web.dev)
The strategy attribute can take three values.

• beforeInteractive: This option may be used for critical scripts that should execute before the page becomes interactive. Next.js ensures that such scripts are injected into the initial HTML on the server and executed before other self-bundled JavaScript. Consent management, bot detection scripts, or helper libraries required to render critical content are good candidates for this strategy.

• afterInteractive: This is the default strategy applied and is equivalent to loading a script with the defer attribute. It should be used for scripts that the browser can run after the page is interactive—for example, analytics scripts. Next.js injects these scripts on the client-side, and they run after the page is hydrated. Thus, unless otherwise specified, all third-party scripts defined using the Script component are deferred by Next.js, thereby providing a strong default.

• lazyOnload: This option may be used to lazy-load low-priority scripts when the browser is idle. The functionality provided by such scripts is not required immediately after the page becomes interactive—for example, chat or social media plug-ins.

As WP is not prerendered, beforeInteractive is null and void.

We can however leverage afterInteractive and lazyOnLoad as described above, afterInteractive is effectively the equivalent of using defer. What I would like to see is an option for lazyOnLoad which loads scripts when the browsers main thread is idle using requestIdleCallback - MDN. For browsers that do no support requestIdleCallback there is a shim available.

There is currently limited support in Safari for this functionality, but otherwise great support across the web.
Id envision a function like:

tenup_add_script( $handle = 'component', $filename = 'file-name', $ver = '1.0.0', $strategy = 'lazyOnLoad' );

I think a proof of concept could be worthwhile testing out to see how far we could get but would love to see something in action!

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

For both theme and plugin, there are admin-style.css and editor-style.css. Do we need both? If we do need to make admin/editor specific style updates, which file we do we update?

1. /wp-content/themes/10up-theme/assets/css/admin/admin-style.css
2. /wp-content/themes/10up-theme/assets/css/frontend/editor-style.css
3. /wp-content/mu-plugins/10up-plugin/assets/css/admin/admin-style.css
4. /wp-content/mu-plugins/10up-plugin/assets/css/admin/editor-style.css

If we do remove one, I vote to remove editor-style to stay consistent with JS folder/file name (wp-content/mu-plugins/10up-plugin/assets/js/admin/admin.js).

Is your enhancement related to a problem? Please describe.

The scaffold style guide provides a section displaying the CSS colour palette setup in [them]/assets/css/frontend/global/colors.css. This currently only supports the use of HEX values.

We are more and more commonly adopting alternate colour formats.
Therefore extending the style guide to incorporate these will ensure continued adoption and reduce the overhead of adding this on a per-project basis.

For now I believe it best to focus on

• HEX
• RGB(A)
• HSL(A)

I have setup a PR for the proposed approach #91

Designs

N/A

Describe alternatives you've considered

N/A

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe the bug
JS within the theme isn't enqueued with its automatically generated dependencies or version. This is due to the path being passed into Utility\get_asset_info() is incorrect.

The Utility\get_asset_info() function uses the following path TENUP_THEME_PATH . 'dist/' . $slug . '.asset.php'. Note that this doesn't include the js or css directory, which is where the assets are actually located.

We should instead enqueue scripts like this:

wp_enqueue_script(
	'frontend',
	TENUP_THEME_TEMPLATE_URL . '/dist/js/frontend.js',
	Utility\get_asset_info( 'js/frontend', 'dependencies' ),
	Utility\get_asset_info( 'js/frontend', 'version' ),
	true
);

and CSS like this:

wp_enqueue_style(
	'styles',
	TENUP_THEME_TEMPLATE_URL . '/dist/css/style.css',
	[],
	Utility\get_asset_info( 'css/style', 'version' )
);

Steps to Reproduce

1. Add the below code to the theme frontend.js file.
2. Visit a page and check the console
3. See undefined is logged.
4. Check JS file in dev tools and see no version added.

import apiFetch from '@wordpress/api-fetch';

console.log(apiFetch);

Expected behavior
The apiFetch object is logged

Is your enhancement related to a problem? Please describe.

Most of the sites we build require common markup elements like header, main area, footer, and a "skip to main content" link. We can provide this markup in the scaffold. Following structure worked well for me on previous projects and I don't recall a case when I needed something completely different:

<!DOCTYPE html>
<html <?php language_attributes(); ?> class="no-js">
  <head>
    <meta charset="<?php bloginfo( 'charset' ); ?>" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <?php wp_head(); ?>
  </head>

  <body <?php body_class(); ?>>
    <?php wp_body_open(); ?>
    <div id="page" class="site">
      <header id="masthead" class="site__header site-header">
        <div class="site-header__inner">
          <a class="site-header__skip-link visually-hidden" href="#primary"><?php esc_html_e( 'Skip to content', 'textdomain' ); ?></a>
          <h1><?php bloginfo( 'name' ); ?></h1>
        </div>
      </header>

      <main id="primary" class="site__main site-main">
        <?php if ( have_posts() ) : ?>
          <?php while ( have_posts() ) : the_post(); ?>
            <h2><?php the_title(); ?></h1>
          <?php endwhile; ?>
        <?php endif; ?>
      </main>

      <footer id="colophon" class="site__footer site-footer">
        <div class="site-footer__inner">
          <!-- Footer content goes here -->
        </div>
      </footer>
  </div>
  <?php wp_footer(); ?>
  </body>
</html>

This is a combined markup from header.php, index|page|post.php, and footer.php.

It is design agnostic but gives flexibility in terms of styling the header and footer position they way we want. Here's a quick CSS example of how to make a layout with a sticky header and footer at the bottom (regardless of the amount of content):

html,
body {
	height: 100%;
	width: 100%;
}

body {
	padding-top: var(--h-header);

	&.admin-bar {
		padding-top: calc(var(--h-header) + var(--h-admin-bar));

		@media (--wp-medium) {
			padding-top: calc(var(--h-header) + var(--h-admin-bar-medium));
		}
	}
}

.site {
	display: flex;
	flex-direction: column;
	min-height: 100%;
	width: 100%;
}

.site__header {
	height: var(--h-header);
	left: 0;
	position: fixed;
	top: 0;
	width: 100%;
	z-index: 1;

	@nest .admin-bar & {
		top: var(--h-admin-bar);

		@media (--wp-medium) {
			top: var(--h-admin-bar-medium);
		}
	}
}

.site__main {
	flex-basis: auto;
	flex-grow: 1;
	flex-shrink: 0;
}

.site__footer {
	flex-shrink: 0;
	height: var(--h-header);
	width: 100%;
}

Adding default CSS is a bigger discussion though. I'm not suggesting adding this snippet as part of this issue.

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

This repo is throwing deprecation warnings when used with WordPress 5.8 due to incorrect structure in the block.json file for the Example Block.

Steps to Reproduce

1. Set WP_DEBUG to true in wp-config.php
2. Go to wp-admin on to see warnings

Expected behavior
Should not see any errors when WP_DEBUG is set to true

Environment information

• WordPress version: 5.8

Dark mode is a display options for many.
Currently, we most often leave it alone and avoid intentionally adding inentional dark mode styles.

Per this article, Google may be auto enabling an applying a dark mode theme to sites.

There are a few options to explore:

• Intentionally disable dark mode with this: <meta name="color-scheme" content="only light">
• Add guidance and starter css for enabling dark mode with intentionally set custom properties
• Actually apply a dark mode theme by default - with guidance on how to customize / modify as needed
• If we add a dark mode option, should we add / provide guidance for toggling on or off by the user?

Is your enhancement related to a problem? Please describe.

• Ensure only intended blocks are enabled from a commonly used list of blocks
• Ensure this pattern if followed on projects going forward to prevent new core blocks from being enabled without passing engineering (styling, functionality)

Describe the solution you'd like
Allowed blocks list enabled

Describe the bug

When using the npm run test command, from the root of the repo or the root of the theme, I get errors like this and the tests fail:

[BABEL] /home/josh/wp-scaffold/themes/10up-theme/includes/blocks/example-block/test.test.js: Unknown option: .wordpress. Check out https://babeljs.io/docs/en/babel-core/#options for more information about options.
    - Maybe you meant to use
    "preset": [
      ["@10up/babel-preset-default", {
      "wordpress": true
    }]
    ]
    To be a valid preset, its name and options should be wrapped in a pair of brackets

      at throwUnknownError (node_modules/@babel/core/lib/config/validation/options.js:131:27)
      at node_modules/@babel/core/lib/config/validation/options.js:116:5
          at Array.forEach (<anonymous>)
      at validateNested (node_modules/@babel/core/lib/config/validation/options.js:92:21)
      at validate (node_modules/@babel/core/lib/config/validation/options.js:83:10)
      at node_modules/@babel/core/lib/config/full.js:320:36
      at cachedFunction (node_modules/@babel/core/lib/config/caching.js:52:27)
          at cachedFunction.next (<anonymous>)
      at evaluateSync (node_modules/gensync/index.js:251:28)
      at sync (node_modules/gensync/index.js:89:14)

Steps to Reproduce

1. Download wp-scaffold
2. Add "themes/10up-theme/includes/blocks/example-block/test.test.js"
3. Add any test to that dir test( 'something', ()=> { expect(1).toBe(1);
4. See error
5. Run npm run test from the theme's directory.
6. Add a test to the mu-plugin
7. See two of the same error

Environment information

• Device: Window Laptop
• OS: Windows 10 Pro with WSL/2. Issue is happening with Ubuntu 20.04.2 LTS
• Tested with Node 12 and Node 14.
• NPM 6.14.11

On package.json (https://github.com/10up/wp-scaffold/blob/trunk/themes/10up-theme/package.json#L27), there is a blocks entry (includes/blocks/blocks.js) but this does not exists on the includes folder. Unless I'm missing something, this entry should be removed or file is missing.

Maybe instead of needing to add index.js for each custom block on package.json like on https://github.com/10up/wp-scaffold/blob/trunk/themes/10up-theme/package.json#L36, have includes/blocks/blocks.js that imports them all so that package.json doesn't need to be updated every time a custom block is added?

Is your enhancement related to a problem? Please describe.

Currently, the way to add a new block is rather cumbersome. You have to first create a new JS entry point in the package.json file like so:

{
  "10up-toolkit": {
    "entry": {
      "example-block": "./includes/blocks/example-block/index.js"
    }
  }
}

Next you have to require the PHP file like so:

require_once TENUP_THEME_BLOCK_DIR . '/example-block/register.php';

// Call block register functions for each block.
Example\register();

Describe the solution you'd like

I think both of these steps could be skipped if we are able to automatically create an entry point for every folder inside the blocks directory and also use autoloader to load all the PHP register.php files inside the individual block folders.

Is your enhancement related to a problem? Please describe.
Menus output as widgets are wrapped in div and are not ADA compliant.
With WordPress 5.5 this has been fixed. It outputs a nav element, and has aria-labels included.
To use it, it must be added as a theme support.
Currently navigation-widgets is not there.

https://make.wordpress.org/core/2020/07/09/accessibility-improvements-to-widgets-outputting-lists-of-links-in-5-5/

In core.php, by adding the following changes we can make sure the menu is output with aria-labels and uses a nav element instead of a div element.

add_theme_support(
		'html5',
		array(
			'search-form',
			'gallery',
			'navigation-widgets'
		)
	);

Would create a nav element in sidebar with aria attributes:

Describe the solution you'd like

Add it!

With build scripts now coming from 10up-scripts, should we include webpack.config.js on root directory for both the theme and plugin? Just about every project requires some sort of updates to build script and I think this would be helpful. Maybe include a file with the following code commented out?

const defaultConfig = require('@10up/scripts/config/webpack.config');
module.exports = {
	...defaultConfig,
	myObject: {
        stuffHere: true
    }
};

I def think this is a file that every project will need.

The filter block_categories is deprecated as of WP 5.8.0 in favor of block_categories_all

Steps to Reproduce

1. Install Block Library plugin and activate
2. Activate all blocks with filter in README
3. set WP_DEBUG to true
4. Create a new post
5. Expected behavior
6. Expected to only see the editor.

Describe the bug

Saw the editor along with deprecation warning messages in the admin nav menu

Expected behavior

Should not see any warnings when WP_DEBUG is set to true

Environment information

• WordPress version: 5.8

Describe the bug

Running npm i && npm run build on a fresh install throws eslint errors in the example block.

Steps to Reproduce

1. Clone the repo
2. Run npm i in root folder
3. Run npm run build in root folder

Screenshots, screen recording, code snippet

➜  wp-scaffold git:(trunk) npm i
npm WARN deprecated [email protected]: The functionality that this package provided is now in @npmcli/arborist
npm WARN deprecated [email protected]: this library is no longer supported
npm WARN deprecated [email protected]: Please upgrade  to version 7 or higher.  Older versions may use Math.random() in certain circumstances, which is known to be problematic.  See https://v8.dev/blog/math-random for details.
npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142

> [email protected] prepare
> lerna bootstrap --hoist && husky install

lerna notice cli v4.0.0
lerna info versioning independent
lerna info Bootstrapping 2 packages
lerna info Installing external dependencies
lerna info hoist Installing hoisted dependencies into root
lerna info hoist Pruning hoisted dependencies
lerna info hoist Finished pruning hoisted dependencies
lerna info hoist Finished bootstrapping root
lerna info Symlinking packages and binaries
lerna success Bootstrapped 2 packages
husky - Git hooks installed

added 652 packages, and audited 653 packages in 1m

80 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
➜  wp-scaffold git:(trunk) ✗ npm run build

> [email protected] build
> lerna run build --stream

lerna notice cli v4.0.0
lerna info versioning independent
lerna info Executing command in 2 packages: "npm run build"
tenup-plugin: > [email protected] build
tenup-plugin: > 10up-toolkit build
tenup-theme: > [email protected] build
tenup-theme: > 10up-toolkit build
tenup-plugin: ℹ Compiling Webpack
tenup-theme: ℹ Compiling Webpack
tenup-plugin: ✔ Webpack: Compiled successfully in 9.91s
tenup-plugin: assets by path js/ 432 bytes
tenup-plugin:   assets by path js/*.php 432 bytes 4 assets
tenup-plugin:   assets by path js/*.js 0 bytes
tenup-plugin:     asset js/admin.js 0 bytes [emitted] [minimized] (name: admin)
tenup-plugin:     asset js/frontend.js 0 bytes [emitted] [minimized] (name: frontend)
tenup-plugin:     asset js/shared.js 0 bytes [emitted] [minimized] (name: shared)
tenup-plugin: assets by path css/ 229 bytes
tenup-plugin:   assets by path css/*.css 39 bytes 3 assets
tenup-plugin:   assets by path css/*.php 190 bytes
tenup-plugin:     asset css/admin-style.asset.php 95 bytes [emitted]
tenup-plugin:     asset css/style.asset.php 95 bytes [emitted]
tenup-plugin: assets by path images/*.png 10.6 KiB
tenup-plugin:   asset images/icon-512.png 6.75 KiB [emitted] [from: assets/images/icon-512.png] [copied]
tenup-plugin:   asset images/icon-192.png 2.33 KiB [emitted] [from: assets/images/icon-192.png] [copied]
tenup-plugin:   asset images/icon-128.png 1.54 KiB [emitted] [from: assets/images/icon-128.png] [copied]
tenup-plugin: javascript modules 240 bytes
tenup-plugin:   modules by path ./assets/js/ 90 bytes
tenup-plugin:     ./assets/js/admin/admin.js 26 bytes [built] [code generated]
tenup-plugin:     ./assets/js/frontend/frontend.js 38 bytes [built] [code generated]
tenup-plugin:     ./assets/js/shared/shared.js 26 bytes [built] [code generated]
tenup-plugin:   modules by path ./assets/css/ 150 bytes
tenup-plugin:     ./assets/css/admin/admin-style.css 50 bytes [built] [code generated]
tenup-plugin:     ./assets/css/shared/shared-style.css 50 bytes [built] [code generated]
tenup-plugin:     ./assets/css/frontend/style.css 50 bytes [built] [code generated]
tenup-plugin: css modules 36 bytes
tenup-plugin:   css ../../node_modules/css-loader/dist/cjs.js??ruleSet[1].rules[2].use[1]!../../node_modules/postcss-loader/dist/cjs.js??ruleSet[1].rules[2].use[2]!./assets/css/admin/admin-style.css 0 bytes [built] [code generated]
tenup-plugin:   css ../../node_modules/css-loader/dist/cjs.js??ruleSet[1].rules[2].use[1]!../../node_modules/postcss-loader/dist/cjs.js??ruleSet[1].rules[2].use[2]!./assets/css/shared/shared-style.css 0 bytes [built] [code generated]
tenup-plugin:   css ../../node_modules/css-loader/dist/cjs.js??ruleSet[1].rules[2].use[1]!../../node_modules/postcss-loader/dist/cjs.js??ruleSet[1].rules[2].use[2]!./assets/css/frontend/style.css 36 bytes [built] [code generated]
tenup-plugin: webpack 5.66.0 compiled successfully in 9915 ms
tenup-theme: ✔ Webpack: Compiled successfully in 10.92s
tenup-theme: assets by path js/ 18.7 KiB
tenup-theme:   assets by path js/*.php 756 bytes 7 assets
tenup-theme:   assets by path js/*.js 18 KiB 5 assets
tenup-theme: assets by path css/ 5.03 KiB
tenup-theme:   assets by path css/*.css 4.75 KiB 5 assets
tenup-theme:   assets by path css/*.php 285 bytes 3 assets
tenup-theme: assets by path images/*.png 10.6 KiB
tenup-theme:   asset images/icon-512.png 6.75 KiB [emitted] [from: assets/images/icon-512.png] [copied]
tenup-theme:   asset images/icon-192.png 2.33 KiB [emitted] [from: assets/images/icon-192.png] [copied]
tenup-theme:   asset images/icon-128.png 1.54 KiB [emitted] [from: assets/images/icon-128.png] [copied]
tenup-theme: assets by path blocks/example-block/ 7.41 KiB
tenup-theme:   asset blocks/example-block/editor.js 7.25 KiB [emitted] [minimized] (name: example-block)
tenup-theme:   asset blocks/example-block/editor.asset.php 165 bytes [emitted] (name: example-block)
tenup-theme: orphan modules 7.01 KiB [orphan] 8 modules
tenup-theme: runtime modules 442 bytes 2 modules
tenup-theme: modules by path ../../node_modules/core-js/internals/*.js 43.4 KiB 77 modules
tenup-theme: modules by path ./ 8.22 KiB (javascript) 4.75 KiB (css/mini-extract)
tenup-theme:   javascript modules 8.22 KiB
tenup-theme:     modules by path ./assets/ 5.14 KiB 9 modules
tenup-theme:     modules by path ./includes/ 3.08 KiB 2 modules
tenup-theme:   css modules 4.75 KiB
tenup-theme:     modules by path ./assets/css/frontend/*.css 2.25 KiB 2 modules
tenup-theme:     3 modules
tenup-theme: modules by path ../../node_modules/core-js/modules/*.js 4.57 KiB
tenup-theme:   ../../node_modules/core-js/modules/es.function.name.js 886 bytes [built] [code generated]
tenup-theme:   ../../node_modules/core-js/modules/es.object.to-string.js 380 bytes [built] [code generated]
tenup-theme:   ../../node_modules/core-js/modules/web.dom-collections.for-each.js 887 bytes [built] [code generated]
tenup-theme:   ../../node_modules/core-js/modules/es.array.concat.js 2.47 KiB [built] [code generated]
tenup-theme: WARNING in
tenup-theme: /Users/ryan/10up/wp-scaffold/themes/10up-theme/includes/blocks/example-block/edit.js
tenup-theme:   24:3  error  Expected indentation of 2 space characters but found 0  react/jsx-indent
tenup-theme:   25:4  error  Expected indentation of 2 space characters but found 0  react/jsx-indent
tenup-theme:   26:5  error  Expected indentation of 2 space characters but found 0  react/jsx-indent-props
tenup-theme:   27:5  error  Expected indentation of 2 space characters but found 0  react/jsx-indent-props
tenup-theme:   28:5  error  Expected indentation of 2 space characters but found 0  react/jsx-indent-props
tenup-theme:   29:5  error  Expected indentation of 2 space characters but found 0  react/jsx-indent-props
tenup-theme:   30:5  error  Expected indentation of 2 space characters but found 0  react/jsx-indent-props
tenup-theme: ✖ 7 problems (7 errors, 0 warnings)
tenup-theme:   7 errors and 0 warnings potentially fixable with the `--fix` option.
tenup-theme:
tenup-theme: webpack 5.66.0 compiled with 1 warning in 10924 ms
lerna success run Ran npm script 'build' in 2 packages in 14.9s:
lerna success - tenup-plugin
lerna success - tenup-theme

Environment information

• MacBook
• [email protected]

WordPress information

No response

Code of Conduct

• I agree to follow this project's Code of Conduct