Znuff
Member-
Posts
10 -
Joined
-
Last visited
About Znuff

Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
Znuff's Achievements
Junior Member (1/3)
0
Reputation
-
Change Domain Contact Details in PreRegistrarRegisterDomain
Znuff replied to Znuff's topic in Developer Corner
1) no, you only need this 2) https://docs.whmcs.com/Custom_Transliteration: -
Pipe.php permissions get reset on update
Znuff replied to SamS1's topic in Installation, Upgrade, and Import Support
You are literally not understanding the bits in the permission system. 755 is not "friendly" in any way. the extra bit away from 644 is simply the execute bit. -
Pipe.php permissions get reset on update
Znuff replied to SamS1's topic in Installation, Upgrade, and Import Support
This is a very "faux" sense of security. If an attacker has access to your `pipe.php` somehow, be sure that he can already set 755 on the file. There is absolutely no security risk from having 755 vs 644; the only difference between the two is that 755 also has eXecute rights compared to 644. There would have been an issue if it had `777` or `666` as that would make it world/group writeable/executable. tl;dr - leave the file's permissions like that -
Change Domain Contact Details in PreRegistrarRegisterDomain
Znuff replied to Znuff's topic in Developer Corner
Answering this for posterity. While the hook does indeed seem to be NOT functioning correctly, as per #CORE-13757, the best way to do fix my initial issue would be to use this hook: <?php function hook_transliterate($string) { $string = transliterator_transliterate('Any-Latin; Latin-ASCII;', $string); return $string; } Notice how we are using transliterator_transliterate(), which is a built-in function of PHP, instead of having a huge array of characters to swap. The WHMCS documentation could be a little bit clearer on this functionality, as in, we initially thought that the client data would be stored in WHMCS already transliterated (which we didn't want, at all), but it does not seem to be the case. -
Change Domain Contact Details in PreRegistrarRegisterDomain
Znuff posted a topic in Developer Corner
Hello, I have a relatively simple issue with ResellerClub not accepting Unicode chars in the State/City field (and probably others). I'm trying to change the contact details with the help of PreRegistrarRegisterDomain, but so far I'm not having much luck. My code seems to be working fine, it changes the array from what I can tell, but the Registrar is still replying with Error. This is my code (transliteration function shamelessly stolen from another module posted on this community, I forget which): <?php function remove_unicode_before_registrar($string){ $nonLatinChars = array( '/ä|æ|ǽ/' => 'ae', '/ö|œ/' => 'oe', '/ü/' => 'ue', '/Ä/' => 'Ae', '/Ü/' => 'Ue', '/Ö/' => 'Oe', '/À|Á|Â|Ã|Ä|Å|Ǻ|Ā|Ă|Ą|Ǎ|Α|Ά|Ả|Ạ|Ầ|Ẫ|Ẩ|Ậ|Ằ|Ắ|Ẵ|Ẳ|Ặ|А/' => 'A', '/à|á|â|ã|å|ǻ|ā|ă|ą|ǎ|ª|α|ά|ả|ạ|ầ|ấ|ẫ|ẩ|ậ|ằ|ắ|ẵ|ẳ|ặ|а/' => 'a', '/Б/' => 'B', '/б/' => 'b', '/Ç|Ć|Ĉ|Ċ|Č/' => 'C', '/ç|ć|ĉ|ċ|č/' => 'c', '/Д/' => 'D', '/д/' => 'd', '/Ð|Ď|Đ|Δ/' => 'Dj', '/ð|ď|đ|δ/' => 'dj', '/È|É|Ê|Ë|Ē|Ĕ|Ė|Ę|Ě|Ε|Έ|Ẽ|Ẻ|Ẹ|Ề|Ế|Ễ|Ể|Ệ|Е|Ё|Э/' => 'E', '/è|é|ê|ë|ē|ĕ|ė|ę|ě|έ|ε|ẽ|ẻ|ẹ|ề|ế|ễ|ể|ệ|е|ё|э/' => 'e', '/Ф/' => 'F', '/ф/' => 'f', '/Ĝ|Ğ|Ġ|Ģ|Γ|Г/' => 'G', '/ĝ|ğ|ġ|ģ|γ|г/' => 'g', '/Ĥ|Ħ/' => 'H', '/ĥ|ħ/' => 'h', '/Ì|Í|Î|Ï|Ĩ|Ī|Ĭ|Ǐ|Į|İ|Η|Ή|Ί|Ι|Ϊ|Ỉ|Ị|И|Й/' => 'I', '/ì|í|î|ï|ĩ|ī|ĭ|ǐ|į|ı|η|ή|ί|ι|ϊ|ỉ|ị|и|й/' => 'i', '/Ĵ/' => 'J', '/ĵ/' => 'j', '/Ķ|Κ|К/' => 'K', '/ķ|κ|к/' => 'k', '/Ĺ|Ļ|Ľ|Ŀ|Ł|Λ|Л/' => 'L', '/ĺ|ļ|ľ|ŀ|ł|λ|л/' => 'l', '/М/' => 'M', '/м/' => 'm', '/Ñ|Ń|Ņ|Ň|Ν|Н/' => 'N', '/ñ|ń|ņ|ň|ʼn|ν|н/' => 'n', '/Ò|Ó|Ô|Õ|Ō|Ŏ|Ǒ|Ő|Ơ|Ø|Ǿ|Ο|Ό|Ω|Ώ|Ỏ|Ọ|Ồ|Ố|Ỗ|Ổ|Ộ|Ờ|Ớ|Ỡ|Ở|Ợ|О/' => 'O', '/ò|ó|ô|õ|ō|ŏ|ǒ|ő|ơ|ø|ǿ|º|ο|ό|ω|ώ|ỏ|ọ|ồ|ố|ỗ|ổ|ộ|ờ|ớ|ỡ|ở|ợ|о/' => 'o', '/П/' => 'P', '/п/' => 'p', '/Ŕ|Ŗ|Ř|Ρ|Р/' => 'R', '/ŕ|ŗ|ř|ρ|р/' => 'r', '/Ś|Ŝ|Ş|Ș|Š|Σ|С/' => 'S', '/ś|ŝ|ş|ș|š|ſ|σ|ς|с/' => 's', '/Ț|Ţ|Ť|Ŧ|τ|Т/' => 'T', '/ț|ţ|ť|ŧ|т/' => 't', '/Ù|Ú|Û|Ũ|Ū|Ŭ|Ů|Ű|Ų|Ư|Ǔ|Ǖ|Ǘ|Ǚ|Ǜ|Ũ|Ủ|Ụ|Ừ|Ứ|Ữ|Ử|Ự|У/' => 'U', '/ù|ú|û|ũ|ū|ŭ|ů|ű|ų|ư|ǔ|ǖ|ǘ|ǚ|ǜ|υ|ύ|ϋ|ủ|ụ|ừ|ứ|ữ|ử|ự|у/' => 'u', '/Ý|Ÿ|Ŷ|Υ|Ύ|Ϋ|Ỳ|Ỹ|Ỷ|Ỵ/' => 'Y', '/ý|ÿ|ŷ|ỳ|ỹ|ỷ|ỵ/' => 'y', '/В/' => 'V', '/в/' => 'v', '/Ŵ/' => 'W', '/ŵ/' => 'w', '/Ź|Ż|Ž|Ζ|З/' => 'Z', '/ź|ż|ž|ζ|з/' => 'z', '/Æ|Ǽ/' => 'AE', '/ß/'=> 'ss', '/IJ/' => 'IJ', '/ij/' => 'ij', '/Œ/' => 'OE', '/ƒ/' => 'f', '/ξ/' => 'ks', '/π/' => 'p', '/β/' => 'v', '/μ/' => 'm', '/ψ/' => 'ps', '/Ж/' => 'Zh', '/ж/' => 'zh', '/Х/' => 'Kh', '/х/' => 'kh', '/Ц/' => 'Tc', '/ц/' => 'tc', '/Ч/' => 'Ch', '/ч/' => 'ch', '/Ы/' => 'Y', '/ы/' => 'y', '/Ш/' => 'Sh', '/ш/' => 'sh', '/Щ/' => 'Shch', '/щ/' => 'shch', '/Ю/' => 'Iu', '/ю/' => 'iu', '/ю/' => 'iu', '/Я/' => 'Ia', '/я/' => 'ia' ); $nonLatinFrom = array_keys($nonLatinChars); $nonLatinTo = array_values($nonLatinChars); $separator = '-'; $pregSeparator = preg_quote($separator, '#'); $string = trim($string); $string = strip_tags($string); $string = preg_replace($nonLatinFrom, $nonLatinTo, $string); $string = trim(trim($string, $separator)); return $string; } add_hook('PreRegistrarRegisterDomain', 1, function($vars) { array_walk($vars['params'], function(&$value) { $value = remove_unicode_before_registrar($value); } ); return $vars; }); The code seems to be working fine when I test it externally: https://3v4l.org/Sbojv - you can see it transliterates Constanța to Constanta just fine. This also seems to be working fine in WHMCS when I var_dump($vars) in the code, but the registrar is still being sent the non-transliterated values, so I still end up with {state=State is invalid., stateid=State is invalid, city=City is invalid.} What am I doing wrong here, and why is the registrar module not picking up the transliterated strings? -
Just answering for posterity - I ended up doing what I mentioned above, I created a simple "custom page" that just outputs the current logged in client's details: <?php require __DIR__ . '/../init.php'; use WHMCS\ClientArea; use WHMCS\Database\Capsule; use WHMCS\User\Client; header("Content-type: application/json"); $ca = new ClientArea(); $ca->initPage(); // Check login status if ($ca->isLoggedIn()) { $d = Client::find( $ca->getUserId() ); $client = array( 'firstname' => $d->firstname, 'lastname' => $d->lastname, 'email' => $d->email, 'address1' => $d->address1, 'address2' => $d->address2, 'city' => $d->city, 'state' => $d->state, 'postcode' => $d->postcode, 'country' => $d->country, 'phonenumber' => str_replace(' ', '', $d->phonenumber), 'tax_id' => $d->tax_id, 'language' => $d->language, 'companyname' => $d->companyname, ); // Custom Fields: // 1 - CNP // 3 - Reg. Com. // 6 - Tip Persoana // 33 - IBAN // 34 - Banca $d = Capsule::table('tblcustomfieldsvalues') ->where('relid', $ca->getUserId()) ->get(); foreach ($d as $i) { switch ($i->fieldid) { case 1: $client['cnp'] = $i->value; break; case 3: $client['regcom'] = $i->value; break; case 6: $client['tippersoana'] = $i->value; break; case 33: $client['iban'] = $i->value; break; case 34: $client['bank'] = $i->value; break; } } print(json_encode($client, true)); } else { // User is not logged in } Then I simply just did the pre-fill of my values in the page using JavaScript/jQuery: $.ajax({ url: "/my-custom-page.php", success: function (data) { if (!$.isEmptyObject(data)) { $('.cnpField').val(data['cnp']); $('.regComField').val(data['regcom']); $('.cifField').val(data['codfiscal']); $('.selectField').val(data['tippersoana']).change(); if ( data['tippersoana'] === 'p' || data['tippersoana'] === 'ap' ) { $('.ownerField').val(data['firstname'] + ' ' + data['lastname']); } else { $('.ownerField').val(data['companyname']); } $('.mailField').val(data['email']); $('.address1Field').val(data['address1']); $('.address2Field').val(data['address2']); $('.phoneField').val(data['phonenumber']); $('.countryField').val(data['country']); $('.stateField').val(data['state']); $('.cityField').val(data['city']); } } }); If a non-registered user goes trough the same process, it gets an empty output, because the custom page in WHMCS takes care of auth and client details. If it's empty, it simply does nothing. Maybe it will be useful for someone 🙂
-
Actually disregard the above. I figured that I would rather use a "custom page" type and generate the javascript file directly from whmcs: <?php use WHMCS\ClientArea; use WHMCS\Database\Capsule; use WHMCS\User\Client; require __DIR__ . '/../init.php'; header("Content-type: application/json"); $ca = new ClientArea(); $ca->initPage(); // Check login status if ($ca->isLoggedIn()) { $d = Client::find( $ca->getUserId() ); $client = array( 'firstname' => $d->firstname, 'lastname' => $d->lastname, 'email' => $d->email, 'address1' => $d->address1, 'address2' => $d->address2, 'city' => $d->city, 'state' => $d->state, 'postcode' => $d->postcode, 'country' => $d->country, 'phonenumber' => $d->phonenumber, 'tax_id' => $d->tax_id, 'language' => $d->language, ); print(json_encode($client, true)); } else { // User is not logged in } Now I just need to figure out how do I actually get the custom fields, as Client doesn't actually return those values. I would like to avoid an extra query if I can, but I'm not sure I will be able to, as there doesn't seem to be a model for it.
-
I tried ClientAreaHomepage, unfortunately that does not trigger on the cart pages. I tried ClientAreaPageCart, but this does not seem to do any actual output. function ch_output_client_details($vars) { return <<<HTML <script> alert('hi'); </script> HTML; } add_hook("ClientAreaPageCart", 1, "ch_output_client_details"); What I'm trying to do here: - For our local .tld, a common request is that users want to register their domain names for other people/companies, but they don't particularly want to create new user accounts for each and every domain - Yes, I am aware that WHMCS has the ability to use a different contact for domain registration, but unfortunately this is insufficient in our use case (our .tld requires extra information based on the type of business/personal entity) - We do have almost all the fields that are common between actual account information configured as additional fields for the .tld (like name, address, email, phone etc.) In particular, we are trying to have pre-filled data when an existing user attempts to buy a new domain while logged on. We are also trying to avoid modifying template files as much as we can - as this would create overhead and extra work when we update it from our vendor. So, our idea is to simply have WHMCS output a <script> in the confdomains cart step, which contains an object with the clients user information, from which we can just populate the fields on loading of the page - we are already doing form validation via javascript on that page, so it would be a natural progression. Any tips on where/how to do this?
-
Hello, I'm trying to get the logged in users' customer data and then drop it in a javascript variable using a custom hook, on the domain configuration (additional page) field. I'm looking at the documentation but I'm sure sure where to start from - all looking at the hook list, there doesn't seem to be any hook firing on: /cart.php?a=confdomains Or at least I can't figure out which one does. Could someone point me in the right direction?
-
Welcome to WHMCS.Community Znuff! We're glad you're here please take some time to familiarise yourself with the Community Rules & Guidelines and take a moment to introduce yourself to other WHMCS.Community members in the Introduce Yourself Board.
