Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prevent plugins from using core/ namespace #333

Closed
nylen opened this issue Mar 27, 2017 · 4 comments
Closed

Prevent plugins from using core/ namespace #333

nylen opened this issue Mar 27, 2017 · 4 comments
Labels
[Feature] Block API API that allows to express the block paradigm. [Feature] Extensibility The ability to extend blocks or the editing experience Good First Issue An issue that's suitable for someone looking to contribute for the first time [Priority] Low Used to indicate that the issue at hand isn't a top priority to address and can be handled later

Comments

@nylen
Copy link
Member

nylen commented Mar 27, 2017

How can we prevent plugins from using the core/ namespace, as in core/my-block-name, while still allowing blocks to be registered this way by the editor itself?

@nylen nylen added [Feature] Block API API that allows to express the block paradigm. [Feature] Blocks Overall functionality of blocks Framework Issues related to broader framework topics, especially as it relates to javascript labels Mar 27, 2017
@BE-Webdesign
Copy link
Contributor

There are a couple ways to do it. I think allowing it is fine though. One option is in registerBlock to throw an error if core/ namespace is detected. Then you could manually assign the core objects to wp.blocks. Another probably better option is to introduce an array of approved core block slugs. When registering check whether the slug contains core/ and from there check if it is contained in the approved core blocks array. Then have the same registering logic that is already in place do its thing.

@TimothyBJacobs
Copy link
Member

Maybe reopen #336. A registry, if I'm understanding what you meant @BE-Webdesign, would allow for the namespaces to be enforced instead of being bypassable by accessing the global variable directly.

A method could be added like freezeNamespace( string namespace ). Which would prevent additional blocks from being added to that namespace. That would protect core, but would help plugin authors to alleviate the same thing. WooCommerce might not want people using the wc namespace for instance.

@BE-Webdesign
Copy link
Contributor

BE-Webdesign commented Mar 28, 2017

TimothyBJacobs: That could be another application of changes made by #336. But it is not totally necessary at this point to implement something like that.

@aduth aduth added the Good First Issue An issue that's suitable for someone looking to contribute for the first time label Apr 6, 2017
@mtias mtias removed [Feature] Blocks Overall functionality of blocks Framework Issues related to broader framework topics, especially as it relates to javascript labels May 3, 2017
@karmatosed karmatosed added this to the Merge Proposal milestone Jan 25, 2018
@gziolo gziolo added the [Feature] Extensibility The ability to extend blocks or the editing experience label Feb 1, 2018
@gziolo gziolo added the [Priority] Low Used to indicate that the issue at hand isn't a top priority to address and can be handled later label Feb 5, 2018
@jeffpaul jeffpaul modified the milestones: Merge Proposal, Bonus Features Feb 8, 2018
@mtias
Copy link
Member

mtias commented Oct 4, 2018

Going to close this for now as there's no trivial implementation and it's low priority.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Block API API that allows to express the block paradigm. [Feature] Extensibility The ability to extend blocks or the editing experience Good First Issue An issue that's suitable for someone looking to contribute for the first time [Priority] Low Used to indicate that the issue at hand isn't a top priority to address and can be handled later
Projects
None yet
Development

No branches or pull requests

8 participants