Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


PapaKai last won the day on January 16

PapaKai had the most liked content!

Community Reputation

29 Excellent


About PapaKai

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hey @ganje! 😏 Let me for completeness also point out that availability checks based on whois are a) slow b) not always reliable c) not supporting premium domain names that's why the better idea is to stick to your registrar as provider even though this isn't providing what you're looking for.
  2. Hey @FutureX Let me reply here regarding premium domain names and how this works in WHMCS. Showing up the design issues of WHMCS itself with the premium domain integration as well. (I am the Dep. Lead / Lead Dev. of the HEXONET ispapi registrar module, not the one that is shipped with WHMCS!) So, basically, you already received very good input here. Thanks @Remitur for having us mentioned as Premium Domain Provider - very appreciated! The best idea is always to use your Registrar of Choice also for availability checks - independent of the premium domain topic. This ensures that the availability shown reflects to possibility to order or not. Sometimes a domain is shown as available at Registrar A (the configured lookup provider), but isn't then for some reason available on Registrar B (your configured TLD Provider). I would find it better, if the lookup would be done in general by relying on the availability check integration of the TLD Provider - but that's just my opinion. Premium Domain Names are rarely well supported by registrar integrations. The reasons: the demand for premiums is not that high and as of bugs / issues in either the registrar integrations or in whmcs core related to premium domains, people stop business with premiums soon or are keeping it disabled anyway. It took years until WHMCS patched my reported bug with Premium Domain Transfers where the regular price was used on shopping cart level and not the one shown up in search results. WHMCS Core itself looks stable regarding premiums now, but there are still design issues... In tbldomains, there's a single field is_premium or so that is then 1 or 0 and is telling whmcs that the domain is premium or not. in tbldomains_extra, you'll find entries related to the registrar registration price, registrar renewal price and registrar currency of the underlying premium domain(s). ... and this is where it is getting weird for domain registrars: There's no WHMCS Core built-in possibility to get this price updated and we had to build our own tooling for either adding missing parts or adding the full set of that premium pricing data. Partially missing/incomplete data was a result of a WHMCS Core Bug (they missed adding the premium renewal price to DB). This bug got patched some time ago, but patching missing data is of other's responsibility. But that's about an old bug, not of interest if you're freshly starting with premiums. But what if the registry provider decides to switch regular domain names to premiums, or if prices change on registry level? Yes, no solution available in WHMCS for automatically adding the missing premium pricing data or updating existing pricing data. We had a customer with ~1k .xxx domain names that got switched to premium and we spent a lot time on our end with helping them and thanks to our tooling, we have a way now for this. You may upvote this feature request: https://requests.whmcs.com/idea/domain-synchronization-process-premium-domain-names If you want to offer Premium Domains, let me point to us, we have huge experience with them in WHMCS. Search for the ispapi whmcs registrar module and you'll be able to find the github repo. You may reach out to our Sales Dep. regarding prices. Prices depend always on the volume, so prices we show in public are probably not matching your situation. Hopefully people start upvoting the above feature request to make the premium domain integration of whmcs a better experience. Enjoy / HTH Kai
  3. No, we are writing Modules/Addons for WHMCS. The code is finally a mixture of our produced code that is in some cases using functions / classes of WHMCS (e.g. https://classdocs.whmcs.com/8.5/index.html). Therefore, it is necessary to bootstrap the necessary underlying system (or a subset of files or so), so that phpstan is able to identify return types, parameter types etc. and to use it for validation. I am not interested in analysing WHMCS itself (that would even mean doing reverse engineering - which is prohibited by WHMCS' EULA.
  4. Hi there, I am interested in using phpstan for static code analysis, but wasn't able to get WHMCS source files bootstrapped. Does anyone of you guys have experience and a working setup? If I try to load/bootstrap the init.php, I am ending in "Fatal error: Uncaught Error: Class 'Hoa\Event\Bucket' not found ...". This is independent of dealing just with freshly unzipped archive or using source files of a installed whmcs system. When just loading files from includes directory, not all functions I am looking for are finally present. ioncube loader is installed and up & working in our setup. Thanks Kai
  5. The hexonet provider module provides this. Just use the one we, the Hexonet team, maintain. https://github.com/hexonet/whmcs-ispapi-registrar#readme Bulk update can be done over our own frontend to enable transfer lock for all existing domains.
  6. I can confirm that this got finally patched. Sorry for the delay in this matter.
  7. I checked their changelog 'til RC1 and CORE-14055 did not appear. That's why we did not start testing this feature. Let me check this within the rest of this week, latest starting next week. Kai
  8. Thanks Fraz. Great to hear that they finally dive into patching our bug report regarding premium transfers. How much money Resellers may have lost with other registrars who just accepted premium transfers (for standard domain pricing)? Anyways, one little step in a better world.
  9. Both system's core had been authored initially by our former CEO and are therefore very similar. Still/Of course they differ in point of command names and available features, but this might be very adaptive and might allow picking the best of the systems and to mix that up. The final idea is therefore of course to merge there as far as possible to save man power, efforts etc. But this will be a long way.
  10. Hi @incubatec We introduced the encryption with v6 of our WHMCS Module which happened on July 2021. The "already introduced ... earlier" happened somewhere below version 5, so I guess in Q1 2021. The company HEXONET GmbH is no longer existing. The former HEXONET Team has merged with the one from Key-Systems after the acquisition. HEXONET and RRPproxy are just different brands related to the company Key-Systems GmbH (-> commercial register). Still, these brands have their own Backend System API and separate integrations. HTH
  11. Let me address that there are no pricing differences between RRPproxy and HEXONET (price harmonisation). If you need better prices because of a higher volume, you can always reach out to us.
  12. Hey @incubatec I highly appreciate this feedback, even though negative and it sounds like it comes a bit late then for us. The world is looking more worse as it really is. Still, I fully agree and understand your point (what you addressed in your initial post which you updated). What you are addressing has nothing to do with the CentralNic acquisition and the module encryption. We have had this introduced already before encrypting. My Department is completely working in self-responsibility to drive our Integrations to the best user experience, so no one is currently leading decisions from top to bottom regarding features and priorities in general. So, my fault when it comes to such issues. This has been immediately patched in v7.2.13 and I spent also a configuration option as mentioned to toggle this on and off (by default off). My interest is just to try explaining that there had not been a bad intention behind all this, just being a result of high work load on my desk and applying things sometimes too quick. The RRPproxy/Key-Systems module isn't affected at all by this - it is not encrypted, and not having this mechanism in place. Why have we started encrypting the HEXONET Module? Well, we are always interested in extending our modules with feature requests that we received. We noticed other registrars following us immediately after and that's one of the main reasons behind this. But again, introducing the encryption was not related to what you addressed in your initial post (we introduced it already earlier). It still doesn't change things for our customers - we are there, if you need something. If you have some customization in place, address it to us - we'll help out by extending our module or to find a way for you. Customer support is something we are known for and this won't change. The main reason for encrypting is that developing WHMCS modules is legal straight hike as WHMCS itself is closed-source. We try our best to follow public documented ways and review also for that. But checking every case is impossible in addition if it comes to workarounds for WHMCS Core bugs. I am open to share the exact reason for the encryption, but not in public - it is not a secret, but still nothing I want to share here. Just contact me by PM for details. Again sorry for this issue, my pardon. Kai
  13. That's offered by HEXONET and RRPproxy. But please use not the WHMCS built-in Modules.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use & Guidelines and understand your posts will initially be pre-moderated