guys,

i needed to have a list of all Brazilian states. so i created a store_custom.inc including " $available_states['br'] = array(...", as stated on store_location.inc.

there are 2 bugs:
1* the address form misbehave oftem: sometimes it loads $available_states['us'], but sometimes it loads my custom $available_states['br']. the behaviour is just not reliable.
2* the address.js file only changes if the contry is "us", so doesnt matter what contry you customize. Worst: when ecommerce module updates, this file will be set to normal again!

i may urgely suggest:
1* to create some database alternative instead using a file like store_custom.inc. so other modules can manipulate them. a web interface to manage (import/export/change) this data. i can help on this.
2* start to include many new states on main store_location.inc for next releases.

best regards

massa

PS: brazilian states are:
$available_states['br'] = array(
'AC' => 'Acre',
'AL' => 'Alagoas',
'AP' => 'Amapá',
'AM' => 'Amazonas',
'BA' => 'Bahia',
'CE' => 'Ceará',
'DF' => 'Distrito Federal',
'ES' => 'Espírito Santo',
'GO' => 'Goiás',
'MA' => 'Maranhão',
'MT' => 'Mato Grosso',
'MS' => 'Mato Grosso do Sul',
'MG' => 'Minas Gerais',
'PA' => 'Pará',
'PB' => 'Paraíba',
'PR' => 'Paraná',
'PE' => 'Pernambuco',
'PI' => 'Piauí',
'RJ' => 'Rio de Janeiro',
'RN' => 'Rio Grande do Norte',
'RS' => 'Rio Grande do Sul',
'RO' => 'Rondônia',
'RR' => 'Roraima',
'SC' => 'Santa Catarina',
'SP' => 'São Paulo',
'SE' => 'Sergipe',
'TO' => 'Tocantins',
);

CommentFileSizeAuthor
#3 module2.patch534 bytesbrmassa
#2 js2.patch1.57 KBbrmassa
#1 address.txt1.1 KBbrmassa

Comments

brmassa’s picture

brmassa commented
Assigned: Unassigned » brmassa
Priority: Normal » Critical
Status: Active » Needs review
StatusFileSize
new address.txt1.1 KB

guys,

this patch corrects the complete misbehave of javascript on address. the current code only works for US.
bugs fixed:
* you now can update your state/province
* dropdown menu available for all predefined countries.

it doesnt fix:
* a better way to deal with custom data instead editing store_custom.inc

regards,

massa

PS: the zip file, containing the patch to address.module and address.js were renamed to TXT.

brmassa’s picture

brmassa commented
StatusFileSize
new js2.patch1.57 KB

correction: the patchs are inverted.

brmassa’s picture

brmassa commented
StatusFileSize
new module2.patch534 bytes

correction: the patchs are inverted.

sime’s picture

sime
any/any
Location Melbourne
commented

Thanks for the patch, I will test it.

You *can* edit store_custom.inc. It won't be deleted, because when you copy new ecommerce over old ecommerce. New ecommerce will never have this file, so the current file will remain.

You other ideas:

Store in database -
We won't do this in ecommerce. We don't want to manage large country lists like this. Eventually location.module will be the optional alternative.

Add more to store_location.inc -
no, this will consume too much resources when it is included. This might be ok if it was an admin function only, but this will get called on every address page.

brmassa’s picture

brmassa commented

Simon,

thanks for your response.

  • what i meant about losing the file is because the general instruction for updating modules is delete the entire directory and unpacking again. it will erase the store_custom.inc.
  • i dont like solutions involving manual file edition because many Drupal users are resalers: they sell Drupal hosting for clients. when clients need something like editing files, its always get some difficulties. i tought about database in order to update this data thru Drupal interface. i dont know much about location module, but it may be a much more elegant solution.

best regards,

massa

sime’s picture

sime
any/any
Location Melbourne
commented

Ok, I understand. I might have another option for you.

I do want to know: can these clients edit settings.php OK?

brmassa’s picture

brmassa commented

Simon,

he he... generally, no. The common thing is: the reseller configure everything once: settings, cron and modules instalation (now thru installation profiles). Who uses these kind of services dont know much. They are newbies and want a "just works" products.

sometimes, its only a single Drupal installation for many clients. not file access at all.

a third group is formed by linux users using distro packages. Im working on porting Drupal 5.1 to Ubuntu. No access to files besides root. The current problem is about modules and theming installation, so im building a module just for this.

Despite all these reason and situations, i really believe that Drupal can (or even should) be simple to use. That why i proposed a web interface for address module configuration. my opinion only.

im gonna open a forum topic to get from users all customized states data. might be helpfull.

regards,

massa

PS: i think that its not clear that the patch corrects a important bug: you simply cannot update your state/provice once you created. its because a bug on Javascript. It also allows users to really use the customized states.

brmassa’s picture

brmassa commented
Version: 5.x-3.0 » 5.x-4.x-dev
Status: Needs review » Fixed

Fixed on ec4

sime’s picture

sime
any/any
Location Melbourne
commented

Hi brmassa

I haven't looked at this in a while. What fix did you use?

Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)