I have noticed that when my internet connection is a bit slower all my wp sites take up to five minutes to load Google Chrome when I am logged in. The version of google chrome I am using is 17.0.963.83.
When I logout the site loads fine again. The dashboard also loads fine when I am logged in and I know it's not a problem with my theme because the same thing happens applies when I apply the default twenty eleven theme.
I have set up a dummy subscriber user so you can test it yourself (to see the difference between the logged in states you need a slow connection though :p)
h2euro.org/wp-admin
u: testuser
p: test
Does anybody have an idea why this is happening?
When logged in, it loads "aloha.js", which is almost a megabyte. Found using Chrome's dev tools, 'network' pane.
Related
So I just linked my custom domain with firebase and it shows connected:
image of connected status
which is great. But now when I search website without /index.html, it redirects me to this page. I want to see this page which is accessible only when I append website domain with /index.html. I am new to firebase. How can I make my domain access index.html page without specifically mentioning /index.html?
EDIT: I just noticed that it's working fine on the mobile devices and in the incognito tab on PC. It must be something with my chrome browser I am logged in with. which is weird :/ should I change the title? Cause I think fault could be related to browser. but help me if you can.
So the real issue wasn't the configuration but the browser cache. if you are facing similar issues then try clearing the browser cache or try browsing the website on a different device. Spent literally 1-2 hrs on such a silly problem. Either way, thank you.
I have an odd okta issue.
I have a old Web Forms app that I am integrating with okta.
The problem is after I login using okta, okta navigates the app to https://domain/authorization-code/callback. This is the value in the address bar of the browser. The app is not automating navigating to the call back page (my default.aspx page). See screen shot below.
Here is what is really confusing, this issue only happens in Production and in browsers: Edge and IE. For Production, everything works fine using Chrome. (After I log in, I am navigated to my default.aspx page).
Additionally what is confusing is everything also works fine in Dev, QA and UAT using Chrome, Edge and IE.
This issue only occurs in Production, using Edge or IE.
I assume it is not a browser issue / setting since it works fine in the other environments. Plus I assume it is not a server side setting since it work fine in Chrome in Production.
Any suggestions would be appreciated.
Plus suggestions in how to debug. I am trying to use the Network tab of the Developer Tools, but I not having much luck.
Thanks
We fixed this problem, months ago. It was because Production is https and QA and UAT were http. I updated the urls in the General tab inside okta to https and everything started working.
I've got a web service that, like most others, uses js and css files. I use the old trick of appending a version number to the js and css file like; ?v=123 and that gets changed every time we update the service on production.
Now, this works fine on all browsers, except for Chrome. Chrome seems to prefer it's cached version over getting the new one and therefor seems to ignore the appended variable. In some cases, forcing it to refresh cache (cmd+r / ctrl+f5) wasn't enough so I had to go into options and clear out the cache for it to load up the new content.
Has anyone experienced this issue with Chrome? And if so, what was the resolution to the problem?
Chrome should certainly treat requests with varying query strings as different requests; a cached result for style.css?v=123 should never be used for style.css?v=124. If you're seeing different behavior, please file a bug at http://new.crbug.com/ and post the bug ID here.
That said, I'd first check to see whether the page was cached longer than you expected. If a new version of the page itself wasn't downloaded, then it would still be requesting ?v=123 as the HTML wouldn't have changed. If you're sending long-lived cache headers with the page, it's certainly possible that Chrome is caching it more aggressively than you expected. If that's the behavior you're seeing, please star http://crbug.com/8742 for updates.
I had also same experience
You can user Ctrl + Shift + R for cache free browsing in both Chrome + Mozilla.
I have had this experience as well.
I run a membership site which displays content such as "You must be logged in as a Gold member in order to see this content" if they are not logged in or are trying to view content not allowed by their membership level. But even if the user is logged in, the user would still see "You need to log in", due to Google Chrome's aggressive caching. In Firefox, however, it works fine as I test logging in and out of all 5 levels of membership - each displaying the proper content.
While Chrome's caching problem can be solved by clearing the cache every time the user logs in and out, it would be really annoying to take that approach.
An issue has started recently, within Chrome and reportedly Firefox, pages would be loading fine and browsing would be as normal and then suddenly then a page would fail to load (continuing to spin as if loading). The page that fails is often not the same.
If I refresh the page or try to goto another page on the domain within the same browser, the browser doesn't even try to resolve the name or make a connection, and is then unable to load the page.
Swapping to another browser and I am back to browsing the domain normally again, while the original browser(in most cases Chrome) will not load the pages until a restart.
This has happened with 3 different people on 3 different machines in both Chrome and Firefox.
The domain that it is running off has allot of ajax calls within certain pages, I am not sure if the server is tripping out due to the number of requests from the one client...I am not sure.
I am not sure if this is a server, client or script functionality issue, as I can not personally reproduce it. I can do little to debug or work out what is causing this or how to fix it...
As you can see I am not sure of allot with this problem :) so I am throwing it out to stack-overflow in the hope that someone may have had similar experiences or have any directions I could look towards.
Cheers,
Brendan
If the page is making many requests in a short time, your firewall (router) may block it. I've noticed this behavior on my own router, and had to set it to a less restrictive level to make things work.
I'm having a strange problem and no luck debugging.
I was tasked with writing a JSR168 compliant portlet to search a database. When you open the portlet, you're given 6 search boxes for different criteria to search several thousand records. Once you press search, it brings up another page (it keeps the first page and uses <jsp: include> for the second page so users can see/change their search terms) with the search results. From the search results page, the user can click on one of the results (which redirects to a new page) and get more detailed information about it.
All of that works. The problem is when the user wants to search again.
When I developed this, I used LifeRay installed on my local machine. Everything works perfectly in IE, Firefox, and Chrome. However, when I deploy it to our development portal (IBM WebSphere), it doesn't quite work in IE. In Firefox/Chrome, when a user is on the detailed information page, they can hit back on their browser and it loads a cached version of the search results. Perfect, because this content rarely changes.
However, in IE, when they click the back button on the detailed view, we get a "Webpage has expired message". I've tried every caching setting in the portal settings for the portlet as well as the page, but haven't had any luck.
Anyone have any ideas?
There are settings at the portal level too.
Check out following link
http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/index.jsp?topic=/com.ibm.wp.ent.doc/wps/adbakbut.html
You could try tweeking some of these paramters as required by your portlets
The "Webpage has expired message" in IE indicates that you did a POST. You could try using a GET, which should not have this problem on "back" command.
You should install WebSphere Portal on your developer machine and test locally before going to another environment.