[pLog-svn] r4934 - plog/branches/lifetype-1.2/templates/admin
Oscar Renalias
oscar at renalias.net
Sat Mar 3 07:49:00 EST 2007
This check in is not correct, {assignvar} is a valid smarty function
that I created, you'll find the code for it under class/template/
smarty/plugins/fuction.assignvar.php. This function is equivalent to
PHP's $key=$$template_var, which I found no other way to implement in
Smarty.
I'm not sure if you're already familiar with how this feature works,
but it's only meant for administrators to be able to set global
values for plugins, and then those values will be used by all blogs
regardless of the current blog settings (of course depending on
whether administrators allow users to override those settings or not,
that's defined by the drop-down list on the right of each parameter)
If the plugins don't have a default value for those settings, it's
fine. As long as the setting is set to be "overrideable", it won't
cause a problem except for the validation when submitting the form.
If that's a problem, all site admins have to do is set a reasonable
default, or if it is a problem, then the plugin developer should make
sure that the validator used to validate the global parameter doesn't
reject empty values.
Regarding the translation of the parameters, I hadn't thought about
getting them translated but it can be easily done.
On 2 Mar 2007, at 21:08, Jon Daley wrote:
> I am not sure what this is supposed to do. Right now, the
> blog_setting value is directly used as the parameter name,
> untranslated.
> Now that I removed the smarty typo, the configuration values are
> actually getting set to something, and that value is incorrect.
> It seems like we need a table to store the global values, and then
> grab the value from there, rather than from the plugin, since the
> plugin
> might have a useful default value, but doesn't know what the current
> globally set value is.
> As far as translating goes, it seems that we either have to
> enforce that plugins have a translation for their configuration
> settings,
> named exactly the same thing, which probably isn't a bad idea,
> otherwise,
> they would have to provide the translation key in the
> getPluginConfigurationKeys array.
>
> On Fri, 2 Mar 2007, jondaley at devel.lifetype.net wrote:
>
>> Author: jondaley
>> Date: 2007-03-02 14:05:20 -0500 (Fri, 02 Mar 2007)
>> New Revision: 4934
>>
>> Modified:
>> plog/branches/lifetype-1.2/templates/admin/pluginsettings.template
>> Log:
>> typo
>>
>> Modified: plog/branches/lifetype-1.2/templates/admin/
>> pluginsettings.template
>> ===================================================================
>> --- plog/branches/lifetype-1.2/templates/admin/
>> pluginsettings.template 2007-03-02 19:02:21 UTC (rev 4933)
>> +++ plog/branches/lifetype-1.2/templates/admin/
>> pluginsettings.template 2007-03-02 19:05:20 UTC (rev 4934)
>> @@ -21,7 +21,7 @@
>> {assign var=pluginsettings value=$plugin-
>> >getPluginConfigurationKeys()}
>> {foreach from=$pluginsettings item=setting}
>> <tr>
>> - {assignvar var=key value=$setting.name}
>> + {assign var=key value=$setting.name}
>> {assign var=name value=$setting.name}
>> {assign var=overrideValue value=$canOverride[$setting.name]}
>>
>>
>> _______________________________________________
>> pLog-svn mailing list
>> pLog-svn at devel.lifetype.net
>> http://limedaley.com/mailman/listinfo/plog-svn
>>
>
> --
> Jon Daley
> http://jon.limedaley.com/
>
> I haven't lost my mind; I have a tape backup somewhere.
> _______________________________________________
> pLog-svn mailing list
> pLog-svn at devel.lifetype.net
> http://limedaley.com/mailman/listinfo/plog-svn
>
More information about the pLog-svn
mailing list