wp-cli / scaffold-command Goto Github PK
View Code? Open in Web Editor NEWGenerates code for post types, taxonomies, blocks, plugins, child themes, etc.
License: MIT License
Generates code for post types, taxonomies, blocks, plugins, child themes, etc.
License: MIT License
So, I just used wp scaffold plugin
for the first time and I was very impressed ๐
I took a look at the addtextdomain
task and gave it a try. The result though was pretty confusing - I already had textdomains defined in most of my i18n
functions and what I saw in the diff was that the textdomain of my plugin was just tacked onto the end of the __()
call for instance.
I went on a search through the cedaro/grunt-wp-i18n repository and found out that some time ago they added a configuration option that allows you to replace all textdomains with the one specified in the addtextdomain.options.textdomain
config.
Is it just me or is it a bit pointless to have addtextdomain
only append the textdomain instead of having it replace any existing textdomains? This technically means that unless you package your plugin separately and always keep your working copy without textdomains you can only run grunt i18n
once, otherwise you'll end up with an ever growing list of textdomains.
So, I think it would make sense to adjust the auto-generated Gruntfile.js
so that addtextdomain.target
config is replaced with this:
update_all_domains: {
options: {
updateDomains: true
},
src: [ '*.php', '**/*.php', '!node_modules/**', '!php-tests/**', '!bin/**' ]
}
On https://developer.wordpress.org/cli/commands/scaffold/taxonomy/, the docs display <
and >
instead of the respective glyphs:
--theme
and --plugin
should probably have identical formatting with regards to whether the =<name>
is included inside the square brackets.
We should look into setting Behat up so that it can generate code through the scaffolding command and then runs that generated code through linters/sniffers to make sure that the end result adheres to all standards and best practices.
From #109 (comment)
Block scaffolding exists via #88 and I think the current default is a sensible default, but a lot of us will need modern tooling. @ahmadawais has already built what a ESNext + Webpack option would need here:
https://github.com/ahmadawais/Gutenberg-Boilerplate/tree/master/block/02-basic-esnext
I can imagine that as opinions develop in the community about how to build blocks, this is likely to be come a templating system for different block types and workflows. So I'd like to propose a --template
option.
When this option is false, which would be its default, then the current behaviour would happen. I also propose that one template esnext-webpack
be created, based on Ahmad's boilerplate, to act as a reference implementation and also because there is an immediate need for it.
I think to make this happen the following would need to be done:
template
argument to command, and add a template loader.Adding the p
argument to phpcs.xml.dist
allows progress to be shown when invoking phpcs
, which gives confidence to the user that something is happening.
Change:
<!-- Show sniff codes in all reports -->
<arg value="s"/>
to:
<!-- Show progress and sniff codes in all reports -->
<arg value="ps"/>
The scaffold generated when CircleCI is chosen is a CircleCI 1.0 config file. Can this be updated for CircleCI 2.0? I'm a Developer Evangelist over at CircleCI and I can assist if needed.
Thanks.
So first time user of the wp scaffold block
and I got a little confused by the readme. I assumed it would just make a block for me where ever I ran it. It took me a minute to figure out that a block has to belong to a plugin or theme, which makes a lot of sense, not questioning that. Just saying the documentation confused me. PR incoming.
As the work on the new WordPress editor progresses, we thought that it would be great to simplify Gutenberg on-boarding process for plugin developers. It is still being discussed how native Gutenberg extensibility would look like, but we are confident that the most common use case will be that developers will want to create new blocks. We discussed it a bit already and it seems like the best way to start is to create a scaffolding command which creates a block registered into the editor that needs to have only logic updated. It would be great to have it included in the core of wp-cli
.
On the technical side, the only thing that is necessary to create a plugin that registers a new block is to provide two files similar to what @pento shared here:
https://gist.github.com/pento/19b35d621709042fc899e394a9387a54
Please note that this code doesn't use build step (no Webpack, Babel, etc.). It's only PHP and JavaScript code that will work out of the box. JS uses ES5 syntax that can run on every browser including IE11. It's a conscious decision to provide a default starter kit that produces code be approachable for developers coming from all possible backgrounds.
Side note: This sample code is a more advanced use case which uses post meta
, which we can omit in the initial implementation.
We want to support also developers that want to use more advanced JavaScript tooling and we are happy to discuss how to provide more advanced tooling that would be enabled on demand things like:
It also raises the question if wp-cli
would be able to install all dependencies listed in package.json
and execute the build step behind the scenes.
We can also trigger a wider discussion if we want to move that tooling to a separate npm package to make them easier to reuse. I have also shared a blog post where I explain more in-depth advantages of starter kits and reusable scripts in the context of WordPress and Gutenberg.
I already asked this question on Slack, but let me rephrase and ask again here. What do you think about the following flow for new developers:
wp scaffold plugin gutenberg
(or something like that) using ssh to do it on the server the gutenberg plugin is being used on./wp-admin/plugin-editor.php
page to edit the new plugin directly in the code editor bundled with WP and implements save
and edit
JavaScript methods for a newly bootstraped Gutenblock.Would it be possible to wrap wp-cli
command with the interface exposed in Gutenberg, and create a new plugin that registers a block behind the scenes by filling in a form that mirrors CLI options?
Files generated by wp scaffold command are not WordPress coding standard compliant!
For example cpt generated:
As mentioned in https://github.com/wp-cli/scaffold-command/pull/96/files#r164610714 the JS i18n functions do not except the second argument for the text domain. https://github.com/WordPress/gutenberg/blob/master/i18n/index.js#L42
There does not seem to be a way to define the text domain at the moment. WordPress/gutenberg#4147
In install-wp-tests.sh
the tags
directory of the core test suite is used. For example, calling install-wp-tests.sh <name> <user> <pass> <host> 4.7
results in the tags/4.7
directory of the test suite being checked out.
Ref:
scaffold-command/templates/install-wp-tests.sh
Lines 26 to 27 in 8015b66
The disadvantage of this is that any fixes which get made to the test infrastructure in branch point releases don't get picked up by the test install script. For example, specifying a WordPress version of 4.7 checks out the test suite for 4.7, but doesn't include the recent changes in 4.7.1 - 4.7.5.
In my User Switching plugin I changed install-wp-tests.sh
so it uses the branch instead of the tag when a two-digit WordPress version number is specified.
if [[ $WP_VERSION =~ [0-9]+\.[0-9]+ ]]; then
WP_TESTS_TAG="branches/$WP_VERSION"
elif [[ $WP_VERSION =~ [0-9]+\.[0-9]+\.[0-9]+ ]]; then
WP_TESTS_TAG="tags/$WP_VERSION"
This means the test suite includes changes which have been backported to the 4.7 branch. The notable fix that was backported recently was support for PHPUnit 6+ which caused breakage all over the place.
Does it make sense to change the install-wp-tests.sh
template to use this pattern?
From https://travis-ci.org/wp-cli/automated-tests/jobs/267261114
Introduced in #37 but it was only revealed now because I tagged a release.
When making integration tests one may need additional plugins.
Pasting here my install-wp-tests-plugins.sh
#!/usr/bin/env bash
if (( $# < 1 )); then
echo "usage: $0 <plugin[:version]> [plugin[:version]]..."
exit 1
fi
let force=0
WP_CORE_DIR=${WP_CORE_DIR-/tmp/wordpress/}
download() {
if [ `which curl` ]; then
curl -s "$1" > "$2";
elif [ `which wget` ]; then
wget -nv -O "$2" "$1"
fi
}
set -ex
install_plugins() {
if [ ! -d $WP_CORE_DIR ]; then
return;
fi
for PLUGIN in "$@"; do
if [[ -d "$WP_CORE_DIR/wp-content/plugins/${PLUGIN%:*}" ]] && (( ! $force )); then
continue;
fi
[[ $x =~ : ]] && VERSION="${PLUGIN##*:}"
FILENAME="${PLUGIN%:*}.${VERSION:-latest-stable}"
download "https://downloads.wordpress.org/plugin/$FILENAME.zip" "$WP_CORE_DIR/wp-content/plugins/$FILENAME.zip"
unzip -q "$WP_CORE_DIR/wp-content/plugins/$FILENAME.zip" -d "$WP_CORE_DIR/wp-content/plugins/"
done
}
install_plugins "$@"
NB:
--force
wp-cli
itself, composer.json
, ...)Hello,
Today I tried using scaffold to create a block for gutenberg, I was using the --theme option. What me and my colleague found out is that the wp cli still implements plugin_url instead of something for the theme, and we have the following fix for it;
In code of the block e.g. 'blocks/my-custom-block.php'
Instead of:
$dir = dirname( __FILE__ );
Use:
$dir = get_template_directory() . '/blocks';
And instead of:
plugins_url( $block_js, __FILE__ ),
Use:
get_template_directory_uri() . "/blocks/$block_js",
The only thing you have to do next is go to your functions.php in the theme and paste this:
require( get_template_directory() . '/blocks/my-custom-block.php' );
I hope this helps some people out!
I am not sure if this belongs here - it looks like the wp scaffold plugin-tests
command still exists in the main WP-CLI repo and that this package isn't officially available using wp package install
. I assume that all future development will be happening here?
In any case - I have just started to take advantage of the wp scaffold plugin-tests
command (super convenient, thanks for that) and I noticed that the PHPCS command run by travis fails by default. The problem is that PHPCS is run against the tests dir and the SampleTest
class with a filename of test-sample.php
violates the naming conventions defined in the WordPress coding standards.
This isn't a huge deal since the sample test will likely be deleted or renamed right away, but I assume users will follow the same conventions as WP-CLI and therefore continue to run into this issue.
Would it be beneficial to make some changes here?
A couple of possibilities:
phpcs.ruleset.xml
to exclude the tests directory entirely. This would be my preference and is what I am doing personally since my tests tend to stray from the WordPress standards in at least a few ways.WordPress.Files.FileName.InvalidClassFileName
is the rule needed to address this issue. Some other good candidates (in my opinion) would be Squiz.Commenting.FileComment.Missing
, Squiz.Commenting.ClassComment.Missing
and Squiz.Commenting.FunctionComment.Missing
.SampleTest
class to Sample_Test
, moving test-sample.php
to class-sample-test.php
and changing the PHPUnit testsuite definition to drop the test-
prefix and update the suffix to -test.php
.The following labels are missing from the output of wp scaffold taxonomy <slug>
:
items_list
items_list_navigation
no_terms
view_item
In addition, WordPress 4.9 will add:
back_to_items
most_used
Something I noticed while checking the history for #77...
The reason for the .xml.dist
extension for the phpunit config (per da9167d, presumably holds for phpcs as well):
Naming the file
phpunit.xml.dist
instead ofphpunit.xml
is considered a best practice because it allows other developers working on a project to override the configuration without messing with extra command line parameters or dirtying their local version control state.See http://www.testically.org/2010/08/24/best-practice-how-to-ship-phpunit-configuration/
First, that linked site no longer appears to be active - here is an archived copy: http://web.archive.org/web/20160317185523/http://www.testically.org:80/2010/08/24/best-practice-how-to-ship-phpunit-configuration/
Second (and the point of this issue), part of the recommendation from that post is to add phpunit.xml
to .gitignore
to keep git status clean/prevent it from being accidentally committed.
So would it be beneficial for the standard configs to be added to the plugin-gitignore.mustache
template?
Adding a composer.json
template would encourage developers to make their plugins available via Packagist, and also allow local install of dependencies.
Currently, WPCS + PHPCS is made available via a global composer install here for Travis.
I haven't yet found a template for the plugin's composer.json
, but adding WPCS + PHPCS + PHPCompatibility + DealerDirect/phpcodesniffer-composer-installer
to a composer.json
would make PHPCS runnable from local, without Travis.
Hello,
I got this error on every plugin i try to wrap with tests
I use: wp scaffold plugin-tests some-plugin
and I'm getting error when I'm trying to run sh script:
bin/install-wp-tests.sh: 26: bin/install-wp-tests.sh: Syntax error: "(" unexpected (expecting "then")
lines from 26 to 30 looks like this
if [[ $WP_VERSION =~ [0-9]+.[0-9]+(.[0-9]+)? ]]; then
WP_TESTS_TAG="tags/$WP_VERSION"
elif [[ $WP_VERSION == 'nightly' || $WP_VERSION == 'trunk' ]]; then
WP_TESTS_TAG="trunk"
else
I'm on ubuntu 16.
Hello there,
I have submitted a pull request on sample-plugin to add tests on multiple PHP versions on circleci
wp-cli/sample-plugin#8
It also sets the phpunit version to 5.7.* to fix the error:
PHP Fatal error: Class 'PHPUnit_Framework_TestCase' not found
For more info on this issue, see https://core.trac.wordpress.org/ticket/39822
Thanks,
Carlos
Any thoughts on adding support for Bitbucket Pipelines to [--ci=<provider>]
?
bitbucket-pipelines.yml
# This is a sample build configuration for PHP.
# Check our guides at https://confluence.atlassian.com/x/e8YWN for more examples.
# Only use spaces to indent your .yml configuration.
# -----
# You can specify a custom docker image from Docker Hub as your build environment.
image: phpunit/phpunit:5.0.3
pipelines:
default:
- step:
script: # Modify the commands below to build your repository.
- composer install
Previously: #55
If the server's display_errors
directive is set to Off
and the user tries to run their unit tests without first running bash bin/install-wp-tests.sh ...
, they'll be greeted with blank output.
The uncaught exception is good if you have access to the error logs, or think to look there, but an error message which is explicitly output (via echo
) would be even better.
Switch to wp-cli/wp-cli:dev-master
after wp-cli/wp-cli#4024 has been merged.
In attempting to use tests from the theme-tests
base that wp scaffold
sets up, none of my theme's functions existed. Assuming I was doing something wrong, I created a minimal theme and ran wp scaffold theme-tests
to generate the tests. In the theme's functions.php
file, I'm simply outputting text to indicate that the theme is loaded. In Travis CI, you can see that when run as single site, the theme is never loaded. When run as multisite, the theme does get loaded.
A colleague of mine has been struggling with the format for scheduling a WP-Cron event and correctly passing parameters to its callback function. A WP-CLI command to scaffold an event and its callback function with example parameters would be great.
I'm going to put together an example and open a PR.
For the last couple of days I've been trying to get tests to work in themes. I test with a new theme with just a index.php
, a style.css
and a functions.php
file. I have this function in functions.php
:
function test_theme() {
return 'hi';
}
And my test:
function test_sample() {
// Replace this with some actual testing code.
$this->assertTrue( true );
$this->assertEquals( 'hi', test_theme() );
}
When I run the test, PHPUnit gives an error:
There was 1 error:
1) SampleTest::test_sample
Error: Call to undefined function test_theme()
Is there something simple I'm overlooking? For any debug info about my setup/system, please see #22.
The output of wp scaffold post_type <slug>
includes code for the post_updated_messages
filter. The same is not true when generating a taxonomy. It should include code for the term_updated_messages
filter.
The temporary folder that is currently being used in the install-wp-tests.sh
template to download and manipulate files is hardcoded to the /tmp
folder, which can cause all sorts of issues, even on compatible platforms.
The temporary paths should rely on $TMPDIR
instead, as that can then point to /tmp
, /var/tmp
or whatever user-specific temporary folder is meant to be used. Also, it provides a way to override the folder as well.
A command to scaffold the PHP code for a WP-CLI command would be great.
I currently start writing a command by copy-pasting an existing one, but this can get out of date with the latest changes to things such as documentation formatting.
php wp --info
output:
OS: Linux 4.9.60-linuxkit-aufs #1 SMP Mon Nov 6 16:00:12 UTC 2017 x86_64
Shell:
PHP binary: /usr/local/bin/php
PHP version: 7.0.14
php.ini used:
WP-CLI root dir: phar://wp-cli.phar
WP-CLI vendor dir: phar://wp-cli.phar/vendor
WP_CLI phar path: /var/www/html
WP-CLI packages dir:
WP-CLI global config:
WP-CLI project config:
WP-CLI version: 1.5.0
php wp cli version
output:
WP-CLI 1.5.0
php -v
output:
PHP 7.0.14 (cli) (built: Jan 17 2017 19:30:34) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
with Zend OPcache v7.0.14, Copyright (c) 1999-2016, by Zend Technologies
with Xdebug v2.5.5, Copyright (c) 2002-2017, by Derick Rethans
When trying to scaffold the plugin tests I always get the error
Error: Couldn't find install-wp-tests.sh
Command which is executed:
php wp --allow-root --debug --path=/var/www/html/wp scaffold plugin-tests some-plugin
Output:
Debug (bootstrap): No readable global config found (0.326s)
Debug (bootstrap): No project config found (0.328s)
Debug (bootstrap): argv: ./wp/wp --allow-root --debug --path=/var/www/html/wp scaffold plugin-tests some-plugin (0.329s)
Debug (bootstrap): ABSPATH defined: /var/www/html/wp/ (0.329s)
Debug (bootstrap): Begin WordPress load (0.335s)
Debug (bootstrap): wp-config.php path: /var/www/html/wp/wp-config.php (0.337s)
Debug (bootstrap): Loaded WordPress (3.716s)
Debug (bootstrap): Running command: scaffold plugin-tests (3.717s)
Error: Couldn't find install-wp-tests.sh
Did I miss something with the wp-cli installation?
If the above gets implemented, the install-wp-tests.sh
template should be updated in order to introduce a WP_VERSION=beta
flag to support the same functionality in the scaffolding of the unit test suite.
This is a placeholder issue to discuss composable plugins via pull below.
A number of the tests in features/install-wp-tests.feature
assume that you can run mysql
commands as root with no password, which is unlikely to be true locally.
It'd be better I think to use the standard wp_cli_test/password1
user/passsword and have people do GRANT ALL PRIVILEGES ON wp_cli_test_scaffold.* TO "wp_cli_test"@"localhost" IDENTIFIED BY "password1";
to get them to work locally (where using wp_cli_test_scaffold
as the db name instead of the current wordpress_behat_test
). PR incoming.
As mentioned in wp-cli/wp-cli#2119 (comment), you can't test against other WP versions than the version in the $WP_CORE_DIR
directory. As I see it there are two reasons this exists.
install-wp-tests.sh
command.$WP_CORE_DIR
directory.The $WP_CORE_DIR
is an environment variable you can set to use an existing WordPress install for the PHPUnit tests. For back compatibility it's not expected the install-wp-tests.sh
command installs other WordPress versions in that directory.
On the other hand when setting a specific $WP_VERSION
it is expected you test your plugin against that WP version.
Would it be an Idea to add a flag --force-update
to the install-wp-tests.sh
command that allows you to update WP regardless if the $WP_CORE_DIR
directory already exists?
On an unrelated note we could also convert the skip-database-creation
argument to a flag, to not create too many arguments.
To help plugin and theme authors detect PHP version compatibility issues in their codebase, it would be helpful to add the PHPCompatibility sniffs.
Any thoughts on allowing Composer to decide on PHPUnit version instead of manually inspecting TRAVIS_PHP_VERSION?
Instead of this:
scaffold-command/templates/plugin-travis.mustache
Lines 45 to 49 in 382bcff
You could do something like this:
composer global require "phpunit/phpunit=4.8.*|5.7.*"
Which would give us PHPUnit 5.7 instead of 4.8 when running PHP 5.6.
The following labels are missing from the output of wp scaffold post_type <slug>
:
archives
attributes
featured_image
filter_items_list
insert_into_item
items_list
items_list_navigation
remove_featured_image
set_featured_image
uploaded_to_this_item
use_featured_image
view_items
Following up #31 I intend to use behat
on a fully initialized and boostrapable WordPress instance.
For this to work the current bootstrap scripts are too phpunit-centric:
[ ] they rely upon phpunit presence (being run by phpunit)
[ ] they rely upon hardcoded value for host/port/... (issue with wp-config initialization)
[ ] they rely upon not calling wp()
Could we discuss this topic here?
I'm getting these errors when I'm trying to scaffold tests with: wp scaffold plugin-tests name-of-plugin
or wp scaffold theme-tests name-of-theme
. Strangely enough it doesn't happen with all plugins/themes.
This is the output I get when I run wp plugin list
:
+----------------+----------+-----------+---------+
| name | status | update | version |
+----------------+----------+-----------+---------+
| akismet | inactive | available | 3.2 |
| hello | inactive | none | 1.6 |
| new-plugin | inactive | none | 0.1.0 |
| timber-library | active | none | 1.2.4 |
| twitterfeed | inactive | none | 0.5 |
+----------------+----------+-----------+---------+
When I try to scaffold tests for akismet
it works. When I do the same for hello
by running wp scaffold plugin-tests hello
it fails: Error: Invalid plugin slug specified
. In the list above hello
and twitterfeed
fail, the other three work.
wp scaffold theme-tests name-of-theme
also fails with Error: Invalid theme slug specified
, but it's more consistent because I can't seem to get it to work for any of the themes I have installed.
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.1 LTS
Release: 16.04
Codename: xenial
uname -a
Linux russell 4.4.0-78-generic #99-Ubuntu SMP Thu Apr 27 15:29:09 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
which -a php
/usr/bin/php
php -v
PHP 7.0.15-0ubuntu0.16.04.4 (cli) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
with Zend OPcache v7.0.15-0ubuntu0.16.04.4, Copyright (c) 1999-2017, by Zend Technologies
$wp_version = '4.7.5';
which -a wp
/usr/local/bin/wp
stat $(which wp)
File: '/usr/local/bin/wp'
Size: 6804077 Blocks: 13296 IO Block: 4096 regular file
Device: 814h/2068d Inode: 6035154 Links: 1
Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2017-06-06 19:24:44.356297046 +0200
Modify: 2017-06-06 19:24:23.548641754 +0200
Change: 2017-06-06 19:24:41.528343781 +0200
Birth: -
--skip-packages
to skip loading themaaemnnosttv/wp-cli-dotenv-command
Or am I missing something?
I am used to travis where you can define several WP versions for the tests.
I am new to docker but I have a fair knowlege about Linux and Ubuntu.
One way that could be done is by actually just cleaning the /tmp folder and installing the tests again with a different WP version. This way not a complete new docker bootup would be needed. Not sure if that is a good way.
Like this. Assuming the config that wp-cli currently adds. Untested
PHPunit:PHP5.3:MySQL:
image: tetraweb/php:5.3
services:
- mysql:5.6
script:
- phpcs
- phpunit
- rm -rf /tmp/*
- bash bin/install-wp-tests.sh wordpress_tests root mysql mysql nightly true
- phpcs
- phpunit
The scaffolded theme unit test files do not successfully load the theme as the active theme. This is due to what appears to be a core bug in register_theme_directory()
, but which can be fixed in the test bootstrap file.
When the theme test suite bootstrap file calls register_theme_directory()
, an entry is added to the $wp_theme_directories
global. When WordPress attempts to load the active theme, it ultimately calls get_theme_roots()
which first checks for a cached value in the theme_roots
transient. This transient gets populated before the muplugins_loaded
hook fires, which means calling register_theme_directory()
at this point has no effect because it does not flush the theme_roots
transient.
This bug can be worked around by calling delete_site_transient( 'theme_roots' )
after calling register_theme_directory()
in the test suite bootstrap file.
Patch coming up.
Core issue: https://core.trac.wordpress.org/ticket/43228
Running wp scaffold plugin-tests <plugin>
results in the tests/includes
directory completely missing completely from the plugin. This causes the test suite to silently exit due to missing required files.
The current gitlab-ci.yml file use the tetraweb/php on top of which it apt-get some stuff and then manually download WordPress core.
But having a prebuilt image would make builds much cheaper/quicker to request an image alredy containing all the needed stuff (zip, mysql, WordPress, ...). chriszarate/wordpress
as an example.
It could even make most of before_script
and bin/install-wp-tests.sh
superfluous.
If no existing image fit the need, one wordpress-test-image
repository + Dockerfile
could be provided by wp-cli, built and provided by hub.docker.io.
PHP nightly on travis is version 7.2 but the TRAVIS_PHP_VERSION var is still set to 'nightly' so:
if [[ ${TRAVIS_PHP_VERSION:0:2} == "7." ]]; then
composer global require "phpunit/phpunit=5.7.*"
else
composer global require "phpunit/phpunit=4.8.*"
fi
results in the installation of 4.8.*.
Bash is foreign to me but I assume it should be possible to throw a secondary condition in there to also check for "nightly"?
After wp-cli/wp-cli#3985 lands, we should revert 919320c
Gutenberg blocks can optionally have a corresponding dynamic template that gets rendered server side. An example of this is the rendering of the Latest Posts block that's included in Gutenberg: https://github.com/WordPress/gutenberg/blob/5b85f851c3b132d6122979aa121bd24f74e73131/blocks/library/latest-posts/index.php
The wp scaffold block
command should include a template for dynamic block rendering and can be appended to the bottom of block-php.mustache
.
Example:
/**
* Renders the `foo/bar` block server side.
*
* @param array $attributes The saved block attributes.
* @param string $content The saved block content.
* @return string Returns the post content with foo/bar block output added.
*/
function render_block_foo_bar( array $attributes, $content ) {
$output = sprintf(
'<hr>%s',
$content
);
return $output;
}
register_block_type( 'foo/bar', array(
'render_callback' => 'render_block_foo_bar',
) );
Any objections to adding an XML declaration to the phpunit.xml.dist
template (<?xml version="1.0?>
)?
It obviously isn't required, but there is no downside that I am aware of.
The primary upside (at least for me) is ensuring an editor properly detects file type to apply syntax highlighting.
wp scaffold post-type
accepts --dashicon=<dashicon>
as an argument.
If I enter --dashicon=dashicon-info
as my command, it seems sensible to strip my entered 'dashicon-' such that the end result is 'dashicon-info', not 'dashicon-dashicon-info'.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.