1

I have a theoretical question regarding entities in the Block Editor, since I can find virtually no documentation on entities.

I am building a plugin for the Block Editor that relies on plugin settings in the options table. There are many ways to retrieve these settings inside of the Block Editor. The easiest of which is to add 'show_in_rest' when registering the settings and then use useEntityProp( 'root', 'site', 'my-custom-setting' ). This works great so long as a user is an admin. Since none admins do not have access to settings in WordPress, a fetch error occurs when using useEntityProp and the user is not an admin.

I thought of many alternatives: create global variable, create a custom REST endpoint and fetch directly, etc. All were either bad coding practices (IMO) or had significant performance implications.

Then I stumbled upon entities, and the addEntities action. Combining a custom REST endpoint with a new entity, added via addEntities, I am able to retrieve virtually any data in the Block Editor with extremely minimal impacts to performance. You would get the data with getEntityRecord.

So my question is, is this an appropriate usage of addEntities and getEntityRecord or am I doing something uncouth? Has anyone else used this method before? Because this approach really opens up a ton of doors to efficiently retrieving external data in the Block Editor.

1
  • Why doo you need to know these options values in the block editor? There's an extremely high chance that the problem is not how you're doing it, but rather that you need to do it at all – Tom J Nowell Dec 1 '20 at 18:33
0

I thought of many alternatives: create global variable,

This implies a fundamental misunderstanding of how PHP works. Global variables don't persist across requests, nothing persists from the PHP side unless it's stored in a file or database, as WP is loaded from scratch on every request. There is no persistant process like a Node web application.

create a custom REST endpoint and fetch directly, etc.

This is what getEntityRecord does behind the scenes, it's just a helper that benefits from integration with the data store

So my question is, is this an appropriate usage of addEntities and getEntityRecord or am I doing something uncouth? Has anyone else used this method before? Because this approach really opens up a ton of doors to efficiently retrieving external data in the Block Editor.

getEntityRecord? Sure! addEntities? Not so much. There's a reason settings are only available to admins, it's sensitive data. By routing them through a custom endpoint you've allowed un-secure setting manipulation to happen.

There is an extremely high chance that if we were to learn the reasons for this that the very premise that requires what you're asking about is not necessary.

Blocks shouldn't need to know the values of options, and blocks that need to know this when rendered should be rendered in PHP. After all if you save the content, then the option changes, WP can't go back and update all the posts automatically if you were working with JS to save them.

2
  • Hi Tom, thanks for following up. I may have mixed terminology when I said "global variable". What I meant was adding a JS variable with my data that I would then enqueue with my editor scripts using wp_add_inline_script(). I have a plugin with a number of settings that control the functionality of a custom block. It allows a user to disable/enable certain functionality depending on their needs. These are the settings that I need access to in the Block Editor. Hopefully that clears up my use case. – ndiego Dec 1 '20 at 19:54
  • Quick followup, my custom endpoint would only be returning data from my plugin, not all wp setting data. Not sure if that changes your perspective on this approach. – ndiego Dec 1 '20 at 19:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.