Cannot Configure Addon

[JayBird]

I tried to add a Mailchimp API key into the Mailchimp addon, but I get this message when I navigate to xxx/admin/configaddonmods.php I get this message:

Oops!

Something went wrong and we couldn't process your request.

Please go back to the previous page and try again.

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.

Any help with helping me resolve this would be appreciated.

[WHMCS Alex]

Hello @JayBird

Please follow this documentation to obtain the full error here: http://help.whmcs.com/m/troubleshooting/l/678235-troubleshooting-a-blank-page-oops-error-message

Once you have this, please post it here and I can advise further.

[JayBird]

Hello Alex,

I would love to be able to provide the information you asked for; however, now I am getting this message about an invalid license: http://prntscr.com/jxkv61

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.

Regards,
Jay

[JayBird]

Well, the license issue seems to have disappeared as unexpectedly as it appeared. Anyway, I was able to capture the error message, and here it is:

 

Oops!

Something went wrong and we couldn't process your request.

Please go back to the previous page and try again.

Whoops\Exception\ErrorException: The file /modules/addons/enomnewtlds/enomnewtlds.php was encoded by the ionCube Encoder for PHP 5.0 and cannot run under PHP 7.0.
Please ask the provider of the script to provide a version encoded with the ionCube Encoder for PHP 5.6. in Unknown:0
Stack trace:
#0 /vendor/whmcs/whmcs-foundation/lib/Utility/Error/Run.php(0): WHMCS\Utility\Error\Run->handleError(16, 'The file /home/...', 'Unknown', 0)
#1 [internal function]: WHMCS\Utility\Error\Run->handleShutdown()
#2 {main}

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: https://docs.whmcs.com/Version_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.

[wsa]

I open a ticket about this long time and I try now on my dev machine still the same problem

ArgumentCountError: Too few arguments to function newtlds_deactivate(), 0 passed and exactly 1 expected in /home/user/public_html/modules/addons/newtlds/newtlds.php:0
Stack trace:
0 /home/user/public_html/admin/configaddonmods.php(0): newtlds_deactivate()
1 {main}

[WHMCS Alex]

Hello @JayBird

The error you have provided indicates you have an outdated version of this module, and as you are not using this module, you can delete it to resolve this issue.

How did you update to version 7.5? Did you update manually or using the Automatic Updater?

 

@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.

[JayBird]

@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.

[JayBird]

@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.

 

Whoops\Exception\ErrorException: The file public_html/billing/modules/servers/hostingcontroller/hostingcontroller.php was encoded by the ionCube Encoder for PHP 5.0 and cannot run under PHP 7.0.
Please ask the provider of the script to provide a version encoded with the ionCube Encoder for PHP 5.6. in Unknown:0
Stack trace:
#0 public_html/billing/vendor/whmcs/whmcs-foundation/lib/Utility/Error/Run.php(0): WHMCS\Utility\Error\Run->handleError(16, 'The file /home/...', 'Unknown', 0)
#1 [internal function]: WHMCS\Utility\Error\Run->handleShutdown()
#2 {main}

[JayBird]

@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]

@JayBird what files are mentioned in the incompatible encoding?

[JayBird]

@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.

For example, I would expect to see this: /home/newaccountname/public_html/billing/admin/configproductsconfoptions.php, yet instead I see this: /home/oldaccountname/public_html/billing/admin/configproductsconfoptions.php

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.

[JayBird]

@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:

Oops!

Something went wrong and we couldn't process your request.

Please go back to the previous page and try again.

Whoops\Exception\ErrorException: The file /public_html/billing/modules/registrars/distributeit/distributeit.php was encoded by the ionCube Encoder for PHP 5.0 and cannot run under PHP 7.0.
Please ask the provider of the script to provide a version encoded with the ionCube Encoder for PHP 5.6. in Unknown:0
Stack trace:
#0 /public_html/billing/vendor/whmcs/whmcs-foundation/lib/Utility/Error/Run.php(0): WHMCS\Utility\Error\Run->handleError(16, 'The file /home/...', 'Unknown', 0)
#1 [internal function]: WHMCS\Utility\Error\Run->handleShutdown()
#2 {main}

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.

[brian!]

if it helps, the DistributeIT module was deprecated back in 2013 (v5.2.3) - hence the PHP5 encoding error...

Quote

Case #1817 - Added TPP Wholesale Domain Registrar Module which replaces DistributeIT, PlanetDomain & TPPInternet

if you aren't using it, you can safely delete it... the v7.6.0 release will eventually remove it anyway, but you might as well do it now manually.

Quote

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:

• DistributeIT
• GlobalSign OneClick SSL
• Amazon Simple Pay

 

[JayBird]

@brian! It doesn't.  Here I was thinking WHMCS would have been improved over the years, and yet it looks like the team just got lazy. I don't really care about a stray file here or there, as long as it does not lead to any security or stability issues. That said, the WHMCS team is a day late and a dollar short with this expected change in 7.6.0. I just had to buy another year's worth of support to be able to again download the version already installed on my server. Funny thing is, I noticed one of the files raising an error was 5 bytes different in size. When I inspected the file, I see that the file from my site is version 7.5.1-release.1 and is dated 17 Apr 2018. Yet the version in the new download from the WHMCS website was version 7.5.1-release.2, and dated 18 Apr 2018. This was not the only change; the encoded portion of the file was different as well.

Looks like an oversight on someone's part at WHMCS, because the release.2 version of the file SHOULD have been added to my site at during the last upgrade (since my site was up to date according to the version information on the WHMCS dashboard. Since it appears there were changes to 7.5.1 after the initial release, then I believe any such changes, however minor, should have been pushed out as a new upgrade with a new version number. Better that than have a mess like this.

[JayBird]

As an FYI, I also found a file folder dated 30 Oct 2011. This folder was modules/servers/hostingcontroller. The one file inside that folder had the same date.

[brian!]

9 minutes ago, JayBird said:

Here I was thinking WHMCS would have been improved over the years, and yet it looks like the team just got lazy.

I think the reason there were two releases of v7.5.1 was because in release1 they missed out the todolist.php file (which had no changes from v7.5 but was omitted from the update)... and WHMCS took the unusual step (I can't remember them doing it before) of updating the same core download file... usually they would hotfix it, or do a maintenance release.

19 minutes ago, JayBird said:

Looks like an oversight on someone's part at WHMCS, because the release.2 version of the file SHOULD have been added to my site at during the last upgrade

AFAIK the only difference between the files was the omission of the todolist.php, but if you say there were other changes, then i'll take your word on it... but yes, I would have thought the autoupdater would have used r2.

21 minutes ago, JayBird said:

Since it appears there were changes to 7.5.1 after the initial release, then I believe any such changes, however minor, should have been pushed out as a new upgrade with a new version number. Better that than have a mess like this.

I think v7.5 was their first version to actively remove deprecated files, so it was no surprise that there may have been some missing from that list... i'd have been more surprised if they had got it completely right first time.

[JayBird]

4 hours ago, brian! said:

i'd have been more surprised if they had got it completely right first time.

Let's be realistic. This isn't some new application, this is a seasoned product. Not well managed, but a cash cow for somebody.