imaticon

This sounds like a mod security rule does block here. Check the mod security logs to see if there is a rule that blocks verify.php

Add this to the configuration.php file and give it a try: $disable_hook_loading = true; If this resolves your issue, then the culprit is a hook you have in /includes/hooks/ or in any module folder (addons, servers, registrars, gateways) or in /modules/widgets/

These details are available in the unpaid invoice, online in the view invoice page.

https://docs.whmcs.com/Version_6.0_Database_Changes#Addition_of_Timestamp_Fields In the v7.5.0 there is any mention of the new addition of the following: grace_period grace_period_fee redemption_grace_period redemption_grace_period_fee However, I do not complain about this. It was clear with the announcement of this new feature that there must be some changes in the db and the first I did was looking into tbldomainpricing but I did not looked into the table structure to see if there were changes on the scheme. But changing a scheme is reallly something you should mention. It will be really really very helpful to get simply a note of something like "the following table schemes have been altered: tbl1, tbl2, etc. etc. A developer do not need to know from you what you have changed, just mention that you changed the scheme and we will take note of that to see if this affect our coding. This will save to all developers a lot of time because viewing the sql file to see what you did is awful, time consuming and really not the way to go. Thank you for your time @WHMCS John and @WHMCS Nate , I do really appreciate it.

It will certainly help, yes. But it is not the correct way to go. In previously releases you mentioned changes in the release notes. Now we have to check also the SQL files ...

I just figured out that since whmcs 7.5.0 the tbldomainpricing table structure has been altered without any mention in the release notes: Before whmcs 7.5.0: dnsmanagement type text emailforwarding type text idprotection type text eppcode type text Since whmcs 7.5.0 dnsmanagement type tinyint(1) emailforwarding type tinyint(1) idprotection type tinyint(1) eppcode type tinyint(1) This is really not developer friendly dear whmcs team. If you alter tables then at least let us know about all the changes you apply in the tables. Are there any other alterations in any other tables?

No worries, you're welcome and I'm glad to hear your success!

No, really? http://php.net/manual/en/ini.list.php (Search for memory_limit) "MB" is not valid, it must be "M" If you dont specify "M" then the value is interpreted as bytes and not Megabytes. If you prefer not adding the required letter "M" to indicate Megabytes then you have to set the correct value for Bytes: 128M = 134217728

wrong: 2048mb correct: 2048M

Sounds like you have set the PHP directive for memory_limit wrong in the php.ini or user.ini file. Set this to 128M, should work: memory_limit = 128M

@brian! thanks for mention me. @RemiturIt works with all TLDs even if not using our module. All you need to do is declare the tld for transfer in the core addon and apply the template modification. Open a ticket and I will be more than glad to guide you further.

All you need to do is remove the unwanted functions from your code, that's it.

Yes, it is: https://developers.whmcs.com/hooks/module-hooks/

Just to mention that addons, registrar modules and server modules hooks are cached. This said, if you have a module active and then you add hooks.php to the module folder, then the hookpoints from the hooks.php file wont be loaded. It is compulsory to do a save changes action on any of the products setup using the module for which you have added the hooks.php file Hope this helps.

So far I can confirm the following: License validation fails with v7.0 and v7.2. I can access the admin area using v7.1 and v6.3 without any problem and I can also force a license update without any error. That does not work for me either. Wunk, what happens if you do a force license update? Works this for you in v7.2?