Open erickyle opened 5 years ago
Do you mean that you'd like to reuse the same "Fields" – or the settings for a specific Field?
I meant it would be nice to reuse the settings for a specific field. The use case I have is that there are a number of blocks with a select field that contains about thirty options used to choose an icon from a custom font. Currently I need to update the options for the select field in each of the blocks, so being able to populate those fields from a single source would avoid variances. Does that help to clarify the request?
Yeah, that makes sense! One thing you could do is hook into the save_post
hook, then json_decode
the post content, change whatever you need to change, and json_encode
it back again.
I think the solution you proposed will work just fine. Thanks!
On Apr 17, 2019, at 6:24 AM, Luke Carbis notifications@github.com wrote:
Yeah, that makes sense! One thing you could do is hook into the save_post hook, then json_decode the post content, change whatever you need to change, and json_encode it back again.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
Seems like the save_post
hook will not allow me to manipulate the form elements generated by Block Lab. I need a way to inject a list of icons into the "Icon" select menu field for the block. You can see where I have the Choices field populated in the Block Lab block editor, but I must update the list of icons in multiple blocks since they all use the same list of icons. Please let me know if I'm simply missing some aspect of using the hook. Thanks in advance.
If you hook in late (as in, after Block Lab does – a priority of 20
should work) to wp_insert_post_data
, you should be able to json_decode
the post content, make any changes you need, and re-encode it again to be saved.
That said, I think a better way would be to create a custom Field Type. You could create a Field Type called Icon, and maybe just include help text as a setting.
We don't have any docs on how to do this currently (but we should definitely make them – I'm marking it on my to-do list). It starts with the block_lab_controls
filter: https://github.com/getblocklab/block-lab/blob/develop/php/post-types/class-block-post.php#L122
.
Hi, Luke!
I work in Eric's team, and I've been looking at your latest suggestion.
We have created a subclass of Control_Abstract which we add to the controls list using the block_lab_controls filter. It is basically a copy of the Select control, but with the default values populated, and a different name (ctaicon).
After doing that, the control shows correctly when we go to create a new block or edit an existing one.
Nonetheless, when we add the block to a Post, the custom control does not show up (an empty div shows up where the control should be). We think there is something that may need to be edited/added to the functionality under editor.blocks.js, since peppering some console.logs there show that the control is passed as an object identical to the select one, with the only difference of having the control property being "ctaicon" instead of "select". It is super-minified, so finding the exact change needed has been a challenge.
Could you point us in the right direction to get this last step implemented?
Thank you!
@pgallastegui @erickyle – I've not seen anyone actually extending Block Lab with a custom control yet, so this is exciting!
Well done on adding the custom control to the Edit Block screen. The next step will be to build the control out in Javascript, so it can be included in the Editor.
To do this, you could try starting with our existing select
control, and modifying it to suit your needs: https://github.com/getblocklab/block-lab/blob/develop/js/blocks/controls/select.js
Note that this is written in React, so you'll need to build it, and then include it as a script when the editor is active (use the enqueue_block_editor_assets
hook – use a priority of less than 10 to make sure it's included before Block Lab).
Lastly, you'll just need to add the control to Block Lab's array of loadedControls
. We provide a Javascript filter for that, called block_lab_controls
. Here's a tutorial on using WordPress filters in Javascript (this is still a pretty new feature).
Let me know how you go. If this seems too hard, I might take the time to create an example control extension to give you (and others) a starting point. Just not sure how much of a priority it's going to be (I'll talk to the team).
Hi, Luke!
Thanks again for pointing me in the right direction. After a couple of crash courses on React, I think I am still missing something. I've downloaded the development branch, duplicated the select control and modified the constant name. Next, I included it in the index.js at the same level. I ran an npm build, and that obviously resulted in a replacement file for editor.blocks.js that seems to include the new control, along all other controls. Since that is not just an export of the new control, we started playing with different configurations of files (eliminating all the other controls and their references in index.js, eliminating js files in folders above it, etc.). In the end, none of the results seemed like something that could be added using the WP JS hook. For example, the leanest one looked something like this (which is almost exactly the same as the scripts.js file generated alongside it):
!function(n){var r={};function t(e){if(r[e])return r[e].exports;var o=r[e]={i:e,l:!1,exports:{}};return n[e].call(o.exports,o,o.exports,t),o.l=!0,o.exports}t.m=n,t.c=r,t.d=function(n,r,e){t.o(n,r)||Object.defineProperty(n,r,{configurable:!1,enumerable:!0,get:e})},t.n=function(n){var r=n&&n.__esModule?function(){return n.default}:function(){return n};return t.d(r,"a",r),r},t.o=function(n,r){return Object.prototype.hasOwnProperty.call(n,r)},t.p="",t(t.s=0)}([function(n,r){}]);
Would the code above be what we have to use in the filter? How would we do so?
Nonetheless, while working on this, we thought for our particular case we may not need to create the functionality of a new control, since it is identical to the select control, but just with some default values. So we used the hook to create a new method and pass it a reference to the existing select method, which ended up working great!
`wp.hooks.addFilter( 'block_lab_controls', 'namespace/path', blockLabControls );
function blockLabControls( controls ) {
controls.customcontrol = controls.select;
return controls;
}`
I would still love to figure out the last part of the puzzle (creating the control, building it with react, and including it via the hook) so any guidance would be appreciated. It feels we are almost there, but missing a detail. Please let me know if you want me to provide any info on the steps we've taken.
Thank you!
@pgallastegui @erickyle Sorry it took so long – here's an example on how you can extend Block Lab with a custom control: https://github.com/getblocklab/block-lab-pokemon-control
There are cases where we need the same list of options across multiple blocks. Maintaining them separately is fine if the list is short and the blocks are few. However it would be great to be able to filter the options programmatically.