Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I have created a new module called Block Machine Name which handles the machine name related functionality of fe_block.
This module basically borrows verbatim from these functions:
fe_block_form_alter
fe_block_machine_name_validate
fe_block_machine_name_submit
fe_block_machine_name_delete
fe_block_get_machine_name
And then adds a couple functions per #1861008: add the block machine_name into block classes once block has been rendered. so that machine names for blocks provide a reliable class name as well as a template suggestion (a concept which is both relevant for features as well as the site building community at large).
I think it would be a relatively simple matter make fe_block depend on block_machine_name and remove these functions from fe_block in order to reduce the redundancy introduced by making the separate module.
I think there is an excellent case for decoupling this functionality for non-features users which is explained in part on the project page and the issue cited above. I would also be happy to grant maintainer-ship to any of the maintainers here in order to ensure that block_machine_name continues to facilitate the needs of Feature Extra.
I'd be glad to discuss anything in further detail, but just wanted to test the waters and open the door to a dialog.
Thanks!
Comments
Comment #1
pfrenssenThis is a nice initiative but the problem is that we cannot add new dependencies easily. The module dependencies are only checked when a module is first enabled, not when a module is updated. We would break all sites that perform the update without first installing block_machine_name.
One solution is to keep duplicated code available as a fallback when the block_machine_name module is not installed but that defeats the purpose of separating out code. Another solution is to defer this to a next major version (Features Extra 2.x), but just having this code separated does not really warrant a new major version. We would need some other major improvements :)
Comment #2
DYdave CreditAttribution: DYdave commented@justindodge:
Thanks a lot for posting this issue and following-up on #1861008: add the block machine_name into block classes once block has been rendered..
I would also think the suggested change and idea would be an improvement for Features Extra.
@pfrenssen:
Thank you very much for your very helpful/constructive feedback and pointing out the issue related with adding a new dependency.
A new major version would sound great.
maybe we could create a new Roadmap ticket to list other major improvements others/you would like to see.
We'll keep following this issue with a great interest and try helping with testing/reporting where we can.
Thanks again very much for your work, feedback and initiatives.
Cheers!
Comment #3
justindodge CreditAttribution: justindodge commented@pfrenssen:
Thank you for your reply! I see what your point about the difficulty of adding a depenency, but I don't think it is quite impossible to do without breaking sites. Modules can check for new dependencies early at runtime and notify the user and take other necessary actions to prevent issues until the dependency is resolved.
However, I agree that there is not really a major improvement here that necessarily warrants that level of effort.
It sounds like the preferred course of action is to wait for 2.x - in the meantime it would be relatively rudimentary to add the features that block_machine_name offers to fe_block (there is a patch in the issue cited above that's halfway there). I believe the abstraction of block_machine_name into it's own module is still an excellent choice for those who need it's functionality in isolation.
Comment #4
benjifisherI think you can add dependencies with a minor version update. Just call module_enable() from within hook_update_N() in your .install file. Provide a helpful error message in case the new module is not avaiable.