Now that I'm migrating to Oxid version 4.7.7 it's great to see how much modules have improved. The metadata.php file is great for describing all module functionality in a single place, in a way that can be versioned in Git. There is a catch however: the data from metadata.php is not used directly but instead is copied to the database (oxconfig and oxtplblocks). I don't see any advantage in doing this, but it does cause me all kinds of problems, that stem from synchronisation problems between the database tables and the metadata file.
Whenever I change the metadata file I have to deactivate and reactivate the module so it refreshes the data in oxconfig.
If I change the blocks in metadata there is no mechanism that would synchronise the changes to oxtplblocks - not even de- and reactivating the module will do that. Oxid merely updates the active column for any modules already in the table but doesn't add, remove or update any new or existing block row. The only solution is to delete all rows for that module in the oxtplblock table then de- and reactivate the module.
Besides from making module development a pain this also causes me problems with deployment. When I deploy a changed version of the shop I want all my changes to be versioned and deployed from version control. Currently updating the modules on the server doesn't do the trick as I have to go and manually update the oxconfig and oxtplblocks tables to reflect the state I want.
Solution proposal: if there was no state in the database then we of course couldn't switch off modules on the fly. I think this could be solved by storing only a list of disabled modules in the database, so an admin could switch modules off but the deployment would still update all module data otherwise.
Whenever I change the metadata file I have to deactivate and reactivate the module so it refreshes the data in oxconfig.
If I change the blocks in metadata there is no mechanism that would synchronise the changes to oxtplblocks - not even de- and reactivating the module will do that. Oxid merely updates the active column for any modules already in the table but doesn't add, remove or update any new or existing block row. The only solution is to delete all rows for that module in the oxtplblock table then de- and reactivate the module.
Besides from making module development a pain this also causes me problems with deployment. When I deploy a changed version of the shop I want all my changes to be versioned and deployed from version control. Currently updating the modules on the server doesn't do the trick as I have to go and manually update the oxconfig and oxtplblocks tables to reflect the state I want.
Solution proposal: if there was no state in the database then we of course couldn't switch off modules on the fly. I think this could be solved by storing only a list of disabled modules in the database, so an admin could switch modules off but the deployment would still update all module data otherwise.