Whmcs Addons

[Heartbreak Writhe]

Dependingon your purpose, you may wish to use product addons or you may wish to use configurable options. Configurable options on products allow you to give your clients ways to alter the price of that product while product addons do not.

For product addons, WHMCS uses the prorata date setting from the associated parent product or service instead of a separate date. WHMCS will then bill for the product addon and the parent product or service on the same day of the month for their respective billing cycles.

Click a predefined addon to automatically prepopulate the Create New Addon settings with the appropriate values. For example, clicking WP Toolkit Deluxe (cPanel) will configure all of the necessary settings for an addon to sell WP Toolkit Deluxe on your compatible cPanel servers.

Login as a customer, order the add-on and see if you are asked to provide the required custom field. I have tried six template with numerous carts and the checkout completes without requesting the custom field at any time.

The Product Addon Custom Field functionality was implemented solely with third-party developers in mind. The custom fields are designed to compliment the Service Property functionality and allow Product Addons to store data relevant to their parent Product/Service. You can read more about this at _Properties

At this time, Product Addon Custom Fields are not designed to be displayed in the shopping cart area, and are not considered during checkout. This is why required fields can be skipped without issue - they are not designed for information input by customers going through the checkout process.

It just doesn't make any sense to have product add-ons (which I use extensively) i.e. to add domains to an existing hosting account, and I am not able to ask the customer the name of the domain they wish to add. And there are many other scenarios. Totally illogical to have it's functionality in the setup and not make it appear in the shopping cart.

We can configure to add text, textarea, dropdown boxes, tick boxes etc, and after all of that, none of it will be seen by the customer ? Come on WHMCS what is going on with your logic on any of this?

I was trying to use custom fields in product addons for installation service of SSL. I was trying to collect the required info to create the CSR. After a couple of weeks with an open ticket I got the same canned response as above.

I came here now researching this exact same issue. I'm like HUH!?!??! REALLY??? What the hell is the point of custom fields and asking you if they must be required or not and only visible to admins or not if this is not going to work at all from the front-end.

As far as I'm aware it's still unresolved, and it seems that as far as WHMCS cares this is how they want it to be so I doubt they'll ever change it. I do wish they would alter the Addons Custom Fields page to make it obvious it's useless rather than everyone who attempts it googling and ending up on this thread

Ridiculous, still the same in 8.1.1 - do they take any notice of their customers requests?

It seems as if the developers have only the most basic grasp of how their product could be used and no imagination or vision

They will tell you to submit a feature request, refuse to approve the feature request for weeks or even months on end, restrict who can vote on said feature request and then when the next person that asks they will say its not implemented due to lack of votes/interest/demand - or more likely say nobody has ever mentioned it before

That this is still not being worked on is downright atrocious. What's the expectation here? A module dev will fix this? Seriously where the heck does the monthly license fee go to if not to some development. Worse still, I looked at the output of $addon and it does not contain any data on the custom fields, so where are they contained in then? What's the point of them exactly, you implemented the feature for the API users or what? Honestly if I shake my head any harder it'll come off.

Seriously trying not to swear here, but you put in something so someone presumably can store some data into these addons, that was worth the effort because someone complained hard enough or what, but properly implementing this and not just leaving as a massive tease was not worth the effort? WTF

I recently relocated the WHMCS license from an old domain to a new one. I followed the move process according to the instructions, and the license information shows correct details for IPs, domains and directory. The old WHMCS directory is completely offline, and has a 301 redirect to the new location. I was using Chrome for all of this, so thinking it might be a cache issue, I then used Firefox, which has never visited this new site. Same results. Every other page I attempted to access in the admin panel appears to be okay.

When I log into my 'Members Area' of the whmcs.com site, I see the same information I have seen since I made the change from the old domain name. The Valid IPs, Valid Domains and Valid Directory are all correct. The license is an owned license. I clicked the 'Click here to enter a new license key' link in the error message, and reentered the information. I also tried reissuing the license again, but the same 'Invalid License' message keeps showing up.

So what does this mean? I no longer even use eNom, and had deactivated that module. Even if I did, why would WHMCS 7.5.1 have any core modules encoded by an older version of ionCube Encoder? While this page: _7.0-7.4_System_Requirements only provides requirements for WHMCS up to version 7.4, it would make sense that versions after 7.4 would not regress to need PHP 5.x.

@wsaThis issue was reported to our development team and is currently staged for release. Switching to PHP 5.6 or 7.0 will allow you to deactivate the module without encountering any errors in the meantime.

@WHMCS Alex I used to manually update, although ever since the Automatic Updater was released, I have used it every time. It seems odd that this module would have been "overlooked" by the Automatic Updater, as eNom is important enough to WHMCS that you offer a link to create a new account with them if someone does not have an existing account. Anyway, I renamed the file in question, and the reported error appears to be resolved. Thank you.

@WHMCS Alex The issue of 'outdated versions of modules' seems to be an ongoing one. I found another instance of it when I tried to look at a product. Since I used the automatic upgrade process to perform all upgrades since that process was introduced, what would you recommend? I had not planned on spending another $99 for support starting this year, and quite frankly will be steamed if I have to pay it just to fix bugs that the team introduced into WHMCS due to a poorly designed upgrade automatic process.

@WHMCS Alex Looks like it just gets worse. If you look at the attachment, you will see there are 845 files in my installation with incompatible encoding on PHP 7.0. That seems to me to be more than an oversight.

@WHMCS ChrisD Hello Chris - There are a bunch, as I mentioned previously; however, I did notice something odd as I looked through the list of files. It seems every single one listed in the incompatible list has the old account info shown.

Would it be safe to delete the contents of the table tblioncube_file_log? Everything in it pertains to where WHMCS used to be installed. The old account still exists on the same server (same IP address), although all of the files and database have been removed from the account where WHMCS used to be hosted and moved to the new account.

@WHMCS ChrisD I went ahead and emptied the table tblioncube_file_log, and of course now there are 0 incompatible encoding errors listed. That said, when I attempt to go to Setup->Products/Services->Domain Registrars, I see this:

As I mentioned previously, none of this makes any sense, as all upgrades have been performed using the automated update procedure since that process was released. This appears to be an error of some sort related to WHMCS doing housekeeping during the update process.

During the v7.6.0 update, a one-time routine will inspect and attempt to the following modules due to discontinued service by the service provider. Removal will only occur if it is not actively in use. The Activity Log will have a list of any removals. As well, if removal is not performed and the module remains in your installation, an email will be generated for all full admins so that further investigation can be performed. Inspection will be performed for the following modules:

3a8082e126