Jump to content

WHMCS David

WHMCS Developer
  • Posts

    29
  • Joined

  • Last visited

  • Days Won

    3

WHMCS David last won the day on March 23 2020

WHMCS David had the most liked content!

1 Follower

About WHMCS David

Recent Profile Visitors

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

WHMCS David's Achievements

Junior Member

Junior Member (1/3)

13

Reputation

  1. Hi Hostinfacil.co This file may be removed. We have identified this and a few others like it following the beta release. We will have a routine to clean these files on update to 8.6.0 RC. While I can ensure every file we once distributed but is no longer distribute is safe to remove, we cannot guarantee that every file you find within your system was placed there by the WHMCS core product. It is possible that unmanaged files in your installation may be from 3rd-party files (and sometimes in the case of modules, they might have the same base name). Please review each file and retain a backup prior to removal. The PHP Version Compatibility Utility has limited support for the ionCube Online Encoder; we have seen several variants over the years. We look to improve our support with each sample/iteration we receive. Normally the pre-production cycle for WHMCS is 4-6wks. Given this, the expectation is that 8.6.0 GA will arrive by the end of October 2022. Cheers David
  2. @RyanK it is not possible in the current implementation to use service.id to look up the tenant usage. Using that service field would be extremely challenging because the server almost certain doesn't know what auto incrementing id in WHMCS's database table tblhosting is for a service it is hosting (vps/vm/shared/otherwise). There must be a common field that is known to both the WHMCS service and the remote server (ala the server module). In WHMCS 7.9, the feature is meant to use the service field 'domain'; more below. "MetricProviderUniqueIdentifierField" doesn't exist, only "ListAccountsUniqueIdentifierField". "ListAccountsUniqueIdentifierField" is pretty new and will be itemized in the documentation revisions I spoke about in my last post. At this time of this writing, Usage Billing's utilization of "ListAccountsUniqueIdentifierField" was designed to support only the value of 'domain', but with future considerations for other service fields. If this metadata key is not present, the core logic should implicit use that field. If that field in the service is empty, the system will assume there is no tenant stats recorded to map to (and thus nothing will be rendered on the service page). [fwiw, there was a bug in pre-production that affected this behavior; make sure you're running the latest 7.9] At this time you must have a value in service.domain and it must be a key of the array returned by MetricInterface->usage() for the feature to work.
  3. Hi @RyanK Thanks for the feedback. Yes, the documentation with respect to what you mention, as well as what was discussed with @Kamran /this thread earlier, will be updated to clarify these new features.
  4. Hi @Kamran, Glad you're making progress. The TYPE_PERIOD_DAY should not be used at this time; only documented in the class level docs because it is reserved for a potential future design consideration. There are many factors to daily cyclical remote metrics that are not in the current implementation and first iteration of the Usage Billing feature.
  5. @Kamran, I'm glad to see that the usage is being stored based on the cron task. At this point, since the refresh is not triggering a method call, I would guess that there's something not aligned with the service and the server. Please try something like the following: select id, server, domain, username from tblhosting where domain = 'kamran2.com'; You should end up with just one record, and it should show the value tblhosting.server as 4 (as indicated in by your output of tblserver_tenants), and the tblhosting.id should be the id the same as the id parameter in the URL of the client service you are trying to observe the value in. You are running v7.9.1, right?
  6. Hi @Kamran First, in your main module file do you define a function ending in _MetricProvider ? This function is responsible for returning an object that implements \WHMCS\UsageBilling\Contracts\Metrics\ProviderInterface. It is this object that WHMCS will use to get metrics. Since you mention that the cron is calling usage(), I presume you have it...I just thought it was important to mentions since you do not. Following up to that, as well as your questions: The usage() method of the ProviderInterface is invoked during the cron in order to collect all stats at once. The idea is to have one method WHMCS invokes; if you server supports providing all "tenant" (aka user, or domain) stats at one API call, then great; otherwise your module can get the list of individual records however is most optimal for your API. The return value from usage()should be an array. The key of the array is the "tenant" and the value is an array of \WHMCS\UsageBilling\Contracts\Metrics\MetricInterface. WHMCS maps the service's domain field to the tenant. The tenantUsage() method is only invoked within the context of a service. So for example, when you are viewing a client's service in the admin area, and you press the refresh icon in the stats table, this will invoke that single method (and an other tenant stats on that server will not be refreshed...just the tenant associated with this service you are viewing). You do see the table for metric stats on the service page, right? If you don't see it, you might have an issue with the tenant value and how it is mapped to the service...It looks like you are using kamran@domain.com as the tenant value, but I suspect this is not the value in the service's domain field. My guess is this is your issue. I would not recommend trying to observe value change using $params. In fact, I don't even follow what you're doing. After running the TenantUsageMetrics cron task, or clicking the refresh button, you should see changes on the service's stats page. In your example, in the metrics method, you return an array with one Metric. This is good, however, you should not instantiate this with "new Usage(0)". Simply, do no pass that last parameter. The constructor for Metric will know how to treat "no usage data". This should not cause any issue, however, it's better to let the system deal with "no usage data" that stub it with "usage of zero". Hopefully this helps you get on your way. Let me know how it goes.
  7. 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.
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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.
×
×
  • 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