mtindor

This issue isn't specific to cPanel I installed Almalinux 9 running: libcurl-7.76.1-19.el9_1.1.x86_64 curl-7.76.1-19.el9_1.1.x86_64 openssl-3.0.1-47.el9_1.x86_64 I attempted to migrate WHMCS over to that new machine and discovered I was getting the same error when attempting to access things at Enom. Whether cPanel issued a "fix" in EasyApache 4 at some point to fix it, or whether reverting back to a previous or newer version of Curl may have fixed it for some, it definitely doesn't work on Almalinux 9 with the above packages. So does Enom run some broken TLS implementation that they should fix? Or are OpenSSL devs fixing and then reintroducing these issues with changes to OpenSSL? Is it the Curl devs who need to fix it? No clue. I think Enom needs to fix things on their end. You guys (WHMCS) are tight with Enom. So maybe WHMCS might consider reaching out to Enom regarding this issue. Regardless of whose fault it is, it's unfortunate that one can't provision a brand new hosting server running the most recent version of a reliable OS and expect things to work. Bummer.

Hi Andrew, Yes, those have worked (historically) and continue to work now, regardless of which URL setting I use. On those search boxes I have to type a partial in and then hit Enter. I'm unsure if I had to hit enter before. But, on the Add New Order --> Client search box it does not work if I type in a partial, or if I type in a partial and hit enter, when in Full Friendly Rewrites mode. In either of the other two modes, I can just click on the box and it will start giving me possibilities. Mike

Brian, That's a great suggestion. Yes, I do get my license direct from WHMCS. I did figure out, after all of these years, that any rewrite rules in .htaccess were not actually working because of my AllowOverride None directive in Apache for my WHMCS directory. How dumb of me. In Apache, I ended up setting, at <Directory> level, these: AllowOverride FileInfo AllowOverrideList RewriteBase RewriteCond RewriteEngine RewriteMap RewriteOptions RewriteRule I then renamed .htaccess and made one of my own to test rewrite rules of /* to a specific URL and it indeed did work. I then commented out my AllowOverride* directives in Apache (in effect defaulting them to None, like they were before), and verified that mod_rewrite wasn't active. So I know the rules weren't even being processed before today. I then uncommented my AllowOverride* directives and verified again that mod_rewrite was processing rules. I then switched back to using the .htaccess file that WHMCS writes, but still cannot get Full Friendly Rewrites to work. I'll attempt to get a dev license and test on a development site and see what happens, if I can't figure out the issue within the next hour. Mike

Hi Andrew, mod_rewrite is active. Every part of the billing system (as far as I can tell) is working just fine with the friendly URLs except for Orders --> Add New Order --> click on the "Client" box. 1. No 404s 2. .htaccess file only contains the stock WHMCS content If I switch to Basic URLs, all content is removed from .htaccess, and then if I switch to Full Friendly Rewrite the stock WHMCS rules are written to .htaccess. Using various rewrite rules is not anything new on my installation. I've had it installed on this system since 2013 and were using the various rules included in the htacess file included with the distro in the past. As I mentioned in my previous post, with Full Friendly URLs enabled it seems to be POSTing to /myadminurl when I click on the "Client" box in Orders --> Add New Order, when in fact I think it should be POSTing to /myadminurl/index.php. When using Basic URLs or Friendly index.php options, everything works and the browser is POSTing to /myadminurl/index.php. I'll increase the logging verbosity and see if I can find anything odd. Mike

No dice from WHMCS Support via ticket, mainly because I won't allow anybody access to my billing system. I'm disappointed that they wouldn't even venture a guess though. Certainly if somebody there were to give it 30 seconds of thought they could point me in some direction to troubleshoot. At any rate, I used the Firefox Developer Tools --> Network Tab to see what was being sent by the browser when I would click on the Orders --> Add New Order --> click on Client search box, and here is what the browser sends depending upon the URL rewriting scheme used. https://my.example.com/myadminurl/index.php?rp=/myadminurl/search/client - Basic URLs - works fine https://my.example.com/myadminurl/index.php/myadminurl/search/client - Friendly index.php - works fine - server sends back a list of first 30 active clients in my billing system when I click on the Client box in Orders --> Add New Order https://my.example.com/myadminurl/search/client - Full Friendly Rewrite - does not work - server sends back nothing when I click on the Client box in Orders --> Add New Order So, it looks like the browser does not POST /search/client to /myadminurl/index.php with Full Friendly Rewrite enabled. and instead POSTs it to /myadminurl . Of course, that still leaves me wondering if it's simply an issue with rewrite rules or if it is an issue with my PHP-FPM / php.ini settings. It sure would be nice if a couple more people would try all three options, see if they can reproduce the problem, and report back. Mike

Thanks, Brian. I may do that. I do have an update on this issue (in my environment). It now behaves as yours does, meaning that the Client box at /myadminurl/ordersadd.php now works with both the Basic URLs and Friendly index.php settings. Now it only doesn't work with the Full Friendly Rewrites setting. And, my error_log generates no more errors. What resolved the errors seen in error_Log (and what resolved my issue with Friendly index.php not working) was changing to cgi.fix_pathinfo=1 in my php.ini. That's the default, and that's how it should have been, but for whatever reason it was set to 0 in my php.ini. So, the only issue that remains is the Client box search in /myadminurl/ordersadd.php not working when Full Friendly Rewrites is set. Mike

The error I see in error_log is different depending upon whether I choose "Friendly index.php" or "Full Friendly Rewrites" # Friendly index.php [Wed Dec 06 11:30:39.046164 2017] [proxy_fcgi:error] [pid 9261:tid 140482256557824] [client 10.1.1.10:61642] AH01071: Got error 'Unable to open primary script: /home/someuser/public_html/myadminurl/search.php/client (No such file or directory)\n', referer: https://my.example.com/myadminurl/ordersadd.php # Full Friendly Rewrites [Wed Dec 06 11:21:55.454171 2017] [proxy_fcgi:error] [pid 8742:tid 140088369456896] [client 10.1.1.10:61230] AH01071: Got error 'Unable to open primary script: redirect:/index.php (No such file or directory)\n', referer: https://my.example.com/myadminurl/ordersadd.php

In my particular environment (PHP 7.0.x, Apache 2.4.x, PHP-FPM, Opcache), the only setting it will work in is "Basic URLs". Either of the other two options cause it to quit working. Odd. Mike

Hmm. I switched to Basic, and everything worked fine again. Clicking the update rules setting changed the contents of .htaccess and Friendly URLs now shows "Full Friendly Rewrite", but my particular setup isn't working with that setting still. Thanks for testing though. That at least confirms that there may be an issue (outside of my setup). I guess most people never add an order manually. Mike

I see what's happening now. This has to do with using the "Full Friendly Rewrite" or "Friendly index.php" under General --> Friendly URLs. If I switch to "Basic URLs", things work again. error_log shows the following when trying to access ordersadd.php with either "Friendly index.php" or "Full Friendly Rewrite" selected as the Friendly URLs setting: [Wed Dec 06 10:36:48.952917 2017] [proxy_fcgi:error] [pid 7436:tid 140664180262656] [client 10.0.0.10:58987] AH01071: Got error 'Unable to open primary script: redirect:/index.php (No such file or directory)\n', referer: https://my.example.com/myadmindir/orde rsadd.php Anyone have any suggestions? Can anyone else reproduce this issue? Mike

Wondering if anyone else is having this issue. When logged into WHMCS 7.4.1 as an admin, do this: 1. Select Orders --> Add New Order 2. Start typing (a known existing) client name in the "Client" box What should happen is that it should start displaying possible clients as you type, just as the search boxes autofill the possibilities when you start typing a search. This used to work in 7.2.x for me. After I upgraded to 7.4.1 (via the auto update feature), this stopped working. I then renamed public_html and replaced it with a full WHMCS 7.4.1 distribution. Same thing happens. Normally, if I typed something like "Tin" in the Orders --> Add Order --> Client box, it would automatically show my own billing account. Now it doesn't bother to display anything. Mike

Still no response from MyCircleTree. If they have abandoned support, they are still taking money. Ticket still not responded to. As I said before, in the past they always replied promptly -- up to and including 1st quarter of 2017. I have to assume that something happened between then and now and that I should no longer use the addon nor expect support from them. Mike

That is worrisome. Prior to this, the last time I communicated with them was early this year and they responded quickly (and with a fix). Now it sounds as if nobody is getting a response from them. When I look on their website at their "work", Im not sure they have any new web development site examples up online (based upon the fact that none of the ones visible have SSL enabled on them). I have a feeling I'm going to have to uninstall the plugin and consider them as having abandoned the addon / support / etc. Over the years I have had I believe 8 tickets open with them, and they never took more than a day to respond. Something obviously has changed, and not for the better.

I've got a ticket open (for only 3-4 days now) waiting for a response from MCT. I don't know if they took some sort of extended vacation, or if they gave up on the plugin and just aren't responding. I'm sort of worried about that, because I really love the plugin. I'm running WHMCS on PHP 7.0. I upgraded from 7.2.3 to 7.4.1 and now the admin widgets specifically related to Enom aren't working. I had enabled the module logging, and it's successfully making the API calls to Enom (such as getbalance), and Enom's API appears to be returning valid responses. But all of the widgets just sit there and spin and display nothing. So for now, if you use the Enom Pro addon, I would not recommend updating to WHMCS 7.4 unless you are prepared to deactivate the Enom Pro addon. Hopefully they have just taken a long vacation. M

I've been using Enom Pro for a few years. I really like it. I upgraded the billing system to WHMCS 7.1.2 / PHP 7.0 and found that the 3.0.0.5 release that you get from them no longer worked properly on WHMCS 7.1.2 [and if running PHP 7, did not work because it was encoded with a different version of Ioncube]. I opened up a support ticket with them, and they provided me with a version that they said would work. And indeed it does work. Seems to work fine. I'm not aware of any missing functionality. I'm happy. Mike