Overriding / Extending a block controller package to package.

Permalink
I've got a situation here I could use some advice on and there's going to be a few moments of my describing this scenario that will leave you scratching your head about why this was done but you're just gonna have to trust me that this is an inherited situation, I can't really explain why, and I really can't go back in time and undo it as much as I'd like to.

I have a package I'm going to call "All-In-One" for easy reference here. This package installs some new block types and a theme. Several (30+) sites have been set up with this theme package. At some point it was decided that the blocks were too difficult to maintain inside this All-In-One package and they were broken out into their own individual packages. Time went on and many more sites were then setup with this newer scheme of standalone block packages with a different theme also in a standalone package.

Now as you can imagine, there's some tech debt as a result. The All-In-One package sites cannot get the block updates we roll out. We want to get everyone up to date though. If I install any of the new standalone block packages on the All-In-One sites, it will install a duplicate block with the same name and it will actually work as intended but I can't have two blocks in the block palette with the same name. If I uninstall the All-In-One package, it deletes the blocks and content within those blocks which is no good either.

I'm looking for a way where I can install the new standalone blocks and in the old All-In-One theme tell the blocks there to no longer refer to their own block files, namely the view and controller and instead extend or be overwritten by the newer standalone block's view and controller without causing a duplicate install of the block. I really want to sunset that All-In-One package. It's legacy, no longer used and I'd prefer to not upkeep these block updates in two places.

I have extended block controllers from the /application/blocks/ directory for various things but I have not done a package to package override or extension on blocks if that is even something I can do.

I have considered doing something like, detecting when that All-In-One package is present and if so, copying the new standalone block to the applications/blocks/ directory to override but that doesn't get me around the duplicate block issue on install of that standalone block package... unless I leave the package uninstalled which I don't love really.

Anyway, I'd love some advice or suggestions.

SpatialAnomaly
 
JohntheFish replied on at Permalink Reply
JohntheFish
When installing the 'duplicate' blocks, what you actually need to do is modify the database columns for package ownership, swapping ownership from the all-in-one package to the news package. You don't do a full block install, merely point c5 at a new location for the code - your package. That maintains continuity of existing block instances.

For overrides, a package installer can copy an override from a package to /application. Rather than copy the entire class or file, copy a wrapper or shim that then calls back into the actual class/file in the package.
Before copying in such, check nothing is already there.
When uninstalling, remove your override, buty check its still yours (check a signature)
SpatialAnomaly replied on at Permalink Reply
SpatialAnomaly
Oooh interesting on the ownership column. Ok that is some great advice, thanks John. I will look into that. And thank you also for the info on the overrides, I'm hoping in general that it isn't necessary, just swapping ownership should get me where I want to be.