centralnicgroup-opensource/rtldev-middleware-whmcs

AdditionalFields management

Closed this issue · 5 comments

According to your doc (https://centralnicgroup-public.github.io/rtldev-middleware-documentation/docs/cnr/whmcs/whmcs-cnic-registrar/), in order to manage "additional domain fields" I need to "copy the additionalfields.php file provided by our module [to] the /resources/domains/ directory. "
But:

  • current /modules/registrars/cnic/lib/additionalfields.php is encrypted
  • current /modules/registrars/ispapi/lib/additionalfields.php is encrypted

So it's impossible (i.e.) to select few additionalfields from cnic and few from ispapi mixing them as needed, or define additionalfields for other TLD not managed by cnic or ispapi...
Even more:

  • it's harder to translate additionalfields related messages into foreign languages
  • we manage our own reseller API for our customers; but our customers needs to know the comprehensive set of additionalfields to set in their own systems, in order to use them in the API calls to our system

Fix:

  • leave unencrypted both /modules/registrars/cnic/lib/additionalfields.php and /modules/registrars/ispapi/lib/additionalfields.php (also because there's no real reason to encrypt such kind of files...)

Hey @Remitur!

nice to hear from you again :-)

Some feedback in advance:

  • current /modules/registrars/ispapi/lib/Additionalfields.php is encrypted

That's right and we will be keeping it that way. We cover in this class file huge improvements for additional fields that are not offered via WHMCS Core and we don't want to share it with our competitors. Brand "ispapi" is coming with its predefined additional fields configuration shipped with the registrar module and does not need a /resources/domains/additionalfields.php configuration at all. By this solution, we were able to offer a fully translatable way for additional fields, automatic pre-filling of fields (e.g. VATID), etc. WHMCS Core is only capable of translating the label of additional fields but not the description and dropdown fields. Our additional field translations are covered by the language files shipped with our ispapi registrar module (they can be customized, but when upgrading - you'll have to apply the changes again imho). So, from that perspective, I don't see where ispapi has an impact to other TLDs not managed over us. That's leaving me questions to be honest.

  • current /modules/registrars/cnic/lib/additionalfields.php is encrypted

That sounds like a bug. Let me have an eye on it. That file as well all the files under /modules/registrars/cnic/tlds shouldn't be necessarily encrypted. I fully agree. Even though there are no plans yet on my desk - long term perspective could also lead to the ispapi approach and thus making the explicit additional fields configuration file superfluous. Still, maybe with an improved possibility to influence/customize translations. But again, no plans yet for that.

So, we can help you with "cnic" as mentioned. The ispapi integration is a bit special in that regard but allows for customizing and adding languages definitely. Let me know if you need more insights to the ispapi way.

In the meanwhile, I'll rolling a patch out for the cnic integration. Thanks for reporting.

Hello @KaiSchwarz-cnic , and thanks for the fixing.
Just another question about AdditionalFields using cnic.
Ispapi's additionalfields file is much more rich than cnic's file.
I.e., for .ro domains Ispapi has his own definitions, that overrides the standard WHMCS definitions.
Instead in cnic's there's no special additionalfield defined dor .ro domains
So:

  • does cnic's use WHMCS's original additionalfields defined by WHMCS by default, and do not require custom additional fields
  • or does it use same additionalfields defined by ispapi
  • or what else?
    Thank you for your attention

Hey @Remitur,

  • There are no additional fields shared between "ispapi" and "cnic" as both are different registrar systems (even though very similar, still different in detail).
  • cnic -> /modules/registrars/cnic/tlds/ro.php: Yes, there's no special configuration here in place. The integration uses the default fields provided by WHMCS and maps them to Command Parameters. This means that you can still override the field names with your custom additional fields config file - just ensure leaving the field names untouched (and their values of course). That allows for adding custom descriptions, custom language key for the label translation etc.

Hope that helps!
Kai

UPDATE:

  • CNIC Registrar Module: the additional fields integration is now fully api-driven. Please remove any /resources/domains/additionalfields.php configuration related to that integration. Read the guide here
  • ISPAPI Registrar Module: the additional fields integration is not api-driven, but directly maintained by my team if there's a description or so to update, let us know.

Both modules are using the same technical way for showing the additional domain fields on the Contact Information Page in the client area. Check the clientareadomaincontactinformation.tpl file under /templates/cnic-six or /templates/cnic-twenty-one for the related changes. They are nicely wrapped with comments and we recommend taking them over to your theme.

For HEXONETispapi we launched that change via v20.0.0.

Enjoy