Jump to content

WHMCS David

WHMCS Developer
  • Content count

    16
  • Joined

  • Last visited

  • Days Won

    1

WHMCS David last won the day on December 6 2017

WHMCS David had the most liked content!

Community Reputation

11 Good

About WHMCS David

  • Rank
    WHMCS Staff

Recent Profile Visitors

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

  1. WHMCS David

    New WHMCS name spinner

    Hi All, I would like to elaborate on the mechanics of domain lookup and I hope to clarify some possible misunderstands or misgivings: --- The WHMCS Namespinning provider works in the same way that a registrar-drive provider works: For the availability check, it will submit the search to the API service, the response from the service will contain a value that indicates the status of domain: 1 registered 2 not registered 3 reserved 4 unknown 5 tld not supported If the status is 4 or 5 the WHMCS will do a subsequent lookup directly to the whois server based on dist.whois.json/whois.json to try to get a more accurate status. -- @brian! That could be the reason that lookup did not function properly when those files were absent. For the suggestions, for cases 4 & 5 the subsequent lookup is only done on the 'add to cart' action due to the significant impact on performance. ...this is the same behavior as if one has selected Enom as the lookup provider. --- The service that powers the WHMCS Namespinning provider has comparable TLD support across the gTLD spectrum as Enom. The ccTLDs support is less favorable at this time, but will be improved in the future. But just a quick revisit: if an unsupported ccTLD is queried, the fallback to the WHOIS servers goes into effect; again this is pre-existing design that was implemented when name spinning with Enom was first introduced. --- We have made significant efforts to partner with a domain name industry expert specifically to address two issues notable issues: - poor performance and quality of registrar-drive suggestions - latency of having accurate data in dist.whois.json vis-a-vis the WHMCS development cycle + unannounced registry changes + new TLDs If WHMCS Namespinning is failing to address those issues, then clear and constructive feedback would greatly be appreciated. --- It is true that the service is white labeled. This is not an uncommon business practice, whether it is at the behest of the integrator (WHMCS), the service provider, or both. There's no secret here, it's a business decision; I'm not sure I understand how that decision affects the functionality of the feature? --- I think it makes perfect sense for a service provider, registrar, and registry to monitor the query traffic for their APIs. Those analytics and the aggregate business intelligence produced can help improve the value of their services, products, any collaboration with their peers around governance and policy. I do not understand how that would be either improper or maligned? The service powering WHMCS Namespinning does not receive the identity of your WHMCS instance; they cannot associate your business with the queries that your clients make based on any integration or exchange of information. As an aside, if one were to select a registrar as their lookup provider, where the API call must be authenticated with reseller credentials, it's possible that they may log correlative information of account + query. If that is a concern, then it would be a question best directed to the selected registrar since it falls within scope of their TOS, etc. --- If your theme and/or cart templates were capable of registrar-drive domain lookup and suggestions, they should support WHMCS Namespinning in the same respect. There might be other template changes that need to be incorporated to prevent general template compatibility; there is nothing unique about the way that the UI triggers or renders the results with respect to WHMCS Namespinning. It is a modular system that is decoupled between the UI and the backend functionality. --- If you are having issues, please let us know the specifics, either here or in a ticket so we can work towards a solution and/or elaborate on the current design. We think that WHMCS Namespinning is a better alternative to registrar-drive lookups & suggestions because if its performance and quality; it should be a much better experience for customers and present more opportunities for your domain sales over the Standard Whois option.
  2. Hi All, As a status update, we have not received any further actionable information from the IonCube team that would afford your systems the ability to run a single encoding in both the PHP 7.0 and the PHP 7.1 environment. In short, this means any immediate use of encodings that function in a PHP 7.1 environment will result in downtime for your production site while you redeploy your application software. There is no simple solution we can publish that provides the ease and flexibility that we have delivered throughout the WHMCS v7 series with automatic updates. We are currently developing and evaluating a number of solutions. Each provides a different balance of A) access to multiple encodings and access to future updates for those encodings, B) compatibility for the underlying environment, and C) behavior of the application when the environment is changed (without changing to the requisite encodings). Please keep in mind that any solution from WHMCS will only be able to accommodate WHMCS distributed software and any 3rd-party code will need to be updated on your system using new encodings by the original author: again, this is due to the lack of simultaneous support for PHP 7.0 and PHP 7.1 environments when using the current IonCube encoder. Our current target is to provide a viable, balanced, and sustainable solution to customers in the first quarter of 2018. Regards, -David
  3. Hi xyzulu, Thanks for the input/feedback. I understand your perspective and can imagine how it might be shared by others in this thread. Given that, I'd like to touch on the points you raise. Maybe...However, Ioncube provides products that serve the PHP development community, it's in their interest to create the most viable solutions for their clients. I see no reason to either doubt their evaluation/deliverable related to the technical challenges when working with PHP internal engine changes, or malign their efforts. Regardless, it's a challenge that we must overcome and I'm confident we can address it. Our team has performed several rounds of testing to confirm these results (as well as the aforementioned communications with Ioncube). The following screenshot is directly from the README.txt within the Encoder v10 download. Note the 71_10.0 binary is capable of encode any PHP syntax, however the consumer/server is require to have PHP 7.1, not just any 7.x. What is implied, and thus required time for exhaustive testing & confirmation, is that the 56_10.0 binary produces encodings with the same support as the 56_9.0 binary; that the current documentation is actually meant to say "PHP 5.6 or PHP 7.0", not "PHP 5.6 or newer". It is my pure speculation that this is simply a hold-over from the Encoder v9 documentation (which reads the same, verbatim) that was authored & published before PHP 7.1 was stable. So, at least at that time, the behavior and intent were aligned. We are working hard to find a resolution that is suitable for production environments and incurs the least amount of effort for our clients. We will post further updates as we have them. Regards, -David
  4. Hi All, Providing new PHP version support in WHMCS is a continual goal for us and so we were pleased to see that Ioncube announced a new encoder. The new Ioncube Encoder v10, along with Loader v10, allows encoded files to work in PHP 7.1, the latest stable version available for server environments. Prior versions of the Encoder have afforded WHMCS the ability to provide cross-version compatibility, however, currently this is not viable with Encoder 10, but we're working on it. In short, developers cannot produce a single set of encoded files that work within both PHP 7.0 and PHP 7.1 server environments. If developers wish to provide support for PHP 7.1 and PHP 7.0, they must produce and publish two different sets of encoded files. Any attempt to alter the PHP environment requires both a server PHP and a software deployment change in tandem. This complicates the publication and distribution processes. But more so, affects our ability to provide a small, streamlined, and low-risk experience. We have already started internal testing, utilizing Encoder 10 and Loader 10 with a PHP 7.1 environment. We are also actively pursuing two other courses of action. First, we have reached out to Ioncube to understand all facets of Encoder v10 and potentials for cross-version compatibility. Second, we are researching the technical options available for future product updates that will allow you to update your server PHP version with minimal impact to visitors & clients. We will post further updates as we have them. Regards, -David
  5. WHMCS 7.1 RC Now Available We are pleased to announce the release of WHMCS 7.1 RC 1. This version contains further refinements to the fantastic features of 7.1, which includes an all new Admin Dashboard, Premium Domains, Stripe, Automation Task Status Tracking, New Product & Domain Statuses and more... The RC is available from today for all WHMCS users. Users of WHMCS 7 can download the update using the Automatic Update utility and users of earlier versions can download it here. As always, please remember this is a pre-production release and as such is not recommended for production use. Download | Release Notes | Upgrade Instructions | Changelog What's New in WHMCS 7.1? To find out more about the new features and functionality in WHMCS 7.1, visit the WHMCS 7.1 Preview Site
  6. WHMCS Version 7.0.1 Released We are pleased to announce the release of WHMCS 7.0.1. This is a maintenance release for the 7.0 series of WHMCS that includes bug fixes & other updates. WHMCS v7 provides the WHMCS Update Utility which makes updates a breeze! Simply navigate to Utilities >> Update WHMCS to begin the process. We are also providing both a full release and incremental patch set upgrade for manual updates. If you are running the immediate previous release 7.0.1, you can use the incremental patch set to upgrade. Get the Update | Release Notes | Upgrade Instructions | Changelog
  7. We have become aware of a functional issue in the 5.3.12 release published on Wednesday, 25 Feb 2015, which affects the Contact Us page if the Pre-Sale Form Destination is not configured to use a specific department. Resolution Under the Setup > General Settings > Mail tab > Presales Form Destination choose a specific department. Then, clear the 'Presales Contact Form Email' field. Alternatively, we are releasing a hot-fix patch which corrects the premature validation error when a department is not associated with the Contact Us form. To apply the hot-fix, see below. Applying the Hot-Fix To apply the fix, download the zip file from the link below. Extract the contents, a single file named “contact.php”, and upload it to the base folder of your WHMCS installation. whmcs_CORE-8346_Contact-Form-Shows-Validation-Error.zip Note: This file is only valid if you are running Version 5.3.12.
×

Important Information

By using this site, you agree to our Terms of Use & Guidelines