Hide a widget, not sticking

[bear]

Not sure if this is by design or something's not right, but if I hide a widget (using the "x" or gear dropdown) it disappears only until I refresh or return to the dashboard. Should that choice not "stick" and be recalled until I manually change it again? If not, what's the point?

[WebsiteIntegrations]

Tested on my WHMCS and when i closed a widget it did not re-appear. Even when logging off and back on.

[WHMCS Nate]

Hello Bear,

I was not able to reproduce this on my test install. When you check or uncheck a box we send an ajax call to a admin route, the url looks something like:

whmcs/index.php?rp=/admin/widget/display/toggle/Badges

What are the results of that AJAX call for you? If you continue to have issues please open a ticket so we can investigate this further.

[bear]

Hi Nate.

https://www.DOMAIN.com/dev/index.php?rp=/dev-backend/widget/display/toggle/Badges

POST /dev/index.php?rp=/dev-backend/widget/display/toggle/Badges HTTP/1.1
Host: www.DOMAIN.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
X-Requested-With: XMLHttpRequest
Referer: https://www.DOMAIN.com/dev/dev-backend/index.php
Cookie: <removed>
Authorization: Basic <removed>
Connection: keep-alive
Content-Length: 0

HTTP/1.1 404 Not Found
Date: Tue, 03 Oct 2017 22:34:40 GMT
Server: Apache
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 10275
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8

[WHMCS Nate]

Bear, that suggests that the index.php for your client area is returning a 404, is the file present? I think a support ticket would be helpful to speed up investigation of this issue. 

[WHMCS Andrew]

11 hours ago, bear said:

HTTP/1.1 404 Not Found

Does the License Info page work for you in the admin area?

Help -> License Information

This uses the same routing as the widget hiding. If not, you might need to take a look at your WHMCS directory .htaccess to ensure it is what WHMCS is expecting.

[bear]

The license check also gets a 404, but the index files in the main and admin directory exist. The .htaccess file in the main directory contains only the auth info (it's my dev install, so password protected) and there isn't one in the admin directory. Since the installation of this, it's been updated via the automatic process, which we've been testing for any issues. I added in the rewrites found in the default htaccess.txt, which as expected makes no difference. 

As for opening a ticket, it seems I'm unable to. I log in, hit "submit ticket" and I'm sent to a page to choose a department, and all links fail to do anything, and it seems to lose the fact I'm logged in. Suggestions?

Disregard, seems it continues lower on the page and had no indication it did so. Opening ticket. 

Edited October 4, 2017 by bear

[WHMCS Andrew]

If you go to Setup -> General Settings, there is a setting for Friendly URLs (first tab, right at the bottom). Which option is currently selected here?

Click "Advanced Settings" on the right of this field and it will load a modal.

By default, "Mode Override" will be off, but at the bottom of the modal, WHMCS will indicate which methods are shown to be supported on your system - which ones show as supported?

You don't need to copy the .htaccess rules to your admin directory .htaccess - they only need to be in your WHMCS directory .htaccess. The "rewrite file" tab of the opened modal, will display the default rules for your .htaccess file for you to manage them manually.

 

[bear]

17 minutes ago, WHMCS Andrew said:

"Mode Override" will be off, but at the bottom of the modal, WHMCS will indicate which methods are shown to be supported on your system - which ones show as supported?

Only basic URLs is supported, according to that. Why it's a two part setting is confusing...
Basic URLs is selected, and full friendly as well as friendly index are in the list. 

By the way, I tried mode override to be on, and now can't have it stay "off". That setting also won't "stick". sigh

Edited October 4, 2017 by bear

[WHMCS Andrew]

How does your .htaccess in your WHMCS root directory compare to the rules listed on the Rewrite File tab?

It's separate as not everyone will need or want to be able to change the settings in such a way. Trying to avoid confusion for some people, would appear to confuse others.

[bear]

7 minutes ago, WHMCS Andrew said:

How does your .htaccess in your WHMCS root directory compare to the rules listed on the Rewrite File tab?

It matches the lines provided.
Is it not allowing these other modes due to it being the dev install for some reason? Could any of these errors be due to the restriction in place to keep the public out?

[(Amr)]

31 minutes ago, bear said:

It matches the lines provided.
Is it not allowing these other modes due to it being the dev install for some reason? Could any of these errors be due to the restriction in place to keep the public out?

While testing the  Release Candidate, I faced a similar issue with my development environment, and was able to fix it by removing/commenting all htaccess lines, except those added by WHMCS .. For some reason, restricting access to the dev install folder will report that "Full Friendly Rewrite " and "Friendly index.php " are not supported.

[bear]

Thanks (Amr), that at least explains the issue. Unfortunately that also means that even after going live the .htaccess file can't have additional rules? Ouch. 
Did it still work for you with the extra lines, or was the error factual and the rewrites failed?

[(Amr)]

27 minutes ago, bear said:

Thanks (Amr), that at least explains the issue. Unfortunately that also means that even after going live the .htaccess file can't have additional rules? Ouch. 
Did it still work for you with the extra lines, or was the error factual and the rewrites failed?

I've just tried it now, adding the following lines, before [or] after the WHMCS managed rules, will report that  "Full Friendly Rewrite " and "Friendly index.php " are not supported, and will switch to "Basic URLs" automatically.

AuthType Basic
AuthName "Dev"
AuthUserFile "/path/to/auth/file"
require valid-user

For me, the new routing system is working fine, with or without the extra lines.

One more thing comes to mind, the new routing system has changed from the one used in the beta and the RC versions, so if you've upgraded your DEV install from the beta or the RC version, you might need to force refresh your browser's cache, specially if it's chrome, also clearing the "template cache" wont hurt .. I'm not sure if this will help, as I've no idea how the new routing system works, but doing so saved me a lot of headaches in the past.

 

Edited October 4, 2017 by (Amr)
adding note.

[bear]

Clearing cache didn't do anything, nor did using a different browser that was never used before. I don't want to remove the auth from the directory since that would break the dev license, so I'll have to wait for word from support. Best guess is they will insist on login info to troubleshoot, and since I don't hand that out, I'm going to be stuck. 

[WHMCS Andrew]

You shouldn't need to remove any existing lines (like those for your htaccess) to make this work.

The reporting that something may not work may be caused by a test post on your url to see what would be supported and a .htaccess prompt occurring - not much that can be done about that.

However, you can select something that WHMCS thinks will not work, and WHMCS will attempt to make it work.

What do you have right now in your .htaccess file, in your WHMCS root? This is the important one. The .htaccess in your admin directory can just be your auth rules.

[(Amr)]

10 minutes ago, WHMCS Andrew said:

What do you have right now in your .htaccess file, in your WHMCS root? This is the important one.

I was referring to the .htaccess file in the WHMCS root directory.

Adding the auth lines, before [or] after the WHMCS managed rules, will report "Full Friendly Rewrite " and "Friendly index.php " as not supported, and will switch to "Basic URLs" automatically.

I'm not sure if this is happening with all installations, I'm just reporting what is happening with mine.

Edited October 4, 2017 by (Amr)

[bear]

16 minutes ago, WHMCS Andrew said:

What do you have right now in your .htaccess file, in your WHMCS root? This is the important one. The .htaccess in your admin directory can just be your auth rules.

I have no .htaccess in the admin. The one in the root has the auth and the rules that WHMCS added via the admin click. They match. 
I tried with more than one browser (Firefox and Chrome), same result. 

I can't make changes that stick in many of the things we're discussing: widgets (to start), as well as the rewrites you say are connected somehow. None of the choices in that are "green",. and two say unsupported.

[shivahost]

I have same issue and one more! the refresh button of widget continue loading and no refresh! 

on the gear dropdown I can remove check for each widget but I cant check any unchecked!

with page refresh everything comes back and no change saved!

Now I am returning to 7.2.3!

[bear]

On 10/4/2017 at 6:25 AM, WHMCS Nate said:

I think a support ticket would be helpful to speed up investigation of this issue. 

I would have thought so as well, except support apparently consists of repeated and stoic demands for login details to Cpanel, WHMCS, FTP and so on. When I ask if there's another way to discuss it, I'm ignored in favor of yet another demand for that login information. Is that it for support now, "give us logins or no support for you"?

[WHMCS Nate]

Bear,

The debugging you posted earlier suggests the problem is not with .htaccess rewrites being applied, but something more basic. What I see is:

/dev/index.php?rp=/dev-backend/widget/display/toggle/Badges - returns a 404.

If as you suggest domain.foo/dev/ is your dev install of whmcs and domain.foo/dev/dev-backend/ is the custom admin directory location, the error is that a call made to the index.php of the clientarea returned a 404 error. 

Normally that suggests either missing files or some other webserver configuration is not allowing the server to serve that file. If you want to PM me the ticket I'm happy to take a look at things and help you try to move forward, my most basic question to answer first is why is a call to the base index.php returning a 404 error? Typically that error comes from the webserver not the application. 

[bear]

1 hour ago, WHMCS Nate said:

If you want to PM me the ticket I'm happy to take a look at things and help you try to move forward, my most basic question to answer first is why is a call to the base index.php returning a 404 error? Typically that error comes from the webserver not the application. 

I'd be happy to PM, but I can't PM currently, I've Used 351% of my messenger storage.
The new forum move is still a bit new. Ticket is <<removed>>.

I emptied the inbox, trashing stuff I'd been saving. Will PM. 

Edited October 5, 2017 by bear

[WHMCS Nate]

9 minutes ago, bear said:

I'd be happy to PM, but I can't PM currently, I've Used 351% of my messenger storage.
The new forum move is still a bit new. 

Clearly you need to PM @WHMCS ChrisD about your lack of ability to send PMs  Thanks for the ticket ID, I'll touch base w/our support team and work towards a resolution with you there. Once we've tracked down exactly the root problem we can update this thread for anyone else who might be struggling with similar issues.

[bear]

Just now, WHMCS Nate said:

Clearly you need to PM @WHMCS ChrisD about your lack of ability to send PMs  

Mad as a balloon, you are.
Appreciate the help. 

[shivahost]

On 10/4/2017 at 8:05 PM, shivahost said:

I have same issue and one more! the refresh button of widget continue loading and no refresh! 

on the gear dropdown I can remove check for each widget but I cant check any unchecked!

with page refresh everything comes back and no change saved!

Now I am returning to 7.2.3!

any help?