xyzulu

Turned out to be a modsec rule being triggered causing the 403 error

I've seeing the following errors when attempting to preview a new ticket: [Deprecation] Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check https://xhr.spec.whatwg.org/. send @ scripts.min.js?v=bc72f5:4 ajax @ scripts.min.js?v=bc72f5:4 onPreview @ supporttickets.php?action=open&userid=1111117:59 showPreview @ scripts.min.js?v=bc72f5:23 callback @ scripts.min.js?v=bc72f5:23 __handle @ scripts.min.js?v=bc72f5:23 i @ scripts.min.js?v=bc72f5:2 dispatch @ scripts.min.js?v=bc72f5:3 g.handle @ scripts.min.js?v=bc72f5:3 and then a 403 error on the url, ie: https://domain.com/myaccount/admin/supporttickets.php?token=815c711111b0cfc9ecaab3adfgfdg2ea58c1fdb8e98wwwww99a092d&action=parseMarkdown&content= 403 or scripts.min.js?v=bcgdfgdfgf72f5:4 Failed to load resource: the server responded with a status of 403 () send @ scripts.min.js?v=bcdfgdfgdf72f5:4 I've edited out sensitive information of course. Any ideas? I have not noticed this until 7.10.1, but it may have been this way in 7.10.. or perhaps it's something else.

Ok, that lead me in the right direction. Turns out the following in my .htaccess was the issue (but it works just fine with index.php friendly url's) RewriteEngine On RewriteCond %{HTTP:CF-IPCountry} ^$ RewriteRule ^ - [F,L]

I'm sure I've seen this reported for previous versions, but wasn't able to find any posts. As the title says, in 7.10 if you have full friendly urls enabled (not index.php) the universal search doesn't work. An error about needing to login again is shown. Any one else run into this issue?

You should delete the install folder.

I personally think post count is enough of a "ranking" system. As for people that are employed, by WHMCS, well.. they just need something to indicate that (as they already do). I give little attention to a rank under a persons name. I give plenty of attention to their meaningful posts. To be blunt, "we" (whoever you may choose to put into that group) help WHMCS a lot more than I think they realize. Reward "us" with better support, or tangible things other than a fancy tagline and you might just be on to something when it comes to encouraging contributions. PS If you want to learn about how to engage people, you'll find much material on the subject online, including plenty of contradictions. I have quite a lot of experience managing a community many times larger than this, but it's a Open Source community.. and the reasons people are there are vastly different from the reasons they are here.

Why not just provide the hotfix here on the community?

Slightly related to this.. I've seen emails come in with CC recipients and none have been added to the ticket automatically. Other support emails with CC recipients are added just fine. I've not had time to dig deeper into this however.

You need to remove the card from two database tables.. .. tblcreditcards and .... tblpaymentmethods I have the same issue.. WHMCS know about this since I opened a ticket with the when 7.8.0 was released.

Any updates on this? For now I have switched to basic urls as well.

I am also facing a similar issue (not being able to delete cards), however for it is for some customers who never had a card on file.. after visiting their profile they then have an undeletable card (I can delete them manually of course). I've opened a ticket with WHMCS about this quite a few days ago.. so they are well aware. Still, 7.8.1 fixed all the other Stripe issues I had.. especially the ones where I had to process invoices manually. Also, before 7.8.1 invoices were being charged but not marked as paid.

Have you upgraded to 7.8.1 yet?

On 7.8.1 it worked correctly for me when my daily billing ran. Cards were charged correctly and invoices marked as paid.

Did the cron run correctly this time?

You should probably also open a ticket about this so it's not missed.