Jump to content

Chris74

Level 2 Member
  • Content count

    237
  • Joined

  • Last visited

  • Days Won

    1

Chris74 last won the day on February 17 2014

Chris74 had the most liked content!

Community Reputation

6 Neutral

About Chris74

  • Rank
    Level 2 Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Chris74

    Invalid positive integer

    It would certainly save a lot of headaches if WHMCS could release an individual patch for this quickly.
  2. Chris74

    Invalid positive integer

    Just wanted to mention that since this update we are also seeing a "Invalid Postive Integer" error - but only when the checkout amount is zero. This is most definitely a bug.
  3. No we have Stripe and MyWorks Paypal module. I've realised that the MyWorks module hasn't been updated yet for this version, so it could be this module causing the problem.
  4. Seeing this in my PHP error log regularly now... [WHMCS Application] ERROR: Error: Call to undefined function WHMCS\Payment\PayMethod\run_hook() in /home/username/public_html/whmcs/vendor/whmcs/whmcs-foundation/lib/Payment/PayMethod/MigrationProcessor.php:0 Stack trace: #0 /home/username/public_html/whmcs/vendor/whmcs/whmcs-foundation/lib/User/Client.php(0): WHMCS\Payment\PayMethod\MigrationProcessor->migrateForClient(Object(WHMCS\User\Client)) #1 /home/username/public_html/whmcs/vendor/whmcs/whmcs-foundation/lib/Auth.php(0): WHMCS\User\Client->migratePaymentDetailsIfRequired() #2 /home/username/public_html/whmcs/vendor/whmcs/whmcs-foundation/lib/Utility/Bootstrap/Application.php(0): WHMCS\Auth::persistwhmcsession() #3 /home/username/public_html/whmcs/init.php(0): WHMCS\Utility\Bootstrap\Application::persistSession() #4 /home/username/public_html/whmcs/clientarea.php(0): unknown() #5 {main} {"exception":"[object] (Error(code: 0): Call to undefined function WHMCS\\Payment\\PayMethod\\run_hook() at /home/username/public_html/whmcs/vendor/whmcs/whmcs-foundation/lib/Payment/PayMethod/MigrationProcessor.php:0)"} []
  5. Here's something strange... If I duplicate dist.additionalfields.php to a brand new additionalfields.php - the fields don't show up on transfer. If I remove the identical additionalfields.php, leaving behind just dist.additionalfields.php - the field names appear.
  6. Well I didn't think so - and I would have thought it would get overwritten anyway. I've replaced it with the stock version from the WHMCS download - and bingo! The fields now appear for transfers. I'm guessing early on I must have edited that file and it isn't getting overwritten, or flagged up as changed during the upgrade. What a relief. Hopefully that will be the end of it now. Thanks for your persistence Brian and thanks again for your help!
  7. I removed it from the equation and tested using the default one, so I'm getting the same results with both.
  8. This is getting more bizarre. So I'm using six template with only some very minor changes, css colours etc. cart templates are unchanged. Whether I use the standard ADF file or my own, the fields don't show on transfers. But even stranger, now those fields don't appear in the domain details inside WHMCS for new domains that have failed registration. If I look at existing UK domains I can see and edit the fields in the domain record - but until we updated to this version, if a domain failed because the wrong registrant type was selected, we could change it. This is obviously worse now that the registrant name field is not mandatory, a customer has today left it out and the registration has failed - but we are unable to edit it because the fields no longer show in the admin area. Edit.. After some testing, I can't reproduce this latest issue using either the standard Six template or my own template. I'm not sure under what circumstances this happened for the client. So far it has only happened once.
  9. Interesting. I've not changed any of the templates - I'm not using a custom template and the domain config boxes don't appear at all for transfers, no matter which order form template I use. They do still appear for new registrations though. I'll try your template changes for the registrant name and see how it goes. Thanks again for your help Brian.
  10. Wow Brian I really appreciate all the effort you put into your responses and the lengths you go to to help folks out. I definitely got my wires crossed with this because I just assumed that the Nominet module was designed not to show the ADF's on transfers at all (yet they had left in the form validation) and that the issue was simply lazy programming, requiring us to set the fields to non mandatory. Although obviously this just uncovers more lazy programming, it being that the additional fields are absolutely not needed for the transfer of Nominet domains and they haven't bothered to stop them displaying for transfers in that module. So my initial problem (assuming this is all controlled by the cart template) is that I may be using an old version of standard cart - as the additional fields definitely do not show up on transfers. I was under the impression that the auto update of WHMCS would also update the cart templates accordingly. Is this not the case? If it is - and they do get updated then I'm quite confused as to why the fields don't display at all on transfers. I guess my next stop would be to replace the cart template from a fresh WHMCS download.
  11. Ok I've gone through this again. I'm sorry I didn't quite grasp the exact problem. I can see (as you clearly point out) that the only way to make this work is to set "Required" => true on the registrant name field to "Required" => false - but this is really going to cause us a problem of having to manually add info to these fields after the order has been placed. That field is required for a registration - but so many people do try to leave it out and they will now. It's a real hatchet job. Another example of WHMCS doing the bare minimum to add in some new functionality because it might be needed after GDPR - but being wholly inconsiderate to the pre-existing functionality. Disappointing 😞
  12. Thanks Brian. I'm a little confused. You say that the ADF were added to the transfer process. My problem is that the ADF's are not showing up during the transfer process. I doubt WHMCS would leave it in that state. It would mean that transferring any domain that needs ADF would not be possible. If that was the case, I'm sure more people would be mentioning it here. You say you can reproduce this. Are you sure - using the stock WHMCS ADF - this error happens? I'm a bit lost for words - if transferring nominet domains is no longer possible and WHMCS are aware of it - but have no plans to fix it, doesn't that mean they have broken the Nominet module and purposely removed the ability to transfer UK domains in their product? Surely that can't be true? This is a web hosting billing system after all. I know that we are using overrides on this because the field labels need greater detail. Do you think it's our overrides that are the problem?
  13. Can anyone else reproduce this issue please.... As a client, go to transfer any UK domain using the Nominet module. As expected you are not prompted for the registrant details - however, the order cannot continue because the form is being validated with the "additional domain fields" and states that the registrant name is required. This has been happening for us since updating to 7.8 this week. It means currently no customers can transfer Nominet domains to us. (Using Six template and Premium Comparison order form)
  14. Ahh yes, thats great, thanks again!
  15. Tried removing that already - and cleared the cache, but while the actual link no longer works, mousing over the row still changes the cursor.
×

Important Information

By using this site, you agree to our Terms of Use & Guidelines and understand your posts will initially be pre-moderated