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

Block hooks for adding additional blocks to the defined block groups #368

Closed
thenewguy opened this issue Sep 29, 2020 · 2 comments
Closed
Labels
Type: Enhancement New feature or functionality change

Comments

@thenewguy
Copy link
Contributor

It is fairly cumbersome to add additional blocks to the pages.

It would be nice if the variables used for holding "types" of blocks was passed through a hook/signal/something that allowed global modification of these lists: HTML_STREAMBLOCKS, CONTENT_STREAMBLOCKS, NAVIGATION_STREAMBLOCKS, BASIC_LAYOUT_STREAMBLOCKS, LAYOUT_STREAMBLOCKS, STREAMFORM_FIELDBLOCKS, STREAMFORM_BLOCKS

This would make it easy to hook in third party blocks for individual sites without requiring special integration from the CodeRed project. For example, issue #15 could easily be solved with this enhancement for sites that want it without any additional burden on the codebase.

Since all of the pages are implemented in abstract fashion I think this would be pretty straightforward. Migrations would be handled at the implementation level and shouldn't cause any conflict with CodeRed.

Recently when I encountered the need to add custom blocks, I redefined the lists and then wrote mixins that override the "body" field to apply them to my pages. This is kind of clumsy and my next thought is to monkey patch the lists... but I would prefer to take a different route if possible.

I think this would be generally useful for most implementations. What do you think? Is there another plan in place that I have missed?

@thenewguy thenewguy added the Type: Enhancement New feature or functionality change label Sep 29, 2020
@thenewguy
Copy link
Contributor Author

I just found #305. I could be wrong but I think what I am describing is compatible with migrations. It would just require a migration when the value changes which is normal

@thenewguy
Copy link
Contributor Author

Going to close. Pretty much a duplicate of the previously linked issue and there is already discussion there

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Enhancement New feature or functionality change
Projects
None yet
Development

No branches or pull requests

1 participant