Cached admin links bug

[caciavar]

Menu links in the admin back-end seem to be cached.


If you log into the admin back-end and access the site by http://localhost/admin, and then click on "Content Pages", the link is http://localhost/moduleinterface.php?mact=CMSContentManager ...

If you log out and log back into the admin back-end and access the site by http://mydomain.com/admin, and then click on "Content Pages", then link is still http://localhost/moduleinterface.php?mact=CMSContentManager ...

This seems like it's a bug to me. The URLs should be relative as they were in 1.x versions of CMSMS.

Can anyone confirm?

[Rolf]

Clear cache

[caciavar]

Cleaning the cache does force the admin URLS to be regenerated, but it is not the solution.

There may be multiple users accessing the site using different server aliases, and they may not all be valid on all networks.

Example:
If user A logs in using URL A, and clears the cache...

...Then when user B logs in using URL B he/she will have to do the same.

If user A and B are logged in at the same time it becomes an even bigger struggle.

This behaviour did not exist pre 2.x

[Rolf]

There may be multiple users accessing the site using different server aliases

Please explain?

[caciavar]

The first example I gave above would be the best explanation.

User A might be working on the local network accessing the site using local DNS and the url: http://myserver.lan/admin

User B might be working externally using external DNS and the URL: http://mysite.com/admin

If user A has cleared the cache and then navigated the backend, then all the admin links will contain myserver.lan

When user B logs in, all the links will be invalid for him and when he clicks an invalid link he will be logged out unless he clears the cache.

[Rolf]

Core CMSMS doesn't support multiple domains... Doesn't mean it can't work though.

There are some ways to make it work. There is a module in the Forge delivering this feature (never used it). If you use this module, better contact the module developer if it fails somehow.

I use an - also unsupported - method without a module myself at three websites with several subdomains and I know Velden also has some similar sites. Can't speak for Velden but I don't have any issues with this in core 2.x branch.

I suspect your setup is somehow wrong or it is the multi domain module that is failing... In both cases it is not a core bug.

[Rolf]

Just checked a 1.12.2 site and a 2.1.5. Both have the same URLs in the backend, without the root url! That can't be the cause of your problems.

[caciavar]

I was wrong about the admin URL being cached for different users... but it is cached for a single user... so if you log in using URL A, and then log in again (with the same account) using URL B, the 'A' URLs will have been cached and you need to clear the cache for the URLs to have the proper context. If you're working from different locations where the same site may be accesses with a different DNS name (ie. on an intranet vs. over the internet) this becomes problematic. It's also not ALL admin links that are cached... I have a checklist below.

I have checked on 4 different servers, and CMSMS versions 2.1.2 and 2.1.5... and the behaviour exists in every case. I've also checked with various 1.x versions on different servers and the problem never exists.

Here's the easiest way to reproduce the problem on CMSMS 2.1.5 without needing to edit hosts files or access the same site from different networks. This test requires a local instance.

1. Install a CMSMS 2.1.5 instance on your local dev server
2. Log into your local instance using the url http://localhost/admin
3. All of the admin links start with "http://localhost..."
4. Log out
5. Log into your local instance using the url http://127.0.0.1/admin using the same user account used in step 2
6. Expend the "Content" section
7. Hover over the "Content Manager" link and take note of the URL - It is still "http://localhost..."
8. If you click on the link you are redirected back to the login page.

Repeat the same steps using a 1.x versions and you'll see that the URLs are always relative to the URL you are accessing the site by.

Further to what I said above, it is not every admin link that is cached. The following is a list of cached/non-cached links (or relative/absolute links - relative to the host name used in the URL):

CMS
-Home -> not cached
-View Site -> not cached
-Logout -> not cached

Content
-Content Manager -> cached
-File Manager -> cached
-News -> cached

Layout
-Design Manager -> cached

User Management
-Backend Group Assignment -> not cached
-Backend Group Permissions -> not cached
-Backend Groups -> not cached
-Backend Users -> not cached

Extensions
-Admin Search -> cached
-MicroTiny WYSIWYG editor -> cached
-Search -> cached
-Event Manager -> not cached
-Tags -> not cached
-User Defined Tags -> not cached

Site Admin
-Module Manager -> cached
-Settings - Content Manager -> cached
-Settings - Design Manager -> cached
-Settings - Global Settings -> not cached
-Settings - News module -> cached
-System Maintenance -> not cached
-System Information -> not cached
-System Verification -> not cached
-Admin Log -> not cached

My Preferences
-Manage Shortcuts -> not cached
-My Account -> not cached

[caciavar]

This also does not have anything to do with multiple domains. I've used the multidomains module with success in the past but that module's purpose is to solve a different problem altogether.

The problem I'm describing is one that illustrates regression from previous versions of CMSMS and has been introduced in version 2.x.

The problem is similar to the functionality that existed in early versions of CMSMS where if you wanted to view the frontend of the same site using more than one URL, your $config['root_url'] value needed to be $_SERVER['HTTP_HOST'] or something like that (there's some documentation on it that I can't recall offhand right now). Eventually the CMSMS core was restructured in such a way that you were not "locked" into forcing the site to be accessed by one URL and one URL only... it became dynamically accessible. By omitting the $config['root_url'] option the site would work with whichever URL it was accessed by, and all links (both frontend and backend) would be relative to that URL.

This same problem which was solved earlier has now crept it's way back in (to the backend only).

[Rolf]

Thanks for the detailed description. We will look into it.

Grtz. Rolf

[chandra]

It seems related to module API ... only module powered links are cached.