Magento chuyển hướng đến trang web cũ bất kể những thay đổi được thực hiện!


10

Chúng tôi đang gặp sự cố Chuyển hướng kỳ lạ nhất trên trang Magento. Chúng tôi đã sao chép nội dung trang web từ một trang Magento khác sang một URL mới. Chúng tôi đã làm điều này trong quá khứ không có vấn đề gì, nhưng vì một số lý do, điều này chuyển hướng đến trang web cũ ngay khi bạn cố tải trang, bất kỳ trang nào.

Dưới đây là tất cả các bước tôi đã thực hiện cho đến nay trong nhiệm vụ gỡ lỗi này ...

www.Old-Domain.com = URL trang web cũ mà chúng tôi đã chuyển đi từ

www.NEW-Domain.com = Trang web mới mà chúng tôi đã sao chép Magento qua.

Các bước được thực hiện cho đến nay để thử giải quyết vấn đề chuyển hướng:

  • Đã tìm kiếm toàn bộ cơ sở dữ liệu MySQL (Tất cả các bảng) cho chuỗi www.Old-Domain.comvà đảm bảo rằng không có cái nào có thể gây ra Chuyển hướng xảy ra.
  • Các core_config_datacột Bảng cơ sở dữ liệu được cập nhật web/unsecure/base_urlweb/secure/base_urlURL của các trang web mớiwww.NEW-Domain.com
  • xóa mọi tập tin Cache từ /var/cache/trong Magento Root
  • Đã kiểm tra các thư mục bộ đệm của Máy chủ để đảm bảo các tệp không được lưu trong bộ nhớ cache do sự cho phép hoặc lỗi khác.
  • Kiểm tra .htaccesstập tin để đảm bảo nó đã không xảy ra ở đó
  • Kiểm tra index.phptập tin cũng như in ra một số nội dung theo sau một exit()cuộc gọi và dần dần di chuyển nó xuống trang cho đến khi xảy ra chuyển hướng. Đây là dòng cuối cùng được gọi Mage::run($mageRunCode, $mageRunType);khi trang này tải và đến dòng này, tôi ngay lập tức được chuyển hướng đến URL trang web cũ của chúng tôi!

Có ý kiến ​​gì không?


Gỡ lỗi cho index.php. Các biến $mageRunCodevà được $mageRunTypeđiền vào một trong những trang web đang chạy bình thường của bạn là gì và làm thế nào để chúng so sánh với trang web chuyển hướng?
Phòng thí nghiệm Fiasco

@jason: vấn đề của bạn đã được giải quyết chưa?
zus

Câu trả lời:


20

Hoặc cái cũ nhất trong cuốn sách, quyền truy cập tệp / thư mục của bạn bị mất, khiến Magento ghi vào /tmpthư mục hệ thống , nghĩa là thông tin cấu hình được lưu vào bộ đệm cho đến khi bạn khởi động lại toàn bộ máy chủ hoặc xóa bộ nhớ cache Magento khỏi /tmpthư mục hệ thống .

Vấn đề được mô tả ở đây Không thể thay đổi URL cơ sở Magento, bị kẹt trong bộ đệm

Chỉ bao gồm điều này bởi vì các thư mục bộ đệm của máy chủ không nhất thiết phải dịch sang / tmp

Ngoài ra, không lưu ý nếu đây là một tên miền khác trên cùng một máy chủ, nhưng local.xmlcần thay đổi thông tin xác thực cơ sở dữ liệu ngoài việc không đặt tên bản sao lưu của local.xmlthứ gì backup-local.xmlđó sẽ tải nó trước tệp đã thay đổi của bạn (Magento tải tất cả .xmlcác tệp trong app/etc)

Ngoài ra, nếu đây là bản sao trực tiếp của tất cả các tệp và trình biên dịch đã được bật, hãy tắt nó và xóa kho lưu trữ mã của nó.


Liên quan đến tệp local.xml - tải xuống một bản sao vào máy tính của bạn, xóa nó khỏi máy chủ, sau đó xóa các thư mục trong var / cache và var / session. Cố gắng tải trang web sẽ đưa ra một lỗi. Thay đổi tệp local.xml trên máy tính của bạn, sau đó tải lên máy chủ và xóa lại các thư mục bộ đệm / phiên. Hãy thử tải trang web với những thay đổi. Các bản sao của local.xml (thậm chí được đổi tên) có thể nguy hiểm.
Steven J

5

Tôi vừa gặp vấn đề này, sau khi thử mọi thứ được liệt kê ở trên và trên một số câu trả lời SO khác tôi phát hiện ra có nhiều hơn một định nghĩa base_url trong bảng core_config_data

Nếu bạn chạy

select * from core_config_data where path like '%base_url%'

Bạn sẽ thấy tất cả các định nghĩa phạm vi khác nhau trong định nghĩa này và đã ghi đè mặc định mà tôi đã thay đổi.


1
Cảm ơn bạn đã đăng bài, hy vọng điều này sẽ giúp ai đó một ngày nào đó tìm kiếm và tìm thấy câu hỏi này. Tôi chỉ muốn đề cập rằng trong trường hợp cụ thể của tôi chỉ có 1 trong cơ sở dữ liệu nên có lẽ vì cài đặt của tôi là một phạm vi duy nhất nên nó chỉ có một điều đó có nghĩa là điều này không giúp ích gì trong trường hợp của tôi. Thành thật mà nói tôi không thể nhớ tôi đã sửa cái mà tôi nên đăng kết quả ở đây khi tôi quay lại một lúc! Dù sao, tôi chắc chắn rằng điều này sẽ giúp được ai đó và là điều cần kiểm tra xem vấn đề có chắc chắn không, cảm ơn vì đã chia sẻ =)
JasonDavis

Tôi đã nói chuyện sớm, tôi biết giải pháp cho tôi là gì ... Có vẻ như bằng cách nào đó, kết quả / dữ liệu DB đã được lưu trữ trên máy chủ của chúng tôi, vì vậy sau nửa ngày tôi đã hết thời gian, tôi nghĩ rằng nó đã hoạt động. như mong đợi! Cho đến hôm nay tôi không biết tại sao hoặc điều gì đã khiến DB lưu trữ giá trị. Chúng tôi đã có Varness trên máy chủ gốc nhưng máy chủ mới gặp sự cố không có bộ đệm Varness nên ai biết được nhưng trong mọi trường hợp, đó là thứ gì đó trên máy chủ của chúng tôi lưu trữ dữ liệu!
JasonDavis 27/2/2015

2

Ngoài những gì bạn đã thử, tôi có thể nghĩ ra những lý do có thể sau:

  • Bộ nhớ cache cấu hình của Magento được lưu trữ trong một phụ trợ khác với các tệp trong /var/cache, ví dụ như memcache hoặc redis. Kiểm tra tệp app/etc/local.xmlvà xem nếu có một mục như

    <cache>
        <backend>memcached</backend>

    với bất cứ điều gì khác hơn là filesgiữa các backendthẻ. Tìm kiếm cách làm sạch bộ đệm cho phụ trợ cụ thể của bạn hoặc nếu bạn sử dụng n98-mageruncông cụ dòng lệnh tuyệt vời , hãy nhập n98-magerun cache:flushvào thư mục gốc Magento của bạn. Bạn có thể tải Magerun tại đây: https://github.com/netz98/n98-magerun

  • Cái base_urlnày được định nghĩa ở một nơi khác có độ ưu tiên cao hơn cơ sở dữ liệu. Điều này có thể app/etc/local.xmlhoặc bất kỳ tập tin xml khác trong app/etc. Bạn đã thực hiện tìm kiếm tên miền cũ trong cơ sở mã? Hãy thử chạy rgrep old-domain *trong thư mục gốc Magento.


Bullet point hai - bất cứ điều gì sử dụng đường dẫn cấu hình trong core_config_data cũng có thể được định nghĩa trong bất kỳ tệp localDB nào và một quan sát tốt khi tôi thấy mọi người cố gắng hack Magento hoạt động bằng cách thực hiện công cụ như thế này. Nó bị lãng quên một hoặc hai năm sau.
Phòng thí nghiệm Fiasco

2

Tôi đã từng gặp vấn đề tương tự

Hãy thử những gì tôi đã làm

BƯỚC 1: đăng nhập từ SSH và xóa bộ nhớ cache bằng lệnh này:

rm -rf /var/tmp/magento/*

BƯỚC 2 - Đặt lại GIẤY PHÉP FILE

Để đảm bảo rằng tất cả các tệp javascript, CSS và hình ảnh được tải chính xác, bạn nên đặt lại quyền truy cập tệp về cài đặt được đề xuất cho máy chủ mới của mình.

Chạy các lệnh sau từ thư mục gốc Magento của bạn (ví dụ: public_html):

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

Điều này sẽ đặt lại quyền cho tất cả các tệp thành CHMOD 644 và CHMOD 755 cho các thư mục.

PS: Để sử dụng Trình quản lý kết nối Magento, bạn có thể phải đặt lại cài đặt cấu hình PEAR. Để thực hiện việc này, chỉ cần xóa trình tải xuống tệp / Pearlib / pear.ini và một tệp mới sẽ được tạo tự động.

PS 2: Đừng quên kiểm tra tệp .htaccess nếu có bất kỳ chuyển hướng nào đến tên miền cũ


2

Short : Khởi động lại máy chủ web của bạn.

Long: Tôi đã thay đổi base_urls nhưng nó vẫn được chuyển hướng đến trang web cũ. Vì vậy, tôi đã xóa var / cache và thử nó với một trình duyệt ở chế độ riêng tư -> vẫn chuyển hướng đến trang web cũ.

Giải pháp là khởi động lại máy chủ apache2 của tôi với systemctl restart apache2


0

Tôi cũng đã từng gặp phải vấn đề này. Tôi đã xóa tất cả các file trong var/cache, var/sessionvà thay đổi base_urltrong bảng core_config_datađến URL mới. Nhưng vẫn là trang web chuyển hướng đến trang web cũ.

Tôi đã quên chỉnh sửa chi tiết cơ sở dữ liệu (tên người dùng, mật khẩu và dbname) config.xmltrong thư mục app/etc/:

   <username><![CDATA[myusername]]></username>
   <password><![CDATA[mypassword]]></password>
   <dbname><![CDATA[mydbname]]></dbname>

Bây giờ trang web của tôi đang chạy tốt sau khi tôi chỉnh sửa config.xml.


0

Tôi không nhớ phải làm điều này cho các phiên bản trước của Magento, nhưng chắc chắn, kể từ khi triển khai EE 1.14.3.3, tôi phải reindex URL để giải quyết vấn đề này.


0

Ồ vâng!

Đối với tôi cuối cùng những gì đã làm việc là:

php shell / indexer.php --reindexall qua ssh.

Nó xuất hiện, khá logic, sau khi các tệp đã được sao chép từ bản cài đặt trực tiếp trước đó, các url vẫn trỏ đến cửa hàng cũ và do đó phải được lập chỉ mục lại. Nhưng vì trang quản trị trong trường hợp này cũng sẽ không truy cập được, reindex sẽ phải thông qua ssh

Hy vọng nó cũng làm việc cho người khác!


Hoặc sử dụng magerun (./n98-magerun.phar index: reindex: all)
Đen

0

Nếu bạn đang sử dụng Google Chrome, hãy thử sử dụng một trình duyệt khác (Firefox, Edge, v.v.) trước khi bạn thử bất kỳ phương pháp nào khác và bạn có thể thấy rằng các địa chỉ hoạt động như bạn dự định. Chrome dường như thực hiện một số loại bộ nhớ đệm. Tôi đã lãng phí ít nhất một giờ thời gian của mình để xem các tập tin cấu hình và thử nghiệm mọi thứ.


Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.