swinghosting

"Solution" found and discussed here: http://forum.whmcs.com/showthread.php?107858-Upgrade-hangs-at-step2&p=457663#post_457563

Yes, that must have been it. The upgrade was successful after creating a new installation, installing, importing the old database, running the upgrade, performing a few db commands manually, then running the upgrade again. Lots of hoops. Guess I'm spoiled by…pretty much every other CMS on the planet with their single-click upgrades.

Thank you for that suggestion! We get actual error messages now: ######################################################################## ### ERROR ### ######################################################################## Unable to connect to the database. in /public_html/account/includes/classes/WHMCS/Database.php at 0 #0 /public_html/account/includes/classes/WHMCS/Database.php(0): WHMCS\Database::connect() #1 /public_html/account/includes/classes/WHMCS/Database.php(0): WHMCS\Database->connect() #2 /public_html/account/includes/classes/WHMCS/Utility/Bootstrap/Installer.php(0): WHMCS\Database->__construct() #3 /public_html/account/vendor/illuminate/container/Illuminate/Container/Container.php(498): WHMCS\Utility\Bootstrap\Installer::WHMCS\Utility\Bootstrap\{closure}(Object(WHMCS\Container), Array) #4 /public_html/account/vendor/illuminate/container/Illuminate/Container/Container.php(425): Illuminate\Container\Container->build(Object(Closure), Array) #5 /public_html/account/vendor/illuminate/support/Illuminate/Support/Facades/Facade.php(208): Illuminate\Container\Container->make('db') #6 /public_html/account/includes/classes/WHMCS/Installer/Installer.php(0): Illuminate\Support\Facades\Facade::__callStatic('make', Array) #7 /public_html/account/includes/classes/WHMCS/Installer/Cli/Application.php(0): WHMCS\Installer\Installer->runUpgrades() #8 /public_html/account/install/bin/installer.php(0): WHMCS\Installer\Cli\Application->upgrade() #9 {main} ######################################################################## I see the 'cannot connect to db' piece. Note that version 5.3.14 is running just fine.

I have the same problem with getting stuck on step 2. I added `$display_errors = E_ALL;` to my configuration file. The installer log only has: [2016-03-25 12:15:24][WHMCS Installer] DEBUG: Installer bootstrapped [] [2016-03-25 12:15:28][WHMCS Installer] DEBUG: Installer bootstrapped [] [2016-03-25 12:15:28][WHMCS Installer] INFO: Previous install detected [] [2016-03-25 12:15:28][WHMCS Installer] DEBUG: An upgrade from 5.3.14-release.1 to 6.2.2-release.1 will be attempted. []

I have the same issue, except I'm trying to upgrade to 6.2.2

I'm wondering that, too. You'd think WHMCS would have a page saying something one way or the other. If they do, it's not able to be found when searching for whmcs paypal "IPN endpoints" "SHA-256"

Status doesn't appear to enter into the equation.

My issue regards the admin.

I believe I changed the invoice # on one or two a few years ago, but there are several that sort to the top inappropriately. It does look like they are the only ones. Regardless, clearly they should sort by the id #, rather than some invisible value.

Perhaps elsewhere, but at least on the invoices page, when you sort by invoice #, they are out of order. "5, 3, 192, 187, 290…" This is NOT a "feature request," as anything created sequentially with sequential numbers should obviously be able to be displayed sequentially. This is one of those really annoying things about WHMCS where I just stare dumbly and go, "Really? ..... Really?"

A couple times a year, I see a hacking attempt. The exact method differs, but they always start by creating a user account/order. I modified my template's cart template to show only a link to the login page if user is not logged in. Unfortunately, that doesn't do anything against attackers because WHMCS allows them to create an order directly by submitting POST data. The log file for a recent attack looked liked this: [26/Oct/2014:08:26:09 -0500] "GET /account/cart.php?a=add&domain=register HTTP/1.1" [26/Oct/2014:08:26:09 -0500] "POST /account/cart.php?a=add&domain=register HTTP/1.1" [26/Oct/2014:08:26:10 -0500] "GET /account/cart.php?a=confdomains HTTP/1.1" [26/Oct/2014:08:26:10 -0500] "POST /account/cart.php?a=confdomains HTTP/1.1" [26/Oct/2014:08:26:10 -0500] "GET /account/cart.php?a=view HTTP/1.1" [26/Oct/2014:08:26:11 -0500] "POST /account/cart.php?a=checkout HTTP/1.1" [26/Oct/2014:08:26:13 -0500] "GET /account/cart.php?a=complete HTTP/1.1" [26/Oct/2014:08:26:13 -0500] "GET /account/viewinvoice.php?id=258 HTTP/1.1" [26/Oct/2014:08:26:14 -0500] "GET /account/clientarea.php HTTP/1.1" [26/Oct/2014:08:26:14 -0500] "POST /account/dologin.php HTTP/1.1" [26/Oct/2014:08:26:15 -0500] "GET /account/clientarea.php HTTP/1.1" [26/Oct/2014:08:26:15 -0500] "GET /account/clientarea.php?action=details HTTP/1.1" [26/Oct/2014:08:26:15 -0500] "POST /account/clientarea.php?action=details HTTP/1.1" [26/Oct/2014:08:26:16 -0500] "GET /account/clientarea.php?action=details HTTP/1.1" After creating the order, they attempted an SQL injection, which doesn't work, fortunately. They are able to do this via scripts without logging in, despite the fact that if you go to any of these pages on my site, all you get is a link to login! 1. Good God, why does WHMCS not use nonce? → That would completely solve this, yes? 2. WHMCS should realize this activity is too fast for a human to complete. → Sure, script kiddies would just add some dely…but still, this would be a good idea. 3. Why, oh why, does WHMCS not randomized table prefixes? → That way, any SQL injection attempt that managed to execute somehow would not know the table names. sheesh. 4. It would be nice if WHMCS had an option to disable anonymous orders. Is there a modification I can make to achieve this? → If WHMCS used nonce, my existing modifications would be sufficient, but my changes are useless if an attacker can simply submit an order directly via POST.

A couple times a year, I see a hacking attempt. They always start by creating a user account/order. I modified my template's cart template to show only a link to the login page if user is not logged in. Unfortunately, that doesn't do anything against attackers. Today, a hacker created an order without logging in and then attempted SQL injection by changing profile data. Log looked liked this: [26/Oct/2014:08:26:09 -0500] "GET /account/cart.php?a=add&domain=register HTTP/1.1" [26/Oct/2014:08:26:09 -0500] "POST /account/cart.php?a=add&domain=register HTTP/1.1" [26/Oct/2014:08:26:10 -0500] "GET /account/cart.php?a=confdomains HTTP/1.1" [26/Oct/2014:08:26:10 -0500] "POST /account/cart.php?a=confdomains HTTP/1.1" [26/Oct/2014:08:26:10 -0500] "GET /account/cart.php?a=view HTTP/1.1" [26/Oct/2014:08:26:11 -0500] "POST /account/cart.php?a=checkout HTTP/1.1" [26/Oct/2014:08:26:13 -0500] "GET /account/cart.php?a=complete HTTP/1.1" [26/Oct/2014:08:26:13 -0500] "GET /account/viewinvoice.php?id=258 HTTP/1.1" [26/Oct/2014:08:26:14 -0500] "GET /account/clientarea.php HTTP/1.1" [26/Oct/2014:08:26:14 -0500] "POST /account/dologin.php HTTP/1.1" [26/Oct/2014:08:26:15 -0500] "GET /account/clientarea.php HTTP/1.1" [26/Oct/2014:08:26:15 -0500] "GET /account/clientarea.php?action=details HTTP/1.1" [26/Oct/2014:08:26:15 -0500] "POST /account/clientarea.php?action=details HTTP/1.1" [26/Oct/2014:08:26:16 -0500] "GET /account/clientarea.php?action=details HTTP/1.1" After creating the order, they attempted to get admin login info by changing their user data (excerpt from WHMCS User Details Change notification email): Address 1: 'dm' to 'AES_ENCRYPT(1,1), address1= (SELECT MIN(username) FROM tbladmins)' Address 2: 'dm' to 'AES_ENCRYPT(1,1), address2= (SELECT MIN(password) FROM tbladmins)' Before I get to customizations to guard against this, there are three issues I see immediately: WHMCS should realize this activity is too fast for a human to complete. Good God, why have they still not implemented randomized table prefixes?! Good God, why are they not using nonce? It would be nice if WHMCS had an option to disable anonymous orders. Is there a modification I can make to achieve this? If they used nonce, my existing modifications would be sufficient, but my changes are useless if an attacker can simply submit an order directly via POST. Thanks for any suggestions!

Yep. That added a (nearly invisible) "Don't show again" checkbox to the popup. Thanks, Bubka!

I just upgraded to 5.2.4. When I log in to the admin, a popup tells me a 5.2.3 update is available. 1. I have a newer version than it's announcing. 2a. The popup is highly annoying; 2b. the close button is barely visible; 2c. I can't turn it off. How do I get rid of it?

In Automation Settings > Domain Reminder Settings I have the first reminder set to email 60 before expiry. Such an email was just sent from the system. It should say the domain will expire in 60 days, but it reads, "The domain name listed below will expire in 86 days." The template contains: The domain name listed below will expire in {$domain_days_until_expiry} days.