Magento admin URL not working: 404 after changing

问题:

I've been looking through all the topics to find something similar to my case. I've found a few similar cases, but none of the solutions solved my problem.

I changed through the backend the admin url. After saving changes, magento took me directly to a 404 error. The new url I defined for the admin url was "gestion". Going to mydomain.com/gestion, gets a 404 error.

So I decided to go back deleting the new entries that were created on the magento core_config_data table and then emptied manually the cache directory.

But after that I've got the same error: 404 page not found. I've tried this and this. But still the same.

The weird thing is that I've deleted everything related to "gestion" on the database and also emptied the cache directory. But when I go to mydomain.com/admin, magento redirects my to mydomain.com/gestion (with a 404 error).

Why is magento redirecting me to "gestion" when I've removed everything related to that? Where else should I look to solve this?

P.D. Magento 1.5.1

回答1:

ANSWER: I had the same issue and none of previous answers worked for me. I'm using Magento Version 1.9.

Here's what i did to fix the issue...

1. Go to your cpanel and launch phpMyAdmin.
2. Locate your Magento Database and select the core_config_data table.
3. Locate and edit the following rows:
   • Scope:"Default" and Path:"admin/url/custom"
     • Select the NULL checkbox and save.
   • Scope:"Default" and Path:"admin/url/use_custom"
     • Change value from 1 to 0 and save.
   • Scope:"Default" and Path:"admin/url/use_custom_path"
     • Change value from 1 to 0 if it isn't already and save.
4. Locate and delete the following rows:
   • Scope:"Stores" and Path:"web/secure/base_url"
   • Scope:"Stores" and Path:"web/unsecure/base_url" (should be located on the last page)
5. Delete /var/cache folder

and you're DONE!

go to your previous admin url and it should work!

回答2:

Here's the fix for the System Config Custom Admin URL booby trap. It's never worked, and probably never will. The only way to change it is to change the route through local.xml

https://magento.stackexchange.com/a/40622/553

And for anyone who turns Admin Base URL on, here's a way to kill it before you do anything else which WILL mess your system up.

Fire up phpMyAdmin and open your core_config_data table. You have four or more rows to edit.

Find admin/url/custom and set to 0

The next three will have been set from the funky Admin Base URL you set in the Admin Config panel. You know what it is, the following rows will have it in the value field. Note their config_ID numbers and write them down.

admin/url/custom and all instances of web/unsecure/base_url web/secure/base_url

Set these to be what your website unsecured base url should be. Example: http://yourwebsite.com/ and don't forget the folder followed by a slash if you installed there.

EDIT: Flush /var/cache and /var/session.

This should allow you to log into your Admin panel now by appending /admin to your website url as like before you got adventurous. Go to your Advanced Admin setup. Use Custom Admin will be set to No. Clear the URL from the Custom Admin URL field and save. When you go back and check your core_config_data table in phpMyAdmin, you should only find the admin/url/custom row still set to 0, the admin/url/custom row blanked, and the other two rows gone as they were deleted through the admin panel save.

The reason for doing it this way is that you need to get the right web/unsecure/base_url and web/secure/base_url rows deleted. If you get the wrong ones, your website frontend gets completely disabled instead of just losing the admin backend.

EDIT: Now that you have your website back up, go back and make sure you have the correct secure_base_url to get your TLS/SSL capabilities back.

This has all been tested on a dev server, YMMV

回答3:

After trying everything to fix the problem I found out that the /var directory didn't have the correct permissions. Magento wrote on /tmp so there was no effect emptying the /var/cache directory on the magento root.

We fixed the permissions and flushed the /tmp directory and everything went back to normal. So, it was the /var permissions that caused the problem.

Now we have another thing to take into account when something like this happens.

Thanks for your help, guys.

回答4:

To fix the issue run the following query from phpMyAdmin

UPDATE `core_store` SET store_id = 0 WHERE code='admin';
UPDATE `core_store_group` SET group_id = 0 WHERE name='Default';
UPDATE `core_website` SET website_id = 0 WHERE code='admin';
UPDATE `customer_group` SET customer_group_id = 0 WHERE customer_group_code='NOT LOGGED IN';
SET FOREIGN_KEY_CHECKS=1;

回答5:

Just wanted to add here that, even if you follow all the steps on the Magento forum post: http://www.magentocommerce.com/boards/viewreply/274443/ it may still not work - the default admin URL still gives an error.

For me that was because the /var/log directory was not set-up with exception.log & system.log files. So after doing

$ mkdir var/log
$ touch var/log/system.log
$ touch var/log/exception.log
$ chmod -R g+w var/log

(Change the last chmod to match your local web server's permission requirements)

Then the default admin url worked. So if you follow all the db steps through and still no dice, try creating the log files & ensure they are writable by the web server.

回答6:

And yet more confusion to be added to the mix:

None of the above helped me; my magento version is 1.7.0.1. This website did help me. If you DO accidentally use the admin backend to change the admin to a custom URL (like I did) you will need MySql access to fix it.

Simply changing the keys admin/url/use_custom and admin/url/custom aren't enough. Even when I changed app/etc/local.xml nothing I tried will work to get back into the admin interface.

I used a query such as select * from core_config_data where path like '%url%'; to see the bigger picture:

// much data omitted...

+-----------+---------+-------------------------------+----------------------------+
| config_id | scope   | path                          | value                      |
+-----------+---------+-------------------------------+----------------------------+
|         3 | default | web/unsecure/base_url         | http://example.com/        |
|         4 | default | web/secure/base_url           | https://example.com/       |
|           |         |                               |                            |
|       745 | default | admin/url/use_custom          | 1                          |
|       746 | default | admin/url/custom              | https://example.com/oops/  |
|           |         |                               |                            |
|      1538 | stores  | web/secure/base_url           | https://example.com/oops/  |
|      1539 | stores  | web/unsecure/base_url         | http://example.com/oops/   |
|      1540 | default | admin/url/use_custom_path     | 0                          |
+-----------+---------+-------------------------------+----------------------------+

Notice my ids 1538 & 1539. These get changed along with the admin/url/custom setting. Changing back admin/url/custom and admin/url/use_custom` let me log in to admin and then 404 on the oops custom admin url.

So I put all of these back to how they were before:

+-----------+-------------------------------+-----------------------+
| config_id | path                          | value                 |
+-----------+-------------------------------+-----------------------+
|         3 | web/unsecure/base_url         | http://example.com/   |
|         4 | web/secure/base_url           | https://example.com/  |
|           |                               |                       |
|       745 | admin/url/use_custom          | 0                     |
|       746 | admin/url/custom              |                       |
|           |                               |                       |
|      1538 | web/secure/base_url           | https://example.com/  |
|      1539 | web/unsecure/base_url         | http://example.com/   |
|      1540 | admin/url/use_custom_path     | 0                     |
+-----------+-------------------------------+-----------------------+

... then went and changed app/etc/local.xml and was able to get back into my site.

To clear admin/url/custom, I used
update core_config_data set value='' where config_id = 746;

回答7:

Following are the best step to debug this.

1. Open Mage_Core_Controller_Varien_Front which is at magento/app/code/core/Mage/Core/Controller/Varien/Front.php

2. Go to getRouterByRoute($routeName) function

3. Here put this code print_r($this->_routers);exit;
4. It will give you all loaded modules and controller path from here you can check if your module path is loaded correctly or not.
5. If your module is not loaded correctly here you have to make changes in config.xml in your module.

回答8:

I had the same issue while installing Magento 2. Most probably the issue is with the apache2 rewrite. Another possibility is your file permission settings for your Magento directory. I would like to share 2 solutions that worked for me.

Solution 1(if already installed)

While installing Magento 2 on your localhost, if you used "localhost" instead of 127.0.0.1 "Your store address" and "Magento admin address" fields in step 3 of Magento installation, now what can you do is in core_config_data table change following 2 rows:

web/unsecure/base_url to http://127.0.0.1/Magento/

and

web/secure/base_url to https://127.0.0.1/magento2/ Delete everything inside the Magento/var/cache directory.

Then try,

http://127.0.0.1/Magento/index.php/admin/

or

http://127.0.0.1/Magento/admin/

Solution 2

Try reinstalling Magento with the permission settings mentioned in the below url: http://devdocs.magento.com/guides/v2.0/install-gde/prereq/zip_install.html

In the Setup wizard for installations, step 3 use 127.0.0.1 in the your store address instead of the "localhost".

Another thing to consider in this step: expand Advanced Options and uncheck the 'Apache Rewrites' option.

Complete the installation procedure and try the admin urls mentioned in Solution 1.