Hi there,
we're unsure and a bit confused about how to handle the plugin configs in our 1.0-git test environment:
- Almost all plugins do still use the legacy "$rcmail_config" array in
their .dist file, rather than "$config". Do we need to manually run a search/replace across all config.inc.php(.dist)?
- The plugin 'password' for instance does already use the "$config" array
in it's config.php.dist. But this is not being reflected in config.inc.php (shouldn't there be some sort of automatism?).
- Furthermore, the same plugin 'password' does contain a number of new
config settings in .dist - but also those did not find their way into the .php file. So we have to merge them into .php as well?
If so: Hmmm, I have seen (and even developed) more convenient and automated ways of updating configs already, but that was decades ago under DOS/16... ;)
JFTR: The 'password' plugin is just an arbitrary example, the same may/will most likely apply to other plugins as well. But 'password' is just the first one where we recognized that "$config" is being used at least in the .dist file already.
Any helpful advice appreciated.
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 09/22/2013 10:21 PM, Michael Heydekamp wrote:
- Almost all plugins do still use the legacy "$rcmail_config" array in
their .dist file, rather than "$config".
That it not true, at least for plugins from Roundcube repo.
Do we need to manually run a search/replace across all config.inc.php(.dist)?
Yes. However, with current git-master both variables would work.
- The plugin 'password' for instance does already use the "$config" array
in it's config.php.dist. But this is not being reflected in config.inc.php (shouldn't there be some sort of automatism?).
What do you mean? No need to modify variable automatically because the old is supported still.
- Furthermore, the same plugin 'password' does contain a number of new
config settings in .dist - but also those did not find their way into the .php file. So we have to merge them into .php as well?
There's no need to specify all options in config file. You should put there only options you need (and differ from default value).
If so: Hmmm, I have seen (and even developed) more convenient and automated ways of updating configs already, but that was decades ago under DOS/16... ;)
We do/will not update user config files.
Am 23.09.2013 08:25, schrieb A.L.E.C:
On 09/22/2013 10:21 PM, Michael Heydekamp wrote:
- Almost all plugins do still use the legacy "$rcmail_config" array in
their .dist file, rather than "$config".
That it not true, at least for plugins from Roundcube repo.
Well, we do have "some" more (not necessarily activated/registered in Roundcube, but being existent in the plugins directory).
What is still confusing us:
Do we need to manually run a search/replace across all config.inc.php(.dist)?
Yes. However, with current git-master both variables would work.
Ok...
- The plugin 'password' for instance does already use the "$config" array
in it's config.php.dist. But this is not being reflected in config.inc.php (shouldn't there be some sort of automatism?).
What do you mean? No need to modify variable automatically because the old is supported still.
Isn't that a contradiction to what you said above?
We DO NEED to modify the variable manually (that is what you stated with your "Yes" above), but at the same time there is NO NEED to change it (automatically) because the old one does still work...?
Hmmm. Why then do we need to modify it manually?
We do/will not update user config files.
Of course Roundcube should not change any user- or server-defined settings. But in the case of renaming a variable/array, from my point of view this should be updated automatically.
Anyway, why I'm asking and trying to clarify all this: The 'password' plugin doesn't work here anymore since a week or so. To be more precise, it's the domainFACTORY driver that doesn't work anymore.
So whom should we address with this issue? The author of the plugin (you), the author of the domainFACTORY driver (Till Krüss), or domainFACTORY itself?
I have the suspicion that it might not work due to recent changes of the plugin, but I'm not sure, of course.
Are you able to help with this...?
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
What do you mean? No need to modify variable automatically because the old is supported still.
Isn't that a contradiction to what you said above?
We DO NEED to modify the variable manually (that is what you stated with your "Yes" above), but at the same time there is NO NEED to change it (automatically) because the old one does still work...?
Hmmm. Why then do we need to modify it manually?
Because eventually it will stop working and only the new method is supported. Thats how I read his statement.
Cor
Am 24.09.2013 20:59, schrieb Cor Bosman:
What do you mean? No need to modify variable automatically because the old is supported still.
Isn't that a contradiction to what you said above?
We DO NEED to modify the variable manually (that is what you stated with your "Yes" above), but at the same time there is NO NEED to change it (automatically) because the old one does still work...?
Hmmm. Why then do we need to modify it manually?
Because eventually it will stop working and only the new method is supported. Thats how I read his statement.
Ok, but... If a plugin will eventually stop working with the old config variable/array because RC doesn't support it anymore - wouldn't that be a perfect reason to automatically update all .dist and .php config files of all plugins (rather than having to modify them manually and run a search/replace across all config files)?
In our ancient DOS/16 mail client we did often rename and/or add this and that config setting. And of course the user didn't have to fiddle around with it - we renamed or added the designator automatically, but of course didn't touch any existing values.
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 09/24/2013 09:17 PM, Michael Heydekamp wrote:
Ok, but... If a plugin will eventually stop working with the old config variable/array because RC doesn't support it anymore - wouldn't that be a perfect reason to automatically update all .dist and .php config files of all plugins (rather than having to modify them manually and run a search/replace across all config files)?
Sorry, for being missleading. I should say "you shoud" not "you need". Which means it should work with old config. And yes it wasn't working when we initially implemented the change, but we added support for old variable name later. It should work with current git-master.
Am 25.09.2013 08:11, schrieb A.L.E.C:
Sorry, for being missleading. I should say "you shoud" not "you need". Which means it should work with old config. And yes it wasn't working when we initially implemented the change, but we added support for old variable name later. It should work with current git-master.
A lot of "should", in fact... ;)
AFAICS most plugins seem to work, but you didn't respond to this particular problem (which is probably not related to the $config vs. $rcmail_config issue):
Am 24.09.2013 20:48, schrieb Michael Heydekamp:
Anyway, why I'm asking and trying to clarify all this: The 'password' plugin doesn't work here anymore since a week or so. To be more precise, it's the domainFACTORY driver that doesn't work anymore.
So whom should we address with this issue? The author of the plugin (you), the author of the domainFACTORY driver (Till Krüss), or domainFACTORY itself?
I have the suspicion that it might not work due to recent changes of the plugin, but I'm not sure, of course.
Are you able to help with this...?
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
I'm still hoping for an answer to this:
Am 27.09.2013 00:23, schrieb Michael Heydekamp:
Am 24.09.2013 20:48, schrieb Michael Heydekamp:
Anyway, why I'm asking and trying to clarify all this: The 'password' plugin doesn't work here anymore since a week or so. To be more precise, it's the domainFACTORY driver that doesn't work anymore.
So whom should we address with this issue? The author of the plugin (you), the author of the domainFACTORY driver (Till Krüss), or domainFACTORY itself?
I have the suspicion that it might not work due to recent changes of the plugin, but I'm not sure, of course.
Are you able to help with this...?
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 10/03/2013 10:09 PM, Michael Heydekamp wrote:
Anyway, why I'm asking and trying to clarify all this: The 'password' plugin doesn't work here anymore since a week or so. To be more precise, it's the domainFACTORY driver that doesn't work anymore.
I don't use this driver and I don't see anything wrong in it's code. So, this might be not related to config var name change.
Am 04.10.2013 08:09, schrieb A.L.E.C:
On 10/03/2013 10:09 PM, Michael Heydekamp wrote:
Anyway, why I'm asking and trying to clarify all this: The 'password' plugin doesn't work here anymore since a week or so. To be more precise, it's the domainFACTORY driver that doesn't work anymore.
I don't use this driver and I don't see anything wrong in it's code. So, this might be not related to config var name change.
Right, as the driver doesn't work anymore in 0.9.x as well... It was definitely still working on Sep 13th late evening, and it was definitely NOT working anymore on Sep 18th late evening. So something must have happened in this period.
I just wasn't sure if any of the various changes to the plugin itself (ond/or to its config, unrelated to the var name change) might be the reason...?!
If you say no, we will have to approach Till Krüss and/or domainFACTORY. But do you say "no"?
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 10/05/2013 10:00 PM, Michael Heydekamp wrote:
If you say no, we will have to approach Till Krüss and/or domainFACTORY. But do you say "no"?
As I see there was no change in password plugin nor domainfactory driver since 10 months in release-0.9 branch.
Am 06.10.2013 14:37, schrieb A.L.E.C:
As I see there was no change in password plugin nor domainfactory driver since 10 months in release-0.9 branch.
So I did approach Till Krüss and it turned out that domainFACTORY has introduced stronger requirements for (new) passwords, and that was the reason why it appeared as if it wouldn't work anymore.
There is a pull request from Till which claims to handle this case:
https://github.com/roundcube/roundcubemail/pull/136
As I would like to test it - would you be so kind to accept this request?
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Action requested. :)
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 17.10.2013 08:30, schrieb Michael Heydekamp:
Am 06.10.2013 14:37, schrieb A.L.E.C:
As I see there was no change in password plugin nor domainfactory driver since 10 months in release-0.9 branch.
So I did approach Till Krüss and it turned out that domainFACTORY has introduced stronger requirements for (new) passwords, and that was the reason why it appeared as if it wouldn't work anymore.
There is a pull request from Till which claims to handle this case:
https://github.com/roundcube/roundcubemail/pull/136
As I would like to test it - would you be so kind to accept this request?
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany _______________________________________________ Roundcube Development discussion mailing list dev@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/dev
-
A.L.E.C -
Cor Bosman -
Michael Heydekamp