I am experiencing a strange issue on a Joomla 2.5.4 site: http://tinyurl.com/k8xuxth
One of our employees made a few front-end edits to two or three pages and now some of the pages randomly redirect to an error message:
The connection was reset
The connection to the server was reset while the page was loading.
The site could be temporarily unavailable or too busy. Try again in a few
moments.
If you are unable to load any pages, check your computer's network
connection.
If your computer or network is protected by a firewall or proxy, make sure
that Firefox is permitted to access the Web.
It does not happen all the time, and it never happens on the home page. If you click on the "Class Schedule" or "About" links in the nav, it should throw the error message for you. In Chrome, it appears to just freeze up completely. Sometimes, in FireFox, you can see the page begin to load before it redirects to the above error message.
I can't seem to find any errors in any logs. It was a Joomla 1.7 site, but yesterday I upgraded it to the 2.5.4 and also installed K2 and converted all of the Articles to K2 "Items"... neither of these fixed the issue. I am stumped! Any feedback/help/direction would be greatly appreciated.
Other things I tried:
Disabling all modules.
Disabling select plugins (such as Google Analytics).
Upgrading select plugins and modules.
Thanks!
Related
I just installed a SSL certificate on the website and confirmed that it was set-up correctly. But for some reason when visiting the website through HTTPS it gives the error "Not Authorized to View This Page [CFN #0004]". But HTTP works fine.
It's a WordPress website and the htaccess file has not been modified.
What could be the problem?
www.benchmarkadvertising.ca https://benchmarkadvertising.ca/
I've Googled and Googled but cannot find a solution. Called my hosting company, but they're not specialized enough to understand the issue.
First off check this may be a plugin or theme conflict. Please attempt to disable all plugins, and use one of the default (Twenty*) themes. If the problem goes away, enable them one by one to identify the source of your troubles.
If you can install plugins, install “Health Check”: https://wordpress.org/plugins/health-check/ On the troubleshooting tab, you can click the button to disable all plugins and change the theme for you, while you’re still logged in, without affecting normal visitors to your site.
A Magento website is down in IE and in Firefox. Magento provides the following message: "There has been an error processing your request. Exception printing is disabled by default for security reasons."
However using Ctrl+F5 makes the site work.
The site works in Chrome and in Opera.
It also works if any page is requested other than the home page.
The error in the magento file in var/report lists:
a:4:{i:0;s:108:"SQLSTATE[HY000] [1203] User XXXXXXX already has more than 'max_user_connections' active
However it still works in chrome.
You have a problem with your database; Basically your database is hitting the limit for the amount of connections for that user. Check what your max_user_connections setting is at and increase it.
Be careful, as the higher that number, the more resources it will use. You have to find an even balance.
It was not a problem with Magento or the database. The web host was incorrectly caching the site. We found out when a file I uploaded still appeared in cPanel yet the file had been deleted several minutes before.
The web host flushed their cache of the site. The website immediately loaded without any error.
We have been unable to log in to our magento admin panel for a few months now, but this isn't a standard 404 issue.
After logging in with correct username/password, we get redirected to a 404 page. The strange thing is, it only happens from office WIFI, not over 4G or at our developers office. This occurs on our dev server, not live (live logs in just fine)
Our developers have tried creating a new development environment on a new server but the issue is still occurring.
I have tried disabling all firewalls and cannot see anything in router settings which would cause this, anyone had a similar issue or can suggest a solution?
Check your .xml files. You might been redirected to another module url showing the 404 error and check if module is currently actived. This would explain why you still have the same issue even when you're changing server, house, country etc etc.
I tried to download an existing joomla 3.3 project to my local xampp htdocs folder. I copied the database and changed the database connection data in configuration.php
Afterwards it seemed to work, frontend and backend login works perfectly, but as soon as I navigate to another page (/index.php?option=com_fabrik&view=list&listid=25&Itemid=112) I get a nicely styled error page which says "Could not connect to MySQL."
I tried to google this, but it's not like this is a blank page with the error message. The connection to the database must be at least partially working, otherwise I wouldn't be able to login and I wouldn't get such a nice HTML Error page in the same design as the rest of the page.
I am absolutely new to joomla. How can I find out what the problem is? Any hints, ideas? Thanks in advance.
I just "solved" my own problem. Turns out that "fabrik" has its own database connection data. In /administrator I navigated to components - fabrik - connections and edited "site database" there. And now it works!
I'm on Magento 1.4.1 and get regular calls (2-3 per week) from customers that they are unable to add products to their cart. The symptoms are the same for customers: All use IE (7 or 8, most commonly). When they attempt to add to cart, they are taken to an empty cart page. Repeated attempts do not resolve the issue. I have not been able to verify, and the only version of IE I have access to is 9. I would dismiss this as user error except for:
Generally lower-than expected conversion rate on my site (explainable if large % of IE customers are unable to transact).
Consistency of symptoms: Browser and version, action that is failing
I assume this is an issue with setting the session or cookie (but could totally be wrong and am open to other suggested causes). If it is a cookie issue, I've found this post and this post from Stack Overflow which give a little information, but not a solid idea of how to go about confirming it is a cookie or session issue.
Can someone suggest the best way to get started with diagnosis?
setting cookie lifetime to 86400 as recomended here did the trick for me.
IE9 bundles development tools (from settings menu) and this allow you to emulate ie7 - ie9 versions in all compatibility modes.
If you are getting blank pages then there is always a php error behind this and you can see those errors from your server php error log.
We had a similar issue with items disappearing from the cart, it only happened in a store that was using a subdirectory of the main domain, and only with ie9 and older ie's. We also had varnish running on the frontend, and magento 1.4.1.1
e.g.
www.example.com = main store
www.example.com/sub/ = secondary store
After adding items to the secondary store basket in ie9, you could then go to the main store and add more items, return to the basket page and all was well then if you went to another secondary store product and added another item to the basket, then visited the basket page all previous items had gone, but the one just added was there.
We found we could consistently reproduce this by visiting a secondary store product page, adding to the basket, visit the basket - item is there, return to the product page, return to the basket, item has gone. It turned out to be a bad background image url in the stylesheet, and the rule was only used by the product page template, this 404 error was enough to cause ie9 and older ie's to lose the session and start a new one.
ie10 and 11, chrome, firefox and safari didn't have this problem at all, so if you're getting intermittent customer reports of baskets suddenly being empty, check the whole site for 404's, all it can take is one missing image to lose the session for ie9 and older ie's.