Hey Guys,
I discovered a pretty major issue last night.
I am adding an ext.brilliant_retail.php file to the next version of BR. I just tested it against 2.4.0 preview and clicking ‘enable’ in the add-ons extension section is calling the install method in upd.brilliant_retail.php when the module is already installed. The same thing happens when installing fieldtypes or extensions.
Why would installing an extension touch the module install process? The result is detrimental in our case because the module install process does a drop if exists table check on install. By adding a fieldtype or extension you basically delete your entire store.
On the reverses side we package a fieldtype with BR that our clients my or may not wish to use. If they uninstall the fieldtype it completely uninstalls the module. REALLY SCARY…
Let me know if you need any further information.
Thanks, David
Hi David,
Thanks for reporting this. What you’re seeing is the correct behavior in 2.4, though we can improve it further. The reasoning behind this change is that we want to make package installation seamless, and start eliminating the need for users to be conscious of the various types of add-ons that a package might consist of. It won’t happen overnight, but 2.4 should be a big step in this direction.
As far as packages go, we believe they should be considered a single unit. In other words, anything that’s optional should be its own package. I realize we haven’t done a great job of communicating that stance with 2.4 yet.
We are going to look at improving the warning message before uninstallation of a package so that it lists every part of the package that will be affected. It won’t be perfect but we think that’ll be a interim solution until we can make this totally seamless.
Does that help clarify at all?
Hi Brandon, David,
I thought I’d chip in my 2p/2c here after talking this over with the guys in the office. Brandon, would this not cause excess ‘cruft’ in for example, devot-ee, if people who make add-ons with optional features then had to split out each one of these features?
In the case of accessories, which (by default) add a graphical element to every single page, I would say that these should always be optional (I’ve never enabled the Structure accessory or fieldtype in however many installs we’ve used it on).
Is your long view that everything eventually becomes a ‘module’ (or extension) and that inside that module’s control panel would be options for things to be enabled/disabled (fieldtypes/acc./extensions/plugins)? Because I can see a case for that, although maybe not for fieldtypes as they’ve always felt like a distinct entity to me.
Anyway, sorry for the brain dump, but hopefully you appreciate the feedback! :D
Thanks,
Hi Guys,
I don’t know if this topic is up for debate, but it sort of feels like fixing something that isn’t broken. I can appreciate the intention, but this seems to overshoot the goal post by a long shot.
What about the $required_by property for Extensions? I think it’s a great little hidden feature, and seems to answer the brief just fine. And I have to agree with Rob’s concern that it might cause add-on ‘bloat’ by forcing devs to break their addons into many parts.
Thanks for listening, John
Thanks for the feedback, guys. We hear you, so for 2.4 (at least) we are reverting to the previous behavior.
We’re still going to move towards a more unified add-on experience in future releases, but we want to make sure we get the user experience as good as it can possibly be.
Packet Tide owns and develops ExpressionEngine. © Packet Tide, All Rights Reserved.