Trên thực tế, các cảnh báo và thông báo không có hại, chúng chỉ là thông báo và đề xuất bạn khắc phục sự cố. Nếu bạn là nhà phát triển thì bạn phải luôn cố gắng xử lý tốt các thông báo và cảnh báo
Thông báo và cảnh báo xảy ra khi một cái gì đó chưa được xác định chẳng hạn. Nếu bạn đã tạo một biến trong PHP $customer_id sẽ nhận id khách hàng sau khi gửi biểu mẫu
Vui lòng tìm ở đây cách xử lý thông báo đúng cách nếu bạn là nhà phát triển. Lỗi PHP. Để ý. Chỉ số không xác định
Trong trường hợp bạn chưa phát triển tập lệnh và chỉ muốn tắt các cảnh báo và thông báo, hãy làm theo các bước bên dưới
Điều tồi tệ về WAMP là nó không cho phép bạn hoàn thành công việc mà không sửa lỗi. Vì vậy, tốt hơn hết hãy vô hiệu hóa nếu bạn cho rằng các lỗi là ổn và không có hại
Cách tắt cảnh báo và thông báo cho wamp
Mở php của bạn. ini trong bất kỳ trình soạn thảo văn bản nào nếu bạn không có bất kỳ tệp nào, bạn có thể sử dụng notepad ++. Visual Studio Code cũng là một phần mềm tuyệt vời và miễn phí để chỉnh sửa các tệp mã
Bây giờ hãy thử tìm dòng này
;error_reporting ....Thay thế dòng trên trong php của bạn. ini với dòng sau. Điều này sẽ vô hiệu hóa các thông báo và cảnh báo trong môi trường PHP cho WAMP của bạn
Nhiều lần, Chúng tôi đã nhận được một số câu hỏi về các cảnh báo hoặc Thông báo từ các thành viên của chúng tôi khi họ đang sử dụng tiện ích mở rộng của chúng tôi
Chào quản trị viên,
Khi tôi cài đặt mô-đun JV Content Fusion, tôi gặp lỗi này.
Thông báo. biến không xác định. seccount trong C. trình trợ giúp wampwwwjnuOfflinemodulesmod_jv_contenfusion. php trên dòng 112
Trợ giúp. Cảm ơn.
Đôi khi, nếu bạn đang làm việc với một số mã php và chán Cảnh báo hoặc Thông báo trong trình duyệt thì cách dễ dàng là tắt cài đặt trong PHP. tập tin ini. Đây là tệp cấu hình được tải mỗi khi bạn khởi động PHP+Apache. Nó đã làm mọi thứ mà nó phải làm nhưng đồng thời nó lại đưa ra các lỗi và cảnh báo không hợp lý và có hại cho ứng dụng
Đây là phương pháp để thay đổi cài đặt trong PHP. tập tin ini
mở PH. tập tin ini
Trong tệp này tìm kiếm cụm từ “ error_reporting = E_ALL” ,[không đảo dấu phẩy]
Ở đây thay thế bằng “error_reporting = E_ALL & ~E_NOTICE & ~E_WARNING”
[Hiển thị tất cả các lỗi, ngoại trừ các thông báo và cảnh báo tiêu chuẩn mã hóa]
Đảm bảo rằng bạn thay đổi phần kích hoạt thực sự của phần này, có một số ví dụ khác được đưa ra trong tệp
Đây là phần đăng lại những gì tôi đã viết trên blog của Trung tâm phát triển Acquia vào năm 2016, Tôi có nên tắt cảnh báo và thông báo PHP không?
Nhiều nhà phát triển làm việc trên các dự án Drupal [hoặc web/PHP khác] đã vô hiệu hóa báo cáo lỗi trong môi trường nhà phát triển cục bộ hoặc chia sẻ của họ, vì nhiều lý do—một số không biết cách bật tính năng này, một số khó chịu vì tần suất thông báo
Tuy nhiên, có một vài lý do quan trọng mà bạn nên đảm bảo hiển thị tất cả các lỗi khi phát triển
- Khi có một vấn đề lớn xảy ra trên địa điểm sản xuất của bạn, bạn sẽ cần phải xem nhật ký và tìm manh mối về những gì đang xảy ra. Và khi bạn làm như vậy, bạn càng có ít thông báo nhật ký 'ồn ào' thì càng tốt
- Ở một mức độ nhất định, khối lượng thư được ghi lại sẽ gây hại cho hiệu suất trang web của bạn [ngay cả khi bạn đang sử dụng nhật ký hệ thống thay vì ghi nhật ký cơ sở dữ liệu. ]. Tôi đã nghe nói về trường hợp hiệu suất tải trang là 1. Chậm hơn gấp 5 hoặc 2 lần đơn giản là do khối lượng thư PHP đã ghi
- Một số lỗi nguy hiểm nhất là những lỗi liên quan đến các biến không được khởi tạo, các đối tượng được truy cập dưới dạng mảng, v.v. —tất cả những thứ được ghi rõ ràng dưới dạng thông báo và cảnh báo [nhưng sẽ không làm hỏng trang web]
- Thông báo và cảnh báo giúp bạn xác định các khu vực trên trang web mà kiểu mã PHP của bạn có thể không phù hợp và bạn nên bắt đầu sử dụng PHP CodeSniffer hoặc PHP Mess Detector để giúp cải thiện chất lượng mã của mình
- Một trong những cách dễ dàng nhất để xem liệu một mô-đun đã đóng góp có bị hỏng hay không là kích hoạt mô-đun đó và đảm bảo không có thông báo/cảnh báo/lỗi mới nào bắt đầu xuất hiện trên khắp trang web của bạn
Thật không may, đối với nhiều trang web Drupal, thiệt hại đã được thực hiện và nếu bạn xem nhật ký hệ thống hoặc nhật ký giám sát, bạn sẽ tìm thấy hàng tá hoặc thậm chí hàng trăm lỗi cho mỗi yêu cầu trang. Hoặc tệ hơn, bạn sẽ thấy rằng các quản trị viên của trang đã vô hiệu hóa hoàn toàn việc ghi nhật ký vì khối lượng lỗi gây ra các vấn đề nghiêm trọng về hiệu suất
Những gì không làm
Nếu bạn đang làm bất kỳ điều gì trong số này, hãy thay đổi những điều này ngay lập tức để bắt đầu làm cho trang web của bạn tốt hơn
- Đừng tắt tiếng các lỗi PHP — trong quá trình sản xuất, hãy yêu cầu Drupal không ghi nhật ký thông báo lên màn hình, nhưng ít nhất hãy ghi chúng vào nhật ký hệ thống hoặc cơ sở dữ liệu [nhật ký hệ thống được ưu tiên vì lý do hiệu suất—ngoài ra nó còn tích hợp với nhật ký Acquia Cloud và các công cụ như ELK hoặc
- Không sử dụng
@để tắt các lỗi PHP [xem tôi có nên sử dụng @ để ẩn lỗi trong PHP không?] — bạn chỉ đang che đậy một vấn đề; - Không tắt tất cả ghi nhật ký lỗi — một số người tắt hoàn toàn ghi nhật ký lỗi, trên nhà phát triển, cục bộ và sản xuất. Đây là một ý tưởng rất tồi và sẽ dẫn đến rất nhiều khoản nợ kỹ thuật
Tắt tiếng lỗi hoặc vô hiệu hóa tất cả ghi nhật ký là một ý tưởng rất tồi;
Lỗi có vai trò rất quan trọng. họ chỉ ra rằng có điều gì đó không ổn. Ức chế không giải quyết được vấn đề cơ bản. Đây còn được gọi là "Phương pháp Nga". Khi đèn báo động trong nhà máy hạt nhân bắt đầu nhấp nháy, chỉ cần tháo bóng đèn ra. Đèn cảnh báo không còn nhấp nháy; . []
Bình luận này đề cập đến thảm họa Chernobyl; . PHP có cơ chế ghi lỗi là có lý do—đó là để bạn có thể sửa chữa trang web mong manh của mình trước khi nó kết thúc trong thảm họa
phải làm gì
Bạn không thể sửa những gì bạn không thể nhìn thấy, vì vậy điều quan trọng nhất là hiển thị tất cả các lỗi trong khi phát triển trên môi trường phát triển cục bộ và chia sẻ. drupal. org có trang tài liệu hướng dẫn cách thực hiện việc này. Hiển thị tất cả các lỗi trong khi phát triển. Drupal VM bao gồm tiện ích xem nhật ký mà bạn có thể sử dụng để xem lỗi. Hầu hết các máy chủ web đều có giao diện nơi bạn có thể xem nhật ký trực tiếp hoặc ở dạng có thể tải xuống. Biết chúng, sử dụng chúng
Bạn nên có một ngân sách lỗi. "nếu có X thông báo/cảnh báo/lỗi được ghi lại trở lên trong khoảng thời gian Y, chúng tôi sẽ ngừng làm việc với các tính năng mới trên trang web và thay vào đó sẽ làm việc để khắc phục những sự cố đó". Đối với một số đội, X là một hoặc nhiều; . Điều quan trọng là đảm bảo rằng bạn luôn kiểm soát được nó—bạn không muốn có một trang web siêu mỏng manh với hàng tấn nhật ký mà bạn phải xem qua khi có sự cố xảy ra
Nếu trang web của bạn đã vượt quá ngân sách lỗi của bạn [e. g. nếu bạn thấy nhiều lỗi trên trang chủ hơn trang chủ trong môi trường phát triển của mình], hãy cố gắng sửa lỗi ngay bây giờ—ROI là rất lớn, bởi vì hầu hết thời gian, một sửa lỗi nhỏ [e. g. đảm bảo một biến được đặt chính xác ở đâu đó] có thể giải quyết hàng chục hoặc thậm chí hàng nghìn lỗi
Ẩn tin nhắn trên màn hình trong quá trình sản xuất, nhưng ghi chúng vào nhật ký hệ thống. Trên /admin/config/development/logging, hãy đặt 'Không' cho "Thông báo lỗi hiển thị"], đảm bảo bạn đã bật mô-đun Syslog. Nếu bạn có một trang web có lưu lượng truy cập thấp hoặc chỉ cần một giao diện thực sự đơn giản để xem các thông báo đã ghi [và có thể chịu tác động nghiêm trọng đến hiệu suất khi có nhiều hoạt động], bạn có thể cân nhắc sử dụng Nhật ký cơ sở dữ liệu thay vì Syslog. Acquia Cloud thậm chí truyền phát và tổng hợp nhật ký của bạn khi bạn sử dụng Syslog;
Câu hỏi hóc búa về Drupal 6
Một trong những lý do cuối cùng tôi đã viết bài đăng trên blog này [Tôi đã có một bản nháp nằm trong hồ sơ của mình hơn sáu năm. ] là do một số sự cố gần đây đã làm nổi bật một vấn đề lớn đối với những trang web vẫn đang chạy Drupal 6—lõi Drupal 6 và nhiều mô-đun đóng góp của Drupal 6, đưa ra rất nhiều thông báo và cảnh báo nếu bạn chạy chúng với phiên bản PHP được hỗ trợ tích cực [ . 6 hoặc 7. 0]. Kể từ PHP 5. 3 và 5. 4 hiếm khi được hỗ trợ ngày nay và PHP 5. 5 ngày càng khó tìm, có nhiều trường hợp bạn phải chạy một trang web Drupal 6 trên PHP 5. 6 máy chủ. nghĩa là nhật ký của bạn khá đầy đủ
Trước tiên, tôi tranh luận rằng bạn nên coi đây là lý do #1284 tại sao bạn nên nâng cấp lên Drupal 7 hoặc 8 càng sớm càng tốt, nhưng thứ hai, trong một số trường hợp hiếm hoi mà bạn nhất thiết phải duy trì và chạy một trang web Drupal 6, bạn có thể phải phá vỡ một số . Điều này nên được coi là 'tùy chọn hạt nhân' và có lẽ sẽ thúc đẩy bạn bỏ bất kỳ mô-đun nào trên trang web Drupal cũ gây ra nhiều thông báo hoặc thúc đẩy nâng cấp sớm hơn.