xwp / block-scaffolding-wp Goto Github PK

If you run npm run docker -- npm install from the container then you will get an error when composer tries to run.

npm WARN lifecycle @xwp/[email protected]~postinstall: cannot run in wd @xwp/[email protected] composer install (wd=/var/www/html/wp-content/plugins/block-scaffolding-wp)

Basically, NPM tries to downgrade its privileges when it runs scripts. So you have to actually run it like so:

npm run docker -- npm install --unsafe-perm

To reproduce:

1. clone repo
2. npm install
3. vagrant up
4. npm run build
5. Log in and see that plugin is visible and can be activated
6. vagrant halt
7. vagrant up
8. Login and see that plugin is missing
9. npm run build - plugin is still missing

Convert the logic in init.sh into a Composer PHP script that would allow us to simplify the setup down to a single command of composer create-project xwp/block-scaffolding-wp.

The bundled Vagrant and Docker environments are a nice addition.

But there have been a few candidates that needed support with the environments. For example, one reported that they could not find the wp-content/ directory in the Vagrant environment.

Also, vagrant up failed for me with:

The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

 setup

Stdout from the command:

Stderr from the command:

bash: line 4: setup: command not found

These issues might all have solutions.

But I think candidates could be distracted in setting up the environments. I've used this plugin in my own VVV environment fine.

Or instead of removing the bundled environment, maybe:

diff --git a/readme.md b/readme.md
index 154e632..411f1c9 100644
--- a/readme.md
+++ b/readme.md
@@ -19,12 +19,14 @@
 
           npm install
 
-3. Start a virtual testing environment using [Vagrant](https://www.vagrantup.com/) and [VirtualBox](https://www.virtualbox.org/):
+3. If you need a WordPress development environment, start one using [Vagrant](https://www.vagrantup.com/) and [VirtualBox](https://www.virtualbox.org/):
 
           vagrant up
 
        which will be available at [blockextend.local](http://blockextend.local) after provisioning (username: `admin`, password: `password`).
 
+       This is optional, and this plugin should still run in a typical WordPress development environment.
+
        Alternatively, run it on your local Docker host:

Currently you cannot upload media to the container.

We should add the jsx-a11y eslint plugin to ensure our blocks have a solid accessible foundation.

If you're open to considering changing the name of this repo, that could help it be more appropriate for back-end related tasks.

block-extend was perfect for the front-end task of extending a block. But it probably won't apply to back-end tasks, which probably won't involve extending a block.

It might involve creating a dynamic block. Of course, that's partly front-end as well 😄

Maybe:

• block-scaffold
• block-starter

• Add instructions to the readme for how to use Xdebug for debugging the plugin code.
• Maybe include .vscode/launch.json with the defaults for VS Code users.

Would you be open to a PR that adds GitHub actions?

Maybe like this, it could have actions for linting, Jest tests, and PHPUnit tests.

If you're up for it, I'll open the PR.

Thanks!

What do you think about removing the Dockerfile and Vagrantfile?

Most recent candidates have had problems with them.

They usually lose 1-2 days debugging them (though probably not working the whole day on them 😄 ).

The files might be fine. Environments are just hard to set up, and sometimes the candidates don't see errors when they fail.

My instructions for the project say the bundled environments are optional, but almost everyone tries to use the Dockerfile or Vagrantfile.

Most candidates probably have their own WP environment.

Sorry to keep opening issues to this repo, just thinking of how to speed up the trial projects.

The Node and NPM versions are not compatible for the Debian version used from the base image. The Dockerfile needs to be updated to install NPM differently so they are compatible. So installing via apt-get nodejs npm will not work correctly. Instead we can remove the npm and install using https://www.npmjs.com/install.sh.

FROM wordpress:php7.3-apache

# Development tooling dependencies
RUN apt-get update \
	&& apt-get install -y --no-install-recommends \
		bash less default-mysql-client git \
		nodejs curl \
		msmtp \
	&& rm -rf /var/lib/apt/lists/*

RUN curl https://www.npmjs.com/install.sh | sh \
	&& curl -s https://getcomposer.org/installer | php \
	&& mv composer.phar /usr/local/bin/composer

# Include our custom config for PHP and Xdebug.
COPY config/php/* /usr/local/etc/php/conf.d/

# Setup xdebug.
RUN pecl install xdebug; \
	docker-php-ext-enable xdebug;

The following line throws a fatal error in PHP 7.4+:

As can be seen in the documentation for get_file_data(), the second argument $default_headers is not optional and has to be provided.

Add a project description to the readme that explains what the repository is currently and what it hopes to be when it grows up.

• Use Jest.
• Add test coverage reporting. Probably bundle with the existing reporting on Coveralls.

We're currently using the default WordPress docker image for running the WordPress environment and thecodingmachine/php:7.3-v3-fpm-node8 for things that require Composer and Node. Switching to a single container would simplify the commands and ensure parity between the environment running WordPress and the one running tests, etc.

This issue provides visibility into Renovate updates and their statuses. Learn more

Rate Limited

These updates are currently rate limited. Click on a checkbox below to force their creation now.

• Update dependency dealerdirect/phpcodesniffer-composer-installer to v0.7.2
• Update dependency composer/installers to v2

Other Branches

These updates are pending. To force PRs open, click the checkbox below.

• Update dependency handlebars to 4.7.7 [SECURITY]
• Update dependency ua-parser-js to 0.7.23 [SECURITY]

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update dependency async to 2.6.4 [SECURITY]
• Update dependency glob-parent to 5.1.2 [SECURITY]
• Update dependency jsdom to 16.5.0 [SECURITY]
• Update dependency merge-deep to 3.0.3 [SECURITY]
• Update dependency moment to 2.29.2 [SECURITY]
• Update dependency path-parse to 1.0.7 [SECURITY]
• Update dependency shell-quote to 1.7.3 [SECURITY]
• Update dependency tmpl to 1.0.5 [SECURITY]
• Update dependency trim to 0.0.3 [SECURITY]
• Update dependency trim-newlines to 3.0.1 [SECURITY]
• Update dependency phpcompatibility/phpcompatibility-wp to v2.1.3
• Update dependency phpunit/phpunit to v8.5.27
• Update dependency mockery/mockery to v1.5.0
• Update dependency php-coveralls/php-coveralls to v2.5.2
• Update wordpress monorepo (@wordpress/block-editor, @wordpress/scripts)
• Update dependency mysql to v8
• Update wordpress monorepo (major) (@wordpress/block-editor, @wordpress/eslint-plugin, @wordpress/scripts)
• Click on this checkbox to rebase all open PRs at once

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

• Update dependency phpunit/phpunit to v9

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Replace the dummy add() function test with something relevant.

Because $plugin->asset_version() defaults to $plugin->version() (which pulls from $plugin->meta()), any usage of $plugin->asset_version() outside of the WordPress Admin will fail. This is caused by the usage of get_plugin_data() function (which is only available within the admin).

It makes sense to be able to reuse $plugin->asset_version() for non-admin scripts and styles; as such, one of these methods need to be extended to default to a version if no other versions are found.

In addition, the $plugin->meta() method needs to check for is_admin() or function_exists( 'get_plugin_data' ) before checking the plugin data.

Use /local as the canonical directory for storing everything that is not part of the actual plugin code such as tooling, Docker config, etc. We could end up with something like:

• /local/scripts for all Composer/Node scripts used for scaffolding and deploys.
• /local/public for mounting the root directory of the WordPress development environment.
• /local/docker for containing any Docker overrides and customizations.

WordPress plugins hosted on WP.org should support PHP versions down to 5.6 while most of the enterprise projects can rely on PHP 7+ being present. We need to figure out how to account for both of these scenarios.