Làm cách nào để loại bỏ các lỗi 404 lạ trong wp-admin?

Tôi chạy một trang web WordPress với khoảng 70 plugin hoạt động.

Mỗi lần như vậy, tôi sẽ nhận được một trang lỗi ngẫu nhiên ("Không tìm thấy", mặc dù tôi đã không kiểm tra các tiêu đề để xem đó có phải là 404 không) trên một /wp-admin/trang bật ra khỏi hư không.

Đơn giản chỉ cần thử lại giải quyết lỗi, tuy nhiên sẽ khá bất tiện nếu lỗi xảy ra trong quá trình nâng cấp plugin (vì tự động kích hoạt lại không thành công). Tôi nghĩ vấn đề tương tự này chịu trách nhiệm cho một số mô-đun nhất định trên Bảng điều khiển của tôi đôi khi không tải được.

Đưa ra danh sách các plugin tôi đã cài đặt , có ai biết vấn đề với hoặc giữa bất kỳ plugin nào có thể gây ra sự cố này không?

Biên tập:

Thông tin lưu trữ: Dreamhost; Tôi nghĩ rằng máy chủ đang chạy bản dựng Debian tùy chỉnh với Apache httpd

tôi đã có vấn đề cả ngày với những gì dường như là sai lầm 404.

Dù sao, tôi vừa trò chuyện với một người hỗ trợ công nghệ dreamhost, người nói với tôi rằng tài khoản người dùng tôi có với họ đã đạt giới hạn tài nguyên bộ nhớ (tất cả các quy trình) và đó là điều gây ra những vấn đề kỳ lạ, có vẻ liên quan đến htaccess. tôi đã nhận được các lỗi 404 không liên tục từ một tập tin htaccess không nên được gọi! đó là dreamhost với một máy chủ ngôi nhà ma ám.

Rõ ràng, quá trình giết robot mà dreamhost sử dụng sẽ giết chết một quy trình web ở giữa và sau đó vì một lý do nào đó, apache (bây giờ là zombie) thực sự cố gắng hoàn thành công việc của mình (cố gắng hết sức để thoát khỏi kết thúc vô duyên đến một cuộc chinh phục là dự đoán tốt nhất của tôi). nó ném một lỗi 500 vào nhật ký http chính, nhưng sau khi làm như vậy, nó thực sự loại bỏ điều kiện ghi lại và quy tắc không bao giờ được kích hoạt (sử dụng tệp tiêu chuẩn -f và thư mục -d htaccess ở trên) - và nó không 't viết một mục nhật ký mới! một yêu cầu mới (người vô hình) sau đó kích hoạt tệp chỉ mục trong dòng cuối cùng của tệp htaccess

coi chừng giới hạn tài nguyên trong tài khoản cơ bản dreamhost! Nếu bạn vượt qua giới hạn của họ và bạn có htacess với các dòng mod_rewrite, bạn sẽ thấy những điều kỳ lạ chỉ phù hợp cho đêm halloween - những người đàn ông vô hình, bị ám ảnh 404s! quá trình undead! thây ma! htaccess tự di chuyển! yike!

Hy vọng điều này sẽ giúp bạn tránh được vài giờ đau đớn.

Cách duy nhất để gỡ lỗi này là tắt một plugin một lần, mỗi lần cố gắng tái tạo vấn đề trước khi bạn tắt plugin khác. Bắt đầu với các plugin có liên quan đến quản trị WP, sau đó chuyển xuống các plugin chủ đề thông thường, các tiện ích, v.v.

Kiểm tra trang "Không tìm thấy" mà bạn được phục vụ tốt hơn (duyệt bằng Opera và mở bảng Thông tin sẽ hiển thị cho bạn các tiêu đề, thay thế duyệt bằng Firefox và bật Firebird với bảng "Net" được bật) và thực hiện tìm kiếm thông qua tất cả các plugin của bạn để xem liệu chúng có thể được phục vụ trực tiếp không. Nếu không, hãy xem nhật ký của máy chủ web để tìm hiểu tài nguyên chính xác mà nó không thể phục vụ; một plugin có thể đang thực hiện một số chuyển hướng hoặc viết lại ưa thích để nó không nhất thiết phải là URL bạn thấy trong trình duyệt gây ra 404.

Tôi chỉ có thể liên quan đến trải nghiệm của riêng mình và cho đến nay, tôi chưa tìm thấy quy tắc "xác định" để khắc phục tất cả các vấn đề trong một cú đánh.

Vấn đề chính với thiết lập của Dreamhost là, trong cuộc chiến vĩnh cửu để giữ mức tiêu thụ bộ nhớ ở mức tối thiểu, điều đó có nghĩa là loại bỏ càng nhiều tính năng càng tốt - cụ thể là, tất cả sẽ làm giảm băng thông (tốt cho khách truy cập!) Hoặc CPU (tốt đối với máy chủ, nhưng Dreamhost không kiểm soát mức tiêu thụ CPU mạnh như khi họ kiểm soát RAM). Chẳng hạn, điều này có nghĩa là loại bỏ HTML + CSS (sẽ tiêu tốn CPU + RAM) hoặc bất kỳ plugin nào trong số các plugin Minify (cũng sẽ tiêu thụ RAM). Bộ nhớ cache càng tinh vi (tôi thích sử dụng W3 Total Cache hoặc ít nhất là WP Super Cache), RAM cũng sẽ được tiêu thụ nhiều hơn.

Tương tự, nhiều plugin giới hạn số lượng truy vấn MySQL để cải thiện hiệu suất thay vào đó sẽ tiêu tốn RAM. Vì vậy, tìm kiếm một sự đánh đổi mà bạn vẫn có thể giữ cho trang web của mình trả lời với hiệu suất tốt trong khi tránh tiêu thụ RAM quý giá là một việc khó khăn!

Cho đến nay, kết quả tốt nhất của tôi trên các trang web bận rộn là bỏ chọn Tối ưu hóa tốc độ trang và bảo mật web bổ sung, điều này rõ ràng sẽ tiêu tốn rất nhiều RAM và thay vào đó dựa vào sự kết hợp với W3 Total Cache và Cloudflare (dịch vụ proxy ngược miễn phí). Cloudflare thực sự sẽ làm điều tương tự như mô-đun "Extra Web Security", nhưng vì nó chạy bên ngoài Dreamhost, nên nó vẫn ổn. W3 Total Cache tiêu tốn rất nhiều bộ nhớ nhưng một khi các trang được lưu trữ cục bộ, Cloudflare sẽ lưu trữ chúng rất hiệu quả - vì vậy bạn có thể nhận được 404/500 trong khi chỉnh sửa bài đăng, ít nhất khách truy cập của bạn sẽ không trải nghiệm chúng (Cloudflare cũng có thể phục vụ các trang tĩnh ngay cả khi Dreamhost cho 404 hoặc 500).

Ngoài ra, nhờ bài viết này , tôi đã phát hiện ra rằng FastCGI sử dụng nhiều RAM hơn so với CGI 'bình thường'. Và vì PHP 5.3 tốt hơn trong việc quản lý RAM (thu gom rác mạnh hơn, ít rò rỉ bộ nhớ hơn), tôi đã thử nghiệm chuyển sang PHP 5.3 CGI (không phải FastCGI) mà không cần Tối ưu hóa tốc độ trang cũng như Bảo mật web bổ sung, dựa vào W3 Total Cache + Cloudflare để tăng tốc trang web. Bây giờ, backoffice chậm hơn (tiêu thụ CPU nhiều hơn!) Nhưng ít nhất tôi không thấy 404/500 (cho đến nay!).

Tôi vẫn không hài lòng với sự kết hợp này, vì vậy tôi chắc chắn sẽ tiếp tục điều chỉnh các cài đặt của Dreamhost với hy vọng giảm mức tiêu thụ RAM hơn nữa và vẫn có hiệu suất đầy đủ. Giống như @dgw đã nói, tôi cũng sử dụng rất nhiều plugin - vì tôi yêu cầu chức năng của chúng. Không phải tất cả mọi người lưu trữ WP với Dreamhost đều có nhu cầu viết blog đơn giản; Trang web càng phức tạp thì càng cần nhiều chức năng ... và đó là vẻ đẹp của WordPress, bạn chỉ cần sử dụng các plugin bạn thực sự cần và giữ cho WP cài đặt đơn giản nếu bạn hài lòng với vài nhu cầu. Tuy nhiên, các plugin không nhất thiết là "xấu" hoặc nặng trên trang web; nhưng sự thật là một số có thể tiêu thụ rất nhiều RAM ...

Đây chỉ là một ý tưởng sơ bộ: Nếu bạn gặp lỗi 404 "thực" (với các tiêu đề được đặt), thì bạn có thể tìm kiếm thông qua các plugin của mình và tìm kiếm hàm PHPheader() và số 404. Điều này có thể khoan số lượng plugin từ 70 xuống chỉ còn một số. Sau đó, bạn chỉ cần kiểm tra cho những.

Điều này có thể dễ dàng thực hiện với một IDE như PDT của Eclipse cung cấp tìm kiếm cho một lệnh gọi hàm PHP cụ thể.

Bên cạnh đó nhưng không có gì đảm bảo rằng nó hoạt động thành công, là viết một plugin nối vào cài đặt tiêu đề và sau đó cho bạn theo dõi mã nào thực sự đang đặt ra một tiềm năng 404 (backtrace). Điều này sẽ chỉ hoạt động nếu plugin đang sử dụng chức năng API WordPress. Phương pháp đầu tiên để tìm kiếm chức năng PHP sẽ hoạt động bất kể API WP.

Thêm thông tin cần thiết:

1) Tại sao nhiều plugin như vậy?

2) Nhà cung cấp dịch vụ lưu trữ của bạn đang chạy hệ điều hành nào?

3) Máy chủ web nào?

4) Bạn có quyền truy cập vào nhật ký máy chủ httpd, đặc biệt là nhật ký lỗi không?

5) Nhật ký lỗi nói gì trong khung thời gian xung quanh các vấn đề này?

(Bây giờ, sự thật được nói, nếu chúng ta khái quát cho "J6P trung bình đang chạy WordPress có thể có câu hỏi chính xác này, chúng ta có thể bắt đầu bằng cách chỉ đạo J6P nói để trả lời ít nhất 5 câu hỏi trên ...)