Jump to content

leopard16

Member
  • Posts

    22
  • Joined

  • Last visited

About leopard16

leopard16's Achievements

Junior Member

Junior Member (1/3)

0

Reputation

  1. Problem Solved! My hosting provider fixed the issue, it did have something to do with PHP. I believe there was an older version of PHP further up my root folder that was likely the issue. I think my previous WHMCS cron job was attached to that older PHP. Thank you all for your assistance.
  2. The WHMCS folde has a PHP.info file that says 7.4.19 as well. See this link here: WHMCS folder PHP This is the only way I believe WHMCS is running PHP v74. I was thinking along the PHP lines as well. Reason: My primary site and root public_html folder were running Wordpress PHP v7.2 in the past, this area was Wordpress. The WHMCS installation was in a sub-folder on this site primary site. WHMCS was only running PHP v7.1 and would break when I tried to upgrade. Both primary folder and WHMCS folder always had different PHP versions in the past. Anytime I tried to update both PHPs on both sites to match, there were issues. One site would break then the other would work. This time when I upgraded I wanted this fixed. Both Wordpress and WHMCS running the same PHP versions. So I upgraded both to PHP v7.4. It took support 3 different sessions and .htaccess rules to fix to get both sties to run on PHP v7.4 (although WHMCS never properly upgraded). I see no php.ini in root folder or public_html folder in either installation, not even the WHMCS folder either. There is a directive in both .htaccess files(for Wordpress and WHMCS folders) listing the PHP version . As far as me knowing which PHP each installation is using, I see CPanel says the site is at v7.4 plus Wordpress installation under server settings says it says v7.4.19 - : Wordpress installation> tools> site Health> server info> PHP version> 7.4.19 (Supports 64bit values). Not sure if this is taken from the .htaccess directive support added to Wordpress or not. Again, I don't see a php.ini file anywhere. My subfolder of this installation that is running WHMCS has a PHP.info file that says 7.4.19 as well. See this link here: WHMCS folder PHP This is the only way I believe WHMCS is currently running PHP v7.4. Still given that both installations I had were breaking each others site in the past becuase support back in the day added different PHP versions to each installation, and given that it took support 3 times to install the PHP and get ioncube loader installed this time, I am not sure they did this right. I don't see a php.ini file in any public_html folders. I can help but think somehow they botched up my PHP version on my installation. Perhaps I need to reach out to support and seek more help. They made me believe it was a WHMCS issue.
  3. Ooops, my first message about the issue being fixed was wrong. I was looking at wrong website. Your assessment was correct, originally I did overwrite all files except /vendor folder. This time, I deleted vendor folder, then uploaded new vendor from WHMCS download installation. Issue still persists.
  4. I re-uploaded the WHMCS installation files (v8.1.3) minus the /vendor directory and overwrote the old files. Issue still persists.
  5. I just upgraded my WHMCS from v7.3 to the latest version (8.0.13?). Plus I updated my hosting PHP version from 7.1 to 7.4. I upgraded via my CPanel, and Softalisoucs with the upgrade script, and then deleted the install folder after it looked like I was able to upgrade. Everything looked fine, till I went to my admin area, where my admin login page is not working. On my admin login page I see this error: Oops! Something went wrong and we couldn't process your request. Please go back to the previous page and try again. For additional assistance, please reference the WHMCS TroubleShooting Guide » So I enabled error reporting. Now I get this error: Fatal error: Declaration of WHMCS\Language\Loader\WhmcsLoader::load($resource, $locale, $domain = ) must be compatible with Symfony\Component\Translation\Loader\LoaderInterface::load($resource, string $locale, string $domain = 'messages') in /ROOT/public_html/clients/vendor/whmcs/whmcs-foundation/lib/Language/Loader/WhmcsLoader.php on line 0 and on the bottom of the Oops message this: Whoops\Exception\ErrorException: Declaration of WHMCS\Language\Loader\WhmcsLoader::load($resource, $locale, $domain = ) must be compatible with Symfony\Component\Translation\Loader\LoaderInterface::load($resource, string $locale, string $domain = 'messages') in /ROOT/public_html/clients/vendor/whmcs/whmcs-foundation/lib/Language/Loader/WhmcsLoader.php:0 Stack trace: #0 /ROOT/public_html/clients/vendor/whmcs/whmcs-foundation/lib/Utility/Error/Run.php(0): WHMCS\Utility\Error\Run->handleError(64, 'Declaration of ...', '/home2/pard671/...', 0) #1 [internal function]: WHMCS\Utility\Error\Run->handleShutdown() #2 {main} Not sure what happened, but it had to do with the upgrade or maybe the ioncube loader the hosting company had to add to my account for my PHP v7.4. Please advise where to check or what I can do to fix this.
  6. Nothing? No responses? Should I re-download the entire download and try again? Or is this another file that is causing this error? Can someone please point me in the right direction?
  7. I recently upgraded to WHMCS version 7.01. After logging in I see this error in my WHMCS panel: The file /MYPATH/whmcs/whmcs-foundation/lib/TwoFactorAuthentication.php is corrupted. I went to the downloaded folder and re-uploaded this file via ftp to hopefully fix the corruption and it still shows as corrupted. I do not want to attach my cell phone to my account. I can see the area: Setup> Staff management> 2 Step Authentication page shows fine. I am not sure if this actual file is corrupted and where I can get a no n-corrupted copy or if another file pertaining to this file is corrupted. Any ideas how I can get this notice to go away?
  8. OK my issue has been resolved. The problem for me is my PHP version on the cron did not match the PHP version on my server. Here is my hosting companies response to my issue: "Looking through the cron logs it appears that your cron is running reliably, but testing the cron I have found that it is not compatible with php 5.4, so I have updated the cron job to run with php 5.3 as follows: /opt/php53/bin/php -q /home/yourname/public_html/WHMCSFOLDER/crons/cron.php Additionally the path variable needed to be corrected at /home/yourname/public_html/WHMCSFOLDER/crons/config.php You may want to ensure that WHMCS is up to date on the most recent version so that it is compatible with more recent versions of PHP." I don't know when or how my PHP version and the WHMCS became uncompatible but it must have been during one of the recent updates within the past few months. This is when it broke. Anyway all is well now. I hope this helps others with the same issue!
  9. OK. I enabled Display Errors and ran it it my browser again. No errors show on the cron page. When I look at the source code of my cron.php page in the browser the code is blank. However, when I type the cron.php URL into the browser manually it does appear the cron.php page is runningthe tasks (its just not showing PHP debugging error like it should). Now, I can see in my WHMCS logs all the cron activities are running plus all my overdue invoices are now being generated. So at least when I manually enter the cron.php file into my browser, it does seem to be properly executing my crons. But I am not sure (unless I wait a few days) if the cron setup is running this cron file or if these crons were all the manual attempts I made the past few days. Should I try and re-upload my cron folder from my latest WHMCS update to make sure none of the cron files are corrrupt? Maybe during one of these updates one of my cron files became corrupted. It seems as if my server settings are proper, it seems as if my settings in WHMCS are proper, yet my cron.php file does not seem to be actived by my servers cron job which has the proper path according to my host. - - - Updated - - - My hosting company has a ticket created to see how I can enter the debug line you provided. Should I create a new cron or just add the debug to the back of the cron I already have set up? Where will the debug file be shown? I am running CPanel.
  10. I don't know about running the cron job manually, but I open cron job file location in my browser: http://www.MYDOMAIN.com/WHMCSFOLDER/crons/cron.php and when I do all I see it a blank page. I did change the file from 644 to 755 and I still see a blank page when I go to the cron file in my browser.
  11. I am running v6.1.1 and noticed a few months back (best I could tell it was likely August or Septemer) my invoices were not being generated automatically. I am not sure but I think the problem is likely one of the many udpates provided by WHMCS. If I visit the clients profile page and select: Generate Due Invoices it will then generate and e-mail the client the invoice. So I recreated my cron jobs (which were working fine for several years) to make sure it was not a server setting. I have read and followed these instructions: http://docs.whmcs.com/Invoicing_Issues but am still having issues. I contacted my hosting company and they tell me my cron paths are correct for their server. In the Invoicing Issues instructions it says this: If the cron still doesn't complete with the increased memory limit please ensure display_errors is enabled in the server's PHP configuration and enable the Setup > General Settings > Other tab > Display Errors option, then run the cron manually by visiting the cron.php file in your browser. You should now see an error output to the screen. But when I visit the cron page directly it just shows a blank page with no errors. I don't know what should happen when I visit the cron page, but since there are no errors I can only wonder is this points to my issue. As you know not being able to generate invoices is a major problem. Please help. - - - Updated - - - I should have provided the cron paths. My server cron job looks like this: 18 3 * * * php -q /home/MYUSERNAME/public_html/WHMCSFOLDER/crons/cron.php In WHMCS under automation settings I have this: Create the following Cron Job using PHP: php -q /home/MYUSERNAME/public_html/WHMCSFOLDER/crons/cron.php Create the following Cron Job using GET: GET http://www.MYDOMAIN.com/WHMCSFOLDER/crons/cron.php According to my hosting company the php -q is a correct command. Hope these details help. - - - Updated - - - One last detail. As stated in the Invoicing Issues section: Utilities > Logs > Activity Log and ensure you see a number of entries beginning "Cron Job" each day. There are no cron jobs listed in the activity log.
  12. I am using Paypal and mail-in-check or money order. When I set a client to payment method: Credit Card, the invoice gets a payment button added directly to the invoice. The problem is they first have to visit their client area, log-in, find the invoice, open the invoice, find the payment button and then pay. When the second, third, and overdue notices are sent there are no payment buttons directly in the e-mail. Is is possible to add the Paypal payment button directly to each e-mail reminder (that requires a due or overdue invoice)? This would be much easier for my clients than having to visit their client area, login, and go through the steps just to access their payment button. And would require less instruction from me as well. My point is the invoice automatically adds a payment button if the payment is set to credit card directly in the product, but the invoice e-mails do not. I have: WHMCS Version: 5.3.6 Paypal and Mail In Payment Activated. I set each clients products or services "Payment method" to Paypal.
  13. Yep, that was it John. I updated my default template files but not my custom files. That fixed the problem. Thanks much!
  14. It was the default head template that had the image. I updated my custom template files and now I see the image. Basically, I was missing an updated template file. I appreciate the help.
×
×
  • 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