I'm working on the D8 port of the subdomain module. It allows the administrator to define a list of entities/bundles that can be accessed by subdomain aliases. In D7 I had form_alters to add the field, and a custom table tracking subdomains and their related entities for storage. In D8 I can add the field the same way, but I'm trying to figure out the best practice approach to storing the data.

  • I could declare a new content entity, but that seems like a lot of overhead for one varchar field.

  • I could extend the schema of targeted entities to include one extra varchar field. But when I think of altering table schema every time the administrator hits a checkbox, I think that can't be right.

I had a look at core's path module to see how they approach the problem, and they use hook_entity_base_field_info() to add the field, backed by a custom storage service. It seems like that's not a recommended approach for contributed modules, though.

Can anyone advise on what I should use? Am I missing something simple here?

closed as primarily opinion-based by kiamlaluno Jun 6 '16 at 7:30

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    I'm not sure about the best/should use approach. Adding to the base field definitions probably is going to be the best performance-wise (pre-caching), but adding a field to the entity wouldn't be so bad due to caching improvements (og does this). Either adding it to base or bundle fields for an entity does leave the option open to change the field storage later. – mradcliffe Mar 21 '16 at 11:50

Browse other questions tagged or ask your own question.