rota919

I have the same issue. It used to work just fine and I think it started after I applied the upgrade to ver 7.1.2 Under "Automated Settings" it says Cron Status Ok Last run 2017/03/16 09:55 On admin home page it says" Last Automation Run: 4 days ago Needs Attention. My crons run every 5 minutes on the server and automation settings is scheduled to run at 1:00am. Used to be at midnight. I can confirm billing emails were sent last night edit... I run the standard crons without any switches or parameters

Hi Brian, Thanks for your input. I am looking at the six/clientareaproductdetails.tpl template but not 100% sure where to edit. I will have to take some time out somewhere and check out all the possibilities and see what happens. Don't want to break something else in the process.

Understand but having a 0000/00/00 displayed as the provisioning date doesn't help the client to understand that his certificate was provisioned successfully and I have to explain every time that my billing software has a bug in it. That helps a hell of a lot for trust. I would much rather have an app that doesn't look the best but is actually fully functional without such obvious issues. So in my opinion it is affecting the provisioning functionality. Can the dev team at least remove the relevant code in the template so that it presents better or give me a pointer where to look for it in the "six" template?

This is bugging me every time I look at an account in my system. I see the bug has been confirmed a year ago and a statement had been made by "Nate C" that "our release team understands what is needed to fix this". Well since 04-01-15 there has been several updates for WHMCS and still now fix.... maybe it was just an April fools joke posted by "Nate C". How about giving us an update that includes this fix please? Surely thats not to much to ask. Link to original post http://forums.whmcs.com/showthread.php?99159-EnomSSL-module-SSL-Provisioning-Date-displays-as-00-00-0000&highlight=ssl+provisioning+date

A couple of posts up is the code for a widget version of the script. it is working just fine in ver 6.02

Just restore the backup you made before you did the upgrade.

My problem has just been solved with an patched domainsync.php I received from support. Enom crons seems to run just fine now so I suggest log a support ticket asking for the patched file.

WHMCS chose to not give us an option to make the API call over an unsecure connection. Referring to the cPanel documentation example that is shown using https. https://documentation.cpanel.net/display/SDK/Guide+to+API+Authentication#GuidetoAPIAuthentication-singlesignon I tested the example as is and then calling the API over an unsecure connection and received exactly the same jason data without any errors. I made the suggestion in the support ticket to give me an option to decide how I want to call the API. We already have that option when configuring the servers. Why not use the same when calling the API from the member side. It is the same site/server/risk so nothing changes.

I can confirm it is an issue with ver 6. All instances of any references to SSL is disabled in WHMCS and none of my servers redirect to SSL. I do have an SSL cert on my site and thought that might be the problem but looking at your caese and the response you received from support convinced me it is not the case.

You not alone. Here is the other tread http://forum.whmcs.com/showthread.php?102810-Domain-Sync-Cron-Not-running

Same here. I submitted a support ticket for this a couple of minutes ago. Bad idea to upgrade so soon after the release. I usually wait a month or two. Makes you wonder what else is not working... Lesson learned.

No I do not have that. My logs all show the standard/normal expected entries. Looks like they or something on your page are trying to access an array key in your case. (&domains[0]=)

Ok I was wrong about the "Inactive" status and realised it soon after posting the above. Anyone else care to take a hard look at the fraud domain orders and whois logs to see if we can figure out how it's done?

I hear what you are saying Nate but lets be clear. If a visitors / robot / script / entity comes along and enters google.com into the domain search field WHMCS returns that the domain is already registered. If this rouque "entity" then manages to order google.com the software is generating an unexpected result. That in my books is a bug and thus the reason why I posted it under "bugs" Just noticed that none of the fraud domain registrations related to this issue appears in the WHMCS WHOIS logs. Also that an account with a status of "Inactive" can request a "Client Profile Modified - Default Payment Method: '' to ''"

Had another fraudulent order today by the usual suspect "go Team". Sure many of yous recognise the name. They registered a domain testing.com Now testing.com is already registered and thus they shouldn't have been able to register the domain. Question is how did they managed to do it? I already logged a support ticket but would like to hear what the community has to say about this. Did I miss something somewhere or are the hackers accessing some WHMCS API directly?

I am getting the same error but its not on a VPS server. Everything used to work.

I have the same problem with .me domains. It is reported as available while it is not.

The domain availability checker page has been updated with the latest upgrade. It doesn't have a drop down anymore. You need to update your custom template.

Hi Matt, I am trying to setup a server that is using Plesk 7.0.4 and just get this error. Server Command Error Account Creation Failed: - Any suggestion?