Create a Block list block #27
Comments
|
Even with the batch routine for creating Pragmatic solution
|
|
Now I’ve created quite a few blocks automatically I see the need for a Keyword taxonomy - flat to store the (up to 3) keywords for each block. A new command is required to update the blocks to set the keywords. See bobbingwide/oik-shortcodes#64 |
|
The Keyword taxonomy is no longer limited to 3 keywords. |
|
I now want to be able to create links from the Block List to the actual definition of the block. e.g. Chris O'Dell suggested using localise script to add Using When editing the This is nearly OK. We need to replace the |
|
Even though I have a couple of problems with the then sometimes The workaround is to check the value of |
|
So the following is a withSelect example which I think 'solves' the issue above. The boilerplate was created using create-guten-block and esnext. /**
* BLOCK: with-select-test
*
* Registering a basic block with Gutenberg.
* Simple block, renders and saves the same content without any interactivity.
*/
// Import CSS.
import './style.scss';
import './editor.scss';
const { __ } = wp.i18n; // Import __() from wp.i18n
const { registerBlockType } = wp.blocks; // Import registerBlockType() from wp.blocks
const { withSelect } = wp.data;
const TwsRenderAuthors = function (props) {
console.log(props);
let authorName = 'not found';
if (props.authors && props.authors.length > 0) {
//this doesn't 'set' the attribute per se, however it does
//allow for a cleaner implementation and doesn't trigger
//a re-render/re-call of the function.
//then on refresh(ctrl-f5) or when viewing on the front end the
//attribute is picked up correctly
props.attributes.authorName = props.authors[0].name;
}
authorName = props.attributes.authorName;
return (
<div className="tws-author" data-name={ authorName }><h4>20</h4>First author is:- {authorName }</div>
);
};
const TwsGetAuthors = withSelect((select, ownProps) => {
const { getAuthors } = select('core');
return {
authors: getAuthors()
};
})(TwsRenderAuthors);
/**
* Register: aa Gutenberg Block.
*
* Registers a new block provided a unique name and an object defining its
* behavior. Once registered, the block is made editor as an option to any
* editor interface where blocks are implemented.
*
* @link https://wordpress.org/gutenberg/handbook/block-api/
* @param {string} name Block name.
* @param {Object} settings Block settings.
* @return {?WPBlock} The block, if it has been successfully
* registered; otherwise `undefined`.
*/
registerBlockType( 'cgb/block-with-select-test', {
// Block name. Block names must be string that contains a namespace prefix. Example: my-plugin/my-custom-block.
title: __( 'with-select-test - CGB Block' ), // Block title.
icon: 'shield', // Block icon from Dashicons → https://developer.wordpress.org/resource/dashicons/.
category: 'common', // Block category — Group blocks together based on common traits E.g. common, formatting, layout widgets, embed.
keywords: [
__( 'with-select-test — CGB Block' ),
__( 'CGB Example' ),
__( 'create-guten-block' ),
],
attributes: {
authorName: {
type: 'string',
source: 'attribute',
selector: '.tws-author',
attribute: 'data-name'
}
},
/**
* The edit function describes the structure of your block in the context of the editor.
* This represents what the editor will render when the block is used.
*
* The "edit" property must be a valid function.
*
* @link https://wordpress.org/gutenberg/handbook/block-api/block-edit-save/
*/
edit: function( props ) {
// Creates a <p class='wp-block-cgb-block-with-select-test'></p>.
console.log('call edit');
return (
<div className={ props.className }>
<TwsGetAuthors {...props} />
</div>
);
},
/**
* The save function defines the way in which the different attributes should be combined
* into the final markup, which is then serialized by Gutenberg into post_content.
*
* The "save" property must be specified and must be a valid function.
*
* @link https://wordpress.org/gutenberg/handbook/block-api/block-edit-save/
*/
save: function (props) {
console.log('call save');
/*
When using the withSelect version of the component in the 'save' function I always get an error
relating to 't.subscribe'. So call the component rather than the 'withSelect' version.
*/
return (
<div>
<TwsRenderAuthors {...props} />
</div>
);
},
} ); |
Thanks Chris. I'll try this logic in my Author Profile block. Meanwhile, the solution I used in my block seems to work. Where before I had: I changed it to not use |
…stType. Try adding key to Fragment around dt and dd tags
…owBatch and showCreateBlockLink are selected
|
The first pass logic to create/update Block CPTs directly from a Block List block has been checked in already.
|
|
There’s a problem in the function that creates the link to a block, ExplanationIt turns out that the replace function needs to be told to perform a replace all, using a global replace regular expression. SolutionChange to use |
|
With Gutenberg 5.8.0 and 5.9.0 the block list for the core blocks had some very large SVGs for Image and Video. Turns out that I needed to add some CSS to style the SVGs - they'd lost their |
|
The links to the block’s definition needs to be all lower case. Even though WordPress finds the post, oik-loader-mu.php doesn’t find the page when performing an index lookup. Therefore it doesn’t load the dependent plugins for the post. |
|
I used the Block list block in a Block News post to say I'd catalogued the blocks for the Editor-Blocks plugin. Unfortunately the links are no good. e.g. The It should be Pragmatic workaround. Don't include links to each block but a link to the plugin. |
|
The AJAX request to create/update a block can be too long for the server. This occurred for uagb/team. WorkaroundEdit the URL. Reduce the icon to very little. Correct the icon when editing the created post. |
|
I added the example: logic for most of the blocks in oik-blocks. |
…a list should have a unique key prop.
|
The CollegeHumor block was deprecated in WordPress 5.4. In the Gutenberg source the block is still registered but with the How should we cater for blocks that are not insertable? |
|
Well the first thing to do in the block list is to show if the block is insertable or not. |
|
I've decided to extend the logic so that This means that we'll see the words in the excerpt on the Blocks tab for the plugin. Never mind, there are some deprecation messages we have to deal with anyway. |
|
Well, this is still open so I may as well piggy back. For a long time now, each time there's a new version of Gutenberg I spent an absolute age comparing the block list with one version to the block list of the next. Proposed solutionWhen the Show block link toggle is Off and the Show batch commands toggle is On then just display a simple list of blocks with no markup apart from
This should make it a lot easier to identify the block changes. |
… off and Show batch commands is On.
|
While it's still open.... I have a need to compare the block list for one version of a plugin with another. When the toggles are: The output would be like this>
The general format for each block / variation record would be
|
I've only addressed the List layout so far. For the next layout format I think Grid would be preferable to Table |
|
I've found a problem with the block link when the block title contains a |
|
While this issue's still open, I don't want to display all the variations of the Post Terms block ( I expect the solution to be similar to that developed for #54. |
I'm going to drop this requirement from this issue.
|
Following on from #24 (comment) I now have requirements for a Block list block.
This block will be used on the home page for a component which delivers blocks.
Requirements
blockpost where the block is documentedProposed solution
Block type name: oik-block/blocklist
Title: Block list
Icon: block-default
The text was updated successfully, but these errors were encountered: