# Extending UnitBlock class for custom fields and controlling completion mode **URL:** \ **Category:** Development\ **Created:** [July 5, 2022, 8:06pm UTC](https://discuss.openedx.org/t/extending-unitblock-class-for-custom-fields-and-controlling-completion-mode/7747 "2022-07-05T20:06:54Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![braden](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.openedx.org/braden/32/46_2.png) [@braden](https://discuss.openedx.org/u/braden)\ **Post date:** [July 5, 2022, 11:19pm UTC](https://discuss.openedx.org/t/extending-unitblock-class-for-custom-fields-and-controlling-completion-mode/7747/2 "2022-07-05T23:19:40Z")
> [@tramck](#): > > Is this something that is even possible? As far as I know, you “should” be able to implement a custom Vertical XBlock by uninstalling the normal one and installing a subclass of it that has the same `vertical` entry point. I’m not sure why that wouldn’t be working; perhaps you haven’t removed the existing entry point? > [@tramck](#): > > Even if it is possible, is it advisable or are there complications that you could think of that could arise from this method of customization? It should be fine as long as you subclass the existing blocks. If you tried to replace `VerticalBlock` with `UnitBlock` or replaced VerticalBlock with something entirely custom, then you’d have problems. But swapping out VerticalBlock for a custom subclass which has the same entry point (`vertical`) should be fine as far as I can think. > [@tramck](#): > > 1. If this is not possible, I think we will need to create an xblock for managing the unit categorization. All the xblocks I have worked on and seen so far have been content-related, rather than metadata-related. Is there an existing pattern we could follow for creating an xblock for managing unit metadata? Well one option is that you can use the [`XBLOCK_EXTRA_MIXINS `](https://github.com/openedx/edx-platform/blob/15a38bc7f1fb0ecf50795ef322a7462ac7390179/lms/envs/common.py#L1523-L1527) setting to add a mixin class to _all_ XBlocks on the platform, which can define new data/metadata fields and do anything else that you’d like. It applies to all blocks but you can ignore its data and/or make it do nothing for most XBlocks other than `vertical`. Another solution is to not store this data using XBlocks at all, but rather store it in a separate table with a foreign key to the XBlocks. That’s what I did in the [Tagstore](https://github.com/open-craft/blockstore/tree/master/tagstore) API I previously designed for storing taxonomies in Open edX and associating them with XBlocks (or users or anything else), though I never got to finish that project. See the recent thread [Tagging a question in Open edX](https://discuss.openedx.org/t/tagging-a-question-in-open-edx/7671) where someone asked a similar question and I gave a similar answer. You may even want to collaborate with them. A separate table is much cleaner and simpler _but_ the big downside is the data won’t be copied if you e.g. duplicate the XBlock in Studio or re-run the course. So it works well for people using content libraries but probably not as helpful if most of your authoring and tagging happens within courses that are then copied or re-run. > [@tramck](#): > > Is there a way to require an xblock within a unit / prevent an xblock from being used within a unit multiple times? There are hacky ways to do this but no clean way that I know of. It would be better to implement a non-XBlock plugin that renders your custom tagging control in Studio alongside the unit in question, and stores its data in a separate table. You can also do this as an XBlock mixin that adds its control widget to the `studio_view` or `author_view` of whatever XBlocks you want, without modifying their code. --- _[View the full topic](https://discuss.openedx.org/t/extending-unitblock-class-for-custom-fields-and-controlling-completion-mode/7747)._