Best Practice Configuration_group

[brittainmark]

When writing a plugin in which you create a configuration group for your parameters, Should you
1) always check to see if it is already present and resue if it is?
2) delete the configuration group when you uninstall ?
3) not be using my own group?

I have been doing 1 and 2.
I was wondering if I do 1 but not do 2, then if the plugin is reinstalled it will resuse the group that was previously present?

[mc12345678]

Are you sure that you stated 1 correctly or at least in combination with 2?

While there are several "flavors" to the topic of using/not using configuration options, I am not against them, but also don't see that a group should be created just because nor that options shouldn't go to specific configuration areas.

What I have been trying to go towards related to reuse of configuration_ids is associated with a "reinstall" or a removal that is resumed relatively closely to an install. In that case I'm aiming to exactly reuse the id number. But I don't usually start with an expected number (for a new group), rather locate the next highest not in use to do a new install or retrieve the current value for a "repair" or reinstall and work from that value...


Now stepping back a moment from what I thought I was reading as compared to a bigger picture, the question seems centered around the numeric value of configuration_id, such that lets say I create a group that relates to actions that can be taken with the available date of product. Not necessarily a "highly desired" configuration setting, but if my "plugin" deals with that, then that could be what's needed. Well, then if someone creates an additional control switch to say enable/disable the field on the product info collect page, where it has nothing to do with my plugin and they associate it with that configuration group, I think they might be a little upset if the plugin gets uninstalled and their option disappears because it "happened" to be placed in that configuration group.

So that leads to possible suggestions for improvement: in the configuration_key, use something consistent that would seem uniquely associated with your plugin. You could go as specific as is used in payment, shipping and order_total modules where there is actually a method in the class that returns the configuration_keys associated with the plugin. Problem with that methodology is that the key has to be entered twice in most cases unless a separate methodology is used. Anyways, using the consistent configuration_key prefix *and* the configuration_id will at least minimize impact on the uninstall.

I wouldn't consider checking of the presence of the configuration_id as sufficient to consider using/reusing the value except perhaps under a limited number of things. For example, ZC establishes "default" configuration_id sections and they seem to have been that way for a REALLY long time. I might consider/expect that they are present or at least have a consistent meaning and therefore wouldn't work hard to place options within. But an area added by a plugin, yeah, would want to validate that the option was going to the right place so that could minimize the level of support that would be needed to correct the issue.

While haven't yet talked about it, item 3 should always be a consideration, not only to not use one's own, but any at all... Issue of using an existing configuration group is that it isn't "obvious" to a new admin to that store that there is any such modification present because, up until viewing the full list of configuration options, no differences are apparent. There's also the question of just how often and easily does a configuration need to be changed? Most developers will say, whenever desired and as easily as possible while in the store... but... should also add a flavor of realism. Files likely have to be uploaded in some way, is there anything about the process/usage that might offer an opportunity to set the value(s) that need to be set where they are not expected to be modified in the future but add flexibility to the code.

And I didn't address this either, but as for deleting the configuration group, really should validate that nothing is associated with it before doing so or if doing so should be sure to delete all things associated with it regardless of relationship to your plugin. After all should go big or go home, right?!

[brittainmark]

Thanks for the reply.
From above, 1) refers to checking that the configuration group exists and reusing the configuration_group_id. I check by looking for the group name not the number as this is the next one available as you have said (if it does not exist).

When I have written plug-ins, I have usually created a group for them to go into to keep their maintenance in one place and not have them present in the existing section as to me, they get very full. I do see the logic of putting them into the existing groups and will give it some thought for my latest effort.
The question came about because as I was writing a new plug-in, as an encapsulated plug-in, and I fell foul of the random uninstall issue. Which marks the plug-in as uninstalled, but does not remove any of the information from the database. When I tried to reinstall it, it tried to find the group but failed because I was using

 $result = $this->executeInstallerSql($sql); 

which does not return the selected values and so my install failed. I am now using

 $result = $this->dbConn->execute($sql); 

which does return the selected values.
Having found this issue of my creating, I thought I would ask about best practice. To see if there was a better way of doing things.

I am glad that you mentioned others putting settings into your group, as I had never thought about it. Something else check.

It is all a good learning curve and people on the forum are so helpful.

Thanks again

[mc12345678]

Thanks for the reply.
From above, 1) refers to checking that the configuration group exists and reusing the configuration_group_id. I check by looking for the group name not the number as this is the next one available as you have said (if it does not exist).

When I have written plug-ins, I have usually created a group for them to go into to keep their maintenance in one place and not have them present in the existing section as to me, they get very full. I do see the logic of putting them into the existing groups and will give it some thought for my latest effort.
The question came about because as I was writing a new plug-in, as an encapsulated plug-in, and I fell foul of the random uninstall issue. Which marks the plug-in as uninstalled, but does not remove any of the information from the database. When I tried to reinstall it, it tried to find the group but failed because I was using

 $result = $this->executeInstallerSql($sql); 

which does not return the selected values and so my install failed. I am now using

 $result = $this->dbConn->execute($sql); 

which does return the selected values.
Having found this issue of my creating, I thought I would ask about best practice. To see if there was a better way of doing things.

I am glad that you mentioned others putting settings into your group, as I had never thought about it. Something else check.

It is all a good learning curve and people on the forum are so helpful.

Thanks again

Yeah, I was looking at that sql operation yesterday myself in attempting to transition an admin only plugin to an encapsulated plugin. At the time because I was getting some other unusual results (Installer folder was named installer (no capitalization) which led to seeing the install option, allowing selection but provided a successful install message without doing any installation) I backed out to using the global $db->Execute command in order to retrieve results with the future possibility of attempting the above $this->dbConn->Execute($sql) command. I'm a little hesitant about coding with that construct based on the possibility of $this->dbConn becoming protected or private in absence of expressed planning/expectations.

I note further about using other existing or built in menus that it may be a good idea for any newly added option to show something indicating that it is not part of the default store. There have been users here that in upgrading have not further incorporated old/alternate code that used that feature and misunderstood that the option on their system was not global to all... There's also a lot of discussion throughout the forum about such "groupings". Let's just say that everyone has their opinion and there will always be someone that disagrees with the choice(s) made.

Now, I haven't tried it, but I wonder how "temporary" values might work in this new environment especially with sql statements following one another. Historically (not saying will work in more recent MySQL environments) one could assign a variable (in this case @IdVar) through a query such as

SELECT @IdVar := configuration_group_id 
FROM configuration_group WHERE configuration_group_title LIKE '%Plugin_Group Title%';

And then using the variable @IdVar in later queries... Such worked through Tools->Install SQL Queries back in the day, but haven't tested/tried any time recently. The reason I suggest this as a possible method, is that the "result" would not necessarily be needed within the code, but may be able to stay in the associated SQL. Problem though is such may also require creating queries that allow/support exit from future queries by possibly in some way generating an error that stops further execution where/when necessary...

Also, while I brought up the possibility of others incorporating further settings into the menu, in my touching of modules, I have not updated them all to specifically consider that possibility other than maybe some addressment in the uninstall sql, the instructions or the like if at all... I mean at each iteration I try to make improvements but don't always fully rewrite... Further not every such plugin is installed the same way nor with the same types of features/capabilities.