Latest News: (loading..)
Harald Ponce de Leon

Configuration Modules

32 posts in this topic

Hi All..

 

There has always been one area in osCommerce Online Merchant that was not able to be translated into different languages, which has been the configuration parameters. The title and descriptions are hardcoded in english in the database osc_configuration table. Not only that, a hack was introduced to see and set the values dynamically on a per configuration parameter level - which had an ugly implementation that was also hardcoded in the database table.

 

I just pushed out a proof of concept to finally fix this for v3.0 to a new cfg branch on my github repo:

 

https://github.com/haraldpdl/oscommerce/tree/cfg

 

This introduces the concept of Configuration Modules where each configuration parameter is a module, where one common module is used by slightly over half of the configuration parameters to set its value via a normal text input field. Each module has its own language definition file where the title and description are defined, and also additional definitions for unique parameter values.

 

The modules are named in CamelCase style of the parameter key, for example the module for STORE_COUNTRY is found in:

 

osCommerce/OM/Core/Site/Admin/Module/Configuration/StoreCountry.php
osCommerce/OM/Core/Site/Admin/languages/en/US/modules/Configuration/StoreCountry.php

 

The language definitions are defined as:

 

 

cfg_store_country_title
cfg_store_country_description

 

Simple configuration parameters do not need their own module, they can use the standard common module but must have their own language definition file containing the title and description of the parameter.

 

There are two methods to retrieve the configuration parameter value:

 

$Config->get() // returns a formated value, eg United States of America (by default it returns the getRaw() value)
$Config->getRaw() // returns the real value, eg 223 (the country ID for USA)

 

The configuration table can be optimized from:

 

configuration_id
configuration_title
configuration_key
configuration_value
configuration_description
configuration_group_id
sort_order
last_modified
date_added datetime
use_function
set_function

 

to:

 

 

configuration_id
configuration_key
configuration_value
configuration_group_id
sort_order

 

(A field could be added to define the module name, but this can be generated automatically from the configuration key)

 

Although it will be a lot of work to create the initial configuration parameters, it brings in much more flexibility on how configuration parameters can present their input fields and also allow for the parameters to be translated into different languages.

 

What are your thoughts? Is this a good implementation to work on?

 

Kind regards,

foxp2 likes this

Share this post


Link to post
Share on other sites

Hi Harald,

Is this a good implementation to work on?

(w00t) YES ! (w00t)

Share this post


Link to post
Share on other sites

it's a real improvement.

It also has the effect of making life easier to translators

 

[sorry, can't edit my post]

Share this post


Link to post
Share on other sites

Hi Laurent..

 

Yep. I just created a script to automatically create the language definition files from the database and have pushed them to my cfg branch.

 

I would wait with the translations though until the english definitions have been updated and have made it to a release.

 

@@Mark Evans what do you think of backporting the finalized implementation to v2.3? (this would break compatibility so a version number jump would be required)

 

Kind regards,

foxp2 likes this

Share this post


Link to post
Share on other sites

@@Mark Evans what do you think of backporting the finalized implementation to v2.3? (this would break compatibility so a version number jump would be required)

 

Yes, lets jump a version number, that's a great idea this multilingual configuration, makes it also much easier to create modules, not having to type in all that description text into the query

Share this post


Link to post
Share on other sites

Hi Laurent..

 

Yep. I just created a script to automatically create the language definition files from the database and have pushed them to my cfg branch.

 

thank you for that :thumbsup:

 

I would wait with the translations though until the english definitions have been updated and have made it to a release.

 

Oh, a new directory was added ( https://github.com/foxp2/oscommerce/tree/cfg/osCommerce/OM/Core/Site/Admin/languages/fr_FR/modules/Configuration ) ^_^

Share this post


Link to post
Share on other sites

Hi Harald!

It's a wonderful idea!

Thanks a lot for this new localized part.

 

Regards

FX

Share this post


Link to post
Share on other sites

@@GniDhal :

private joke : ici j'ai une grosse truffe (remplace avoir avec être)

 

forceful return of a community that supports Oscommerce since ten years ! :-

Share this post


Link to post
Share on other sites

Great for 3.

 

Maybe leave series 2.x as it is to ensure compatibility for upgrading from prior to 2.4?

Edited by burt

Share this post


Link to post
Share on other sites

hi Harald,

Is it possible to add a htmlspecialchars_decode for configuration_description ?

 

especially for this line in \osCommerce\OM\Core\Site\Admin\Application\Configuration\pages\entries_edit.php

<p><?php echo $OSCOM_ObjectInfo->get('configuration_description'); ?></p>

 

:unsure:

Share this post


Link to post
Share on other sites

Hi Laurent..

 

Can you post a language definition example that is causing a problem?

 

Kind regards,

Share this post


Link to post
Share on other sites

\osCommerce\OM\Core\Site\Admin\languages\fr_FR\modules\Configuration\StoreCountry.php

cfg_store_country_description = The country my store is located in <br /><br /><strong>Note: Please remember to update the store zone.</strong>

 

it's not a problem, htmlspecialchars_decode will be useful

Edited by foxp2

Share this post


Link to post
Share on other sites

Hi Laurent..

 

That is being shown correctly to me (with HTML formatting). Are you seeing the actual HTML tags?

 

Kind regards,

Share this post


Link to post
Share on other sites

I'm seeing nothing, because i've not installed the script ... o:)

i'm going to check it later

sorry to trouble you :blush:

multimixer likes this

Share this post


Link to post
Share on other sites

Great work on the translations! That was really fast! :thumbsup:

currently in process.

i've asked french team to help me by working on translation

@@GniDhal

Share this post


Link to post
Share on other sites

Laurent,

I'm here if I can be helpful to translate ....

 

Fred

thanks for that ! :thumbsup: (PM via our forum (osCommerce France))

 

Actually, today, with github (between osCommerce/haraldpdl/foxp2/oscommerce-france repo), by leaping from branch to branch, i wonder if i'm not a monkey ... :shifty:

Share this post


Link to post
Share on other sites

Hi Harald, that's super! :)

I have actually been thinking of doing something similar for my v2.x.x Plus, it would be nice to have one, perhpas two, admin languages even if the store is multilingual. That is, being able to handle for example Greek without having the Greek language installed on the admin side.

 

I'll be following this topic, and can assist in translation into Swedish.

 

Kind Regards

Sara

foxp2 likes this

Share this post


Link to post
Share on other sites

hi Harald,

can you please add

/**

* @since v3.0.x [ x is the number your choice ]

*/

in new files ?

thanks. :ph34r:

Share this post


Link to post
Share on other sites

Hi Laurent..

 

Yes, will do and will double check before a release is made.

 

I'm thinking about the following releases:

 

v3.0.3 - Admin\Products Application and Admin+Setup PostgreSQL Queries

v3.0.4 - Template Engine functionality and Configuration Modules

v3.0.5 - Admin\Orders Application

 

Kind regards,

Share this post


Link to post
Share on other sites

These modules need to become more modular ;) I don't like that all modules are in the one directory - the ones that belong to actual modules (eg, Service Modules) should be stored at the same module level. I also think these configuration modules should become self-installable / self-uninstallable.

 

I won't be able to sleep tonight :D

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now