I currently have a Magento site version 1.9.1.0 and have the "Front controller reached 100 router match iteration" reports. It's bringing down the site several times a day.
I have followed the steps in this post Magento "Front controller reached 100 router match iterations" error
and when the site went down last I believe the controller that seems to reappearing is the '/admin' path as shown in
2015-09-19T16:55:02+00:00 DEBUG (7): ----Matching routers-------------- ----------------
2015-09-19T16:55:02+00:00 DEBUG (7): Total 7: admin, standard, install, wordpress_addon, cms, wordpress, default
2015-09-19T16:55:02+00:00 DEBUG (7): - Iteration 1
2015-09-19T16:55:02+00:00 DEBUG (7): Request: [path_info=/admin] [module=][action=][controller=][controller_module=][route=]
There is redis, varnish and memcache also running and the cache is saved to the database. When the site goes down I restart these services and it will fix the problem temporarily but obviously this isn't the solution. It also seems that the more I restart the services, the more it happens. This problem happened about a year ago and in order to rectify it, these were added and the problem seemed to be fixed but now has reappeared (badly).
I also found this post http://magentosupport.help/knowledgebase/solved-front-controller-reached-100-router-match-iterations/ which I have gone through each step and checked each one but still the problem hasn't been fixed.
I was going to try this patch https://github.com/convenient/magento-ce-ee-config-corruption-bug#update-good-news-a-patch-from-magento
but my hosting company told me it wouldn't work because it doesn't apply to my version.
The site has multiple stores and lots of additional extensions, I would really appreciate it if anyone could give me any advice because I am desperately stuck.
Kind Regards,
Related
Yesterday my site suddenly stopped working and after investigating I found out that Midphase upgraded the PHP to 8.1 and MariaDB (says from 10.3 to 10.5). I got them to roll back PHP to 7.4 for the time being, although it sounds like it was already on 7.4, which is good as they couldn't go back further.
My live site is on 3.10.1 (http://www.scifivision.com) and after running an upgrade on a backup, assuming I did it right I have a version on 3.10.11. (http://www.thejfiles.com/sfv2023). Both are giving me the same errors other than the database name is different.
The frontend gives me white page with the error "1146 - Table 'thejrub4_joomfin.joom_fields_values' doesn't exist" and backend gives me a warning "Error loading module Table 'thejrub4_joomfin.joom_modules_menu' doesn't exist" and it lets me log in but I can't do anything.
Just wanted to mention, in case it's relevant, I have an earlier backup (I'm at the point if anything is fixed I'll be happy) that is also giving me two warnings:
session_name(): Session name cannot be changed after headers have already been sent in /home/thejrub4/public_html/sfvclon/libraries/joomla/session/handler/native.php on line 128
ession_cache_limiter(): Session cache limiter cannot be changed after headers have already been sent in /home/thejrub4/public_html/sfvclon/libraries/joomla/session/handler/native.php on line 235
Error: Failed to start application: Failed to start the session because headers have already been sent by "/home/thejrub4/public_html/sfvclon/libraries/vendor/joomla/input/src/Input.php" at line 41.
Since I am not seeing them on the newer backup, I'm assuming that is probably not the issue and was something I previously fixed, as I do have maximum on for debug
I have used forum post assistance for joomla.org if that helps and I will post the code below. This is for the 3.10.11 install, as the FPA wouldn't work on the older one. It says it should work without any issues, but clearly that's not true. I didn't know if that would help on this forum, but if you need it please let me know.
I've got a Laravel app setup locally with (what seems to me) very poor performance as you can see below:
My setup:
W8 on a pretty fast laptop with SSD
XAMPP 3.2.1
Laravel 4.1.*
Clockwork 1.* (only added the controller event as desribed in the docs)
Debug mode true
The scenario described:
A logged in user access a page with a list of prospects : 1216ms
Then the user logs out : 1164ms
Finally the user is redirected to the login page : 1165ms
As you can see in every single request the bottleneck is the "Router Dispatch" event. What can I do to dig further, and most importantly what can I do to improve its duration?
Or maybe because this is a dev environnment these are expected numbers? (I don't believe so, but I might be wrong).
After updating my XAMPP to the latest and Laravel to 4.2, this just got fixed by itself.
I'm brand new to server side setup and creating staging environments. I have a magento live environment I've setup, but now I want to setup a stage environment (stage.mystore.com) and practice rolling from stage to live. But, I'm a newb to this and having issues.
I started by following this tutorial to the T, but am currently stuck:
http://www.crucialwebhost.com/kb/setting-up-a-magento-staging-area/
I can load my homepage on the stage subdomain, but any link I click on gives me an "500 internal server error". Secure and unsecure.
I've read around a lot, and it seems like I probably need to either edit something else in my .htaccess or core_config_data but I'm uncertain what to do next.
Can anyone provide more complete step by step instructions for this last part for me?
PhilB's response worked. I just needed to do that change to the varien.php file AND clear out all cookies from my live server in my browser and then I could login. thanks.
Recently transferred my Magento 1.7 store to a new host, and started having a frustrating problem.
We've got the store sitting behind a login shell - you can see it at http://www.seacadetshipsstore.com. Base exchange takes you to the root store (/magento/), and the gearlocker login takes you to a secure sub-store (/magento/gearlocker/).
The problem is, ever since transferring to the new host, /magento/gearlocker/ is sporadically redirecting to /magento/. I can only reproduce it 1 in every 10 times, but customers are constantly complaining that they can't access the secure store for this reason.
I've also noticed that if I turn off the security and have clients navigate to /magento/gearlocker/ directly, it seems to fix the problem for most - they no longer get the redirect after logging in. Only a few of them still have the error, and they're all PC users on various browsers.
I've set up a demo login for stack:
https://www.seacadetshipsstore.com/login.php
U: stack_login
P: thanks
I doubt it's an issue with the base url or base link url, otherwise the error would be much more consistent. I've gone through magento's official tutorials and made sure the secondary store was set up properly (remember, it was working fine on the old host). I also know it's not anything to do with the login shell - all it does is validate the user's login and redirect to /magento/gearlocker/.
Can anyone reproduce this error? Can anyone tell me what's going on, or how I might fix it? Thanks in advance!
i have Fontis reCAPTCHA installed and it has been double checked by another developer to be working. but i keep getting fake customer registrations - about 2 or 3 a day.
they are like this:
452 sesBesIdete sesBesIdeteVQ v.e.ronikalikes#gmail.com
451 Monicarj MonicazcGF Gutermuth#daolemi.com
450 Reennadix ReennadixZB aldenrivas24#yahoo.co.uk
449 Ommett24 Hmmett67OM Demoura#daolemi.com
any way to stop this?
This may sound obvious, but what happens when you try to submit a fake account? I realize that you have the reCaptcha on the site, but how was it implemented? Does it protect the site if someone submits a form externally?
If you had someone apply reCaptcha without using an actual Magento extension then you may want to consider this one:
http://www.magentocommerce.com/magento-connect/Fontis/extension/1169/fontis-recaptcha
FWIW, upgrading to next version fixed this issue ...now at 1.6.2