Domain additional fields

[hostell]

Hi.

 

From new version to new version... Still this poky system of domain additional fields.

The developers of custom reg. modules have to pregmatch() the key names of fields, to send them to registrars's api. Because html names (that users see during domain reg. ) and key names, being sent to api, are the same for WHMCS. Brilliantly.

 

And now look at admin's source page:

 

 

<tr><td class="fieldlabel">

<font color=#0000FF><!-- api_surname -->Surname</font>

</td><td class="fieldarea">

<input type="text" size="40" name="additionaldomainfield[<font color=#0000FF>Surname</font>]" value="Pupkin">

</td></tr>

 

 

Small hint. We have id field. But we do not like it. We like to use name, which contains html code...

 

Mr. Matt, I have only one question. Was it so hard to add the key filed? Why the developer should make a lot of crutches to suit this system?

 

Sorry for such effort, I'm writing custom module for my local registrar, and kinda tired...

[Matt]

No developers don't need to use preg_match. You don't put HTML into a field name, any formatting/styling should be done via the templates, and so the name should be exactly that, the name. Follow the examples of the default fields and then you're using it correctly. There is no more logical way it could work than referencing the field by the name when it comes to module development.

 

Matt

[hostell]

As far as I know, clientsdomains.php cannot be customized via template system.

As a result we have:

 

person <text input>

person_r <text input>

addr_code <text input>

addr_post <text input>

org <text input>

org_r <text input>

Private person <text input>

etc.....

 

No colors, no groups, no descriptions..

 

Very hard to read. Always need to have transcriptions of fields..

 

The only proposal I have to introduce the key field.

 

id | domainid | key | html_name | value

 

And some hooks to be able to validate new data before inserting it to db (not only if it is required field or not).

[pikos]

Also! Lets say that I need the additional domain field translated in Greek because I have Greek customers.. does the fallowing looks right to you ?

 

<input type="text" size="40" name="additionaldomainfield[Επώνυμο]" value="">

 

Just add a key filed.. plz

 

Thank you!

[Rhyzio]

With other fields (lets say Configurable Option Groups) I could use "SYSTEMREQUIREDOPTION|Readable Option". With additionaldomainfields I cannot. All I can get to work is SYSTEMREQUIREDOPTION, which looks terrible unless the Registrar designed their API for the language my WHMCS happens to be in.

[Rhyzio]

IMO: This is what we need to get the additionaldomainfields working correctly (multilingual):

 

1) REQUIREDFIELDNAME|Readable Field Name

2) $_LANG["Readable Field Name"]

3) Support for "Name", "Options", and "Default"

 

Any feedback from Admins?

[Rhyzio]

I just thought I'd post that:

 

{$_LANG["Readable Field Name"]}

 

Does work for translating the Options, but then it sends the translated option through instead of the SYSTEMREQUIRED name.

 

If | was activated for additiondomainfields then this would no longer be a problem.

[Matt]

I can confirm that support for alternative display names compared with the values passed through to backend API's have already been implemented for the next release.

 

Matt