brian!

htaccess would probably be another option.

thanks for sending the PM about this - i'll answer the question in there.

I suspect that their issue is that two emails sent at the same time are showing different amounts (one including VAT, and one not).... but WHMCS has always done that I think. you could use an EmailPreSend hook to change the content, but it might just be simpler to add a disclaimer on the non-invoice emails that any pricing mentioned does not include VAT.

by default, the renewal price is always set the same as the initial price. workarounds would include... using a promotion code - eg set initial price what you want the recurring price to be (so annual/biennial = 18/30) and then use the promo code to discount the initial price... might need a code for each cycle. use a hook to set the recurring price in the cart - so price it as normal in the product pricing (10/18) and then get the hook to change the recurring price based on the years and cycle. take a look at the Discount Center addon module. i'm sure there is another option that I can't remember.

kb articles ? you can't add an article without a category can you ??

would ImportAssist not be an option ? that said, I would (and regularly have) done what you suggest when setting up a dev - just duplicate the existing database.... you might run into issues with missing addon files on the dev (because they will be included in the db, but the files not present on the server), but as long as you're not testing things related / requiring those addons, you might get away with it.

are you sure you mean Six rather than the Standard Cart orderform template ?? at a push, you might be able to make the Modern (which I assume your screenshot is from) template from v7.10 work in v8 - but I wouldn't see that as a long-term solution. Standard Cart has been around for 6+ years - and this is the way it's always worked... if you've been using Modern for all that time, you probably haven't noticed. you could redirect non-clients (e.g those who aren't logged in) from viewcart to checkout with a hook... untested in recent versions, but I assume would still work (and could be made to work for clients too if necessary) - no doubt, you'll tell me if it doesn't. 🙂 you could change the links of the buttons to cart.php?a=checkout instead, though that was easier in earlier versions that later one. I think Lagom effectively doesn't have a view cart option and goes straight to checkout - so that would be an option if you wanted to throw money at this... though lots of other commercial themes will do this too.

i'd be inclined to think its intended behaviour as i'm pretty sure the function is just duplicating the db row (and that will included paid date if it exists)... though it's always a toss of a coin whether something is EB or a bug with WHMCS. 🙄

if you were using v8.1 or later, you should be able to change it from the Manage Users page - click on user, and it should be an option in the modal window.

there's no absolutely no punishment occurring at this end - still haven't got past the stage of just enjoying doing nothing yet... i'm only here cos I got 3 PMs and they needed answering - quickly answered a few threads, but won't be back again publicly for a while. watching paint dry would be a more scintillating experience than anything to do with WHMCS.

I think Kai has mentioned the critical one - tbldomainpricing - that's the one that is used to show the TLDs in domain pricing... now beyond that, I assume tblpricing will be affected too (as it will store the actual pricing for the TLD), but if the relevant row is missing in tbldomainpricing, then those orphaned rows in tblpricing shouldn't really matter... I know you'd probably like to ideally remove them too, but if so, then don't remove the references from tbldomainpricing first otherwise it would make it more difficult to identify them in tblpricing. like many things in WHMCS, it's often easier to bulk add something than it is to later with remove it! with regards to a SQL for this, you'd likely have to set various conditions based on the values of the TLDs you want to remove (which only you know) .... DELETE FROM tbldomainpricing WHERE extension IN ('.sarl', '.us', '.art') always remember that there is no undo option with these queries - so backup the db before running a delete query. frankly, unless you're telling me that you want to remove hundreds/thousands, it would probably be safer to just remove them manually from domain pricing (make yourself a cup of strong coffee first). ☕

it will be in the headers of the email - "From" will be who the email is from... so if you could reply to the email, then it would be sent to the sender. however, if you really can't access your email(!), then you might be better off directing the contact link to a support department rather than using the contact us page (you can change that in general settings).

quick change... $reportdata["headertext"] .= "<br>$numinvoices Invoices Found<br><B>Total Invoiced:</B> ".formatCurrency($total)." &nbsp; <B>Tax Level 1 Liability:</B> ".formatCurrency($tax)." &nbsp; <B>Tax Level 2 Liability:</B> ".formatCurrency($tax2)."<br><b>".$dateRangeText.": </b>".fromMySQLDate($queryStartDate,false)." - ".fromMySQLDate($queryEndDate,false); as always, don't edit the original .php file (it will get replaced during an update) - so duplicate and edit that. could you not remove the "Add Funds" line from the SQL query in the report? $join ->On('tblinvoiceitems.type', '=', Capsule::raw('"Invoice"'));

because of the change to users/clients etc, I suspect $ca->getUserID() likely got deprecated... there would be alternate ways to identify a user in v8+ if you have to go down that road... they will have been discussed in other threads here.

if the staff slipped on the spill, and were on their backs looking directly at the ceiling, some of them would still deny the spillage exists. to a certain extent, I always have when it comes to WHMCS stuff.... i've never woken up in the morning yearning to be a coder - yeah, I can do it, and I still sorta enjoy it, but i've never wanted (or needed) to make a living from it. technically I still haven't been.... typically British attitude.... far too warm to go there during a heatwave last week and this week it's going to rain. 🌧️