私は自分のケースに似たものを見つけるためにすべてのトピックを調べてきました。類似のケースをいくつか見つけましたが、どの解決策でも問題は解決しませんでした。
バックエンドで管理URLを変更しました。変更を保存した後、magentoは直接404エラーを表示しました。管理URLに定義した新しいURLは「gestion」でした。 mydomain.com/gestionにアクセスすると、404エラーが発生します。
そこで、magento core_config_dataテーブルで作成された新しいエントリを削除して、キャッシュディレクトリを手動で空にすることにしました。
しかし、その後、同じエラーが発生します。404ページが見つかりません。 this と this を試しました。しかし、まだ同じです。
奇妙なことに、データベースの「ジェスチャー」に関連するすべてを削除し、キャッシュディレクトリを空にしました。しかし、mydomain.com/adminにアクセスすると、magentoがmydomain.com/gestionにリダイレクトします(404エラーが表示されます)。
関連するすべてのものを削除したのに、なぜmagentoが「gestion」にリダイレクトするのですか?これを解決するために他にどこを見ればいいですか?
P.D. Magento 1.5.1
ANSWER:同じ問題があり、以前の答えはどれもうまくいきませんでした。 Magentoバージョン1.9を使用しています。
ここに私が問題を修正するためにしたことがあります...
そしてあなたは[〜#〜] done [〜#〜]!
以前の管理URLに移動すれば動作するはずです!
これは、システム構成カスタム管理URLブービートラップの修正です。それは決して機能しませんし、おそらく機能しません。変更する唯一の方法は、local.xmlを介してルートを変更することです
https://magento.stackexchange.com/a/40622/55
そして、管理者ベースURLをオンにする人のために、他に何かをする前にそれをkillする方法があります[〜#〜] [〜#〜]がシステムを台無しにします。
PhpMyAdminを起動して、core_config_dataテーブルを開きます。編集する4つ以上の行があります。
admin/url/customを見つけて0に設定します
次の3つは、Admin Configパネルで設定したファンキーな管理ベースURLから設定されます。あなたはそれが何であるかを知っています、以下の行はそれを値フィールドに持っています。それらのconfig_ID番号をメモし、書き留めます。
admin/url/customおよびweb/unsecure/base_url web/secure/base_urlのすべてのインスタンス
これらを、Webサイトのセキュリティで保護されていないベースURLになるように設定します。例: http://yourwebsite.com/ そして、インストールされている場合は、スラッシュが続くフォルダーを忘れないでください。
EDIT:/ var/cacheおよび/ var/sessionをフラッシュします。
これで、冒険する前のように、WebサイトのURLに/ adminを追加して、管理パネルにログインできるようになります。 Advanced Adminセットアップに移動します。 Use Custom AdminはNoに設定されます。Custom Admin URLフィールドからURLをクリアして保存します。戻ってphpMyAdminのcore_config_dataテーブルを確認すると、admin/url/custom行のみが0に設定されており、admin/url/custom行は空白になっていることがわかります。他の2つの行は、管理パネルの保存によって削除されたために失われました。
このようにする理由は、正しいweb/unsecure/base_urlおよびweb/secure/base_urlを取得する必要があるためです。行が削除されました。間違ったものを取得すると、管理バックエンドを失うだけでなく、ウェブサイトのフロントエンドが完全に無効になります。
編集:これでウェブサイトが復旧したので、戻ってTLS/SSL機能を元に戻すための正しいsecure_base_urlがあることを確認してください。
これはすべて開発サーバーYMMVでテストされています
以下は、これをデバッグするための最良のステップです。
Magento/app/code/core/Mage/Core/Controller/Varien/Front.phpにあるMage_Core_Controller_Varien_Frontを開きます
GetRouterByRoute($ routeName)関数に移動します
print_r($this->_routers);exit;
問題を修正するには、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;
そして、さらに混乱がミックスに追加されます:
上記のどれも私を助けませんでした。私のマジェントのバージョンは1.7.0.1です。 このウェブサイトは私を助けてくれました 。誤ってadminバックエンドを使用してadminをカスタムURLに変更した場合(私が行ったように)、それを修正するにはMySqlアクセスが必要になります。
キーadmin/url/use_custom
およびadmin/url/custom
を変更するだけでは不十分です。 app/etc/local.xml
を変更しても、管理者インターフェースに戻るために何もしませんでした。
select * from core_config_data where path like '%url%';
などのクエリを使用して、全体像を確認しました。
// 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 |
+-----------+---------+-------------------------------+----------------------------+
私のID 1538と1539に注意してください。これらは、admin/url/custom設定とともに変更されます。 admin/url/custom
およびadmin/url/use_custom`に戻すと、adminにログインして、oopsカスタム管理URLで404にログインできます。
したがって、これらすべてを以前の状態に戻します。
+-----------+-------------------------------+-----------------------+
| 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 |
+-----------+-------------------------------+-----------------------+
...行ってapp/etc/local.xml
を変更し、私のサイトに戻ることができました。
admin/url/custom
をクリアするために、update core_config_data set value='' where config_id = 746;
Magentoフォーラムの投稿のすべての手順を実行しても、ここに追加したかっただけです http://www.magentocommerce.com/boards/viewreply/274443/ それでも機能しない可能性があります-デフォルトの管理URLでもエラーが発生します。
私にとっては、/ var/logディレクトリがexception.logおよびsystem.logファイルでセットアップされていなかったためです。だからやった後
$ mkdir var/log
$ touch var/log/system.log
$ touch var/log/exception.log
$ chmod -R g+w var/log
(最後のchmodをローカルWebサーバーの権限要件に一致するように変更します)
次に、デフォルトの管理URLが機能しました。したがって、すべてのdbの手順を実行してもダイスがない場合は、ログファイルを作成して、Webサーバーから書き込み可能であることを確認してください。
問題を解決するためにすべてを試みた後、/ varディレクトリに適切な権限がないことがわかりました。 Magentoは/ tmpに書き込んだため、magentoルートの/ var/cacheディレクトリを空にする効果はありませんでした。
権限を修正して/ tmpディレクトリをフラッシュすると、すべてが正常に戻りました。したがって、問題の原因となったのは/ var権限です。
これで、このようなことが発生したときに考慮すべきもう1つのことがわかります。
皆さん、助けてくれてありがとう。
Magento 2のインストール中に同じ問題が発生しました。おそらく、問題はApache2リライトにあります。別の可能性は、Magentoディレクトリのファイル権限設定です。私に役立つ2つのソリューションを共有したいと思います。
ローカルホストにMagento 2をインストールしているときに、Magentoインストールのステップ3で127.0.0.1の「Your store address」フィールドと「Magento admin address」フィールドの代わりに「localhost」を使用した場合、core_config_dataテーブルでできることは次の2に変わります行:
web/unsecure/base_url to http://127.0.0.1/Magento/
そして
web/secure/base_url to https://127.0.0.1/magento2/
Magento/var/cacheディレクトリ内のすべてを削除します。
次に、
http://127.0.0.1/Magento/index.php/admin/
または
http://127.0.0.1/Magento/admin/
以下のURLに記載されている権限設定でMagentoを再インストールしてみてください: http://devdocs.magento.com/guides/v2.0/install-gde/prereq/Zip_install.html
インストールのセットアップウィザードでは、ステップ3で「localhost」の代わりにストアアドレスに127.0.0.1を使用します。
このステップで考慮すべきもう1つのこと:詳細オプションを展開し、「Apache Rewrites」オプションをオフにします。
インストール手順を完了し、ソリューション1に記載されている管理URLを試します。