WordPress-ის თეთრი ეკრანი და 500 შეცდომა: როგორ გავასწოროთ

ცარიელი გვერდი, 500, "There has been a critical error on this website" და "Error establishing a database connection" ოთხ სხვადასხვა პრობლემას ჰგავს, მაგრამ უმეტესად ორია: ან PHP გაჩერდა შენი კოდის შესრულებისას, ან PHP-მ MySQL-თან ვერ დაამყარა კავშირი. იმის გასარკვევად, რომელია ეს, ვარაუდი შეწყვიტე და შეცდომა წაიკითხე. wp-config.php-ში ჩართე WP_DEBUG_LOG, დაზიანებული გვერდი ერთხელ გადატვირთე და გახსენი wp-content/debug.log და PHP-ის error log. ათიდან ცხრა შემთხვევაში ბოლო ხაზში ჩანს plugin-ის ან თემის ფაილი და მიზეზი. თუ არ ჩანს, გაიარე ამ პოსტში მოცემული თანმიმდევრობა: გადაარქვი სახელი plugins საქაღალდეს, გადადი სტანდარტულ თემაზე, გაზარდე მეხსიერების ლიმიტი, თავიდან შექმენი rewrite წესები, შეამოწმე ბაზის მონაცემები და მხოლოდ ამის შემდეგ შეაკეთე ბაზა.

ყველაფერი, რაც ქვემოთაა, მხოლოდ ფაილ მენეჯერით ან SFTP-ით კეთდება. ზუსტად ამ მდგომარეობაში ხარ ხოლმე, როცა დაფა აღარ იხსნება.

რას ნიშნავს თითოეული შეცდომა სინამდვილეში#

ბრაუზერი ძალიან ცოტას გიჩვენებს, და ისიც იმაზეა დამოკიდებული, როგორ გაჩერდა PHP. ეს ცხრილი მთელი პოსტის რუკაა.

კლასიკური "თეთრი ეკრანი" ამათგან ყველაზე ძველია. WordPress 5.2-მდე plugin-ის ნებისმიერი ფატალური შეცდომა ცარიელ გვერდს იძლეოდა. მას შემდეგ WordPress ფატალური შეცდომების უმეტესობას იჭერს, აჩვენებს "critical error" შეტყობინებას და ადმინისტრატორს წერილს უგზავნის. დღეს ნამდვილად ცარიელი გვერდი ჩვეულებრივ სამიდან ერთ-ერთს ნიშნავს: შეცდომა მოხდა მანამ, სანამ WordPress მას დაიჭერდა (სინტაქსური შეცდომა wp-config.php-ში ან ადრე ჩატვირთულ ფაილში), ფატალური შეცდომა თავად შეცდომების დამმუშავებელში მოხდა, ან PHP-ს მეხსიერება იმდენად მთლიანად ამოეწურა, რომ ვერაფრის დაბეჭდვა მოახერხა.

500 სხვა დონის საკითხია. ეს ვებსერვერის სტატუს კოდია და მხოლოდ იმას ამბობს, რომ "სერვერზე რაღაც ჩავარდა". 500-ს იძლევა PHP-ის ავარიაც, გაფუჭებული rewrite წესიც, წვდომის უფლებების პრობლემაც, დროის ლიმიტს გადაცილებული მოთხოვნაც და მეხსიერების გადამეტების გამო მოკლული PHP პროცესიც. ამიტომ პირველი ამოცანა ყოველთვის ერთი და იგივეა: იპოვე ლოგის ის ხაზი, რომელიც ჩავარდნილ მოთხოვნას შეესაბამება.

კიდევ ერთი განსხვავება დროს გაგიმარტივებს. თუ მხოლოდ ადმინ გვერდები არ მუშაობს და საიტის საჯარო ნაწილი მუშაობს, ან პირიქით, პრობლემა კოდშია, რომელიც მხოლოდ ერთ მხარეს იტვირთება - თემის შაბლონში, plugin-ის ადმინ გვერდზე, ვიჯეტში. თუ ყველაფერი ვარდება, სტატიკური ფაილის ჩათვლით, როგორიცაა /readme.html, პრობლემა WordPress-ზე დაბლაა: სერვერში, PHP-ის ვერსიაში ან ფაილურ სისტემაში. გახსენი /readme.html და ნახე, იტვირთება თუ არა. თუ იტვირთება, ვებსერვერი კარგადაა და დამნაშავე PHP ან WordPress არის.

ჯერ ჩართე ლოგირება: WP_DEBUG და debug.log#

ამ პოსტის ყველა გამოსწორება უფრო სწრაფად მიდის, როცა ნამდვილ შეცდომას კითხულობ. WordPress-ს ამისთვის სამი კონსტანტა აქვს და სამივე wp-config.php-ში იწერება იმ ხაზის ზემოთ, სადაც წერია That's all, stop editing!.

define( 'WP_DEBUG', true );define( 'WP_DEBUG_LOG', true );define( 'WP_DEBUG_DISPLAY', false );@ini_set( 'display_errors', 0 );

რას აკეთებს თითოეული:

• WP_DEBUG რთავს WordPress-ის საკუთარ შეცდომების ანგარიშგებას. მისი ნაგულისხმევი მნიშვნელობა false-ია.
• WP_DEBUG_LOG შეცდომებს წერს wp-content/debug.log-ში. true-ს ნაცვლად გზაც შეიძლება მიუთითო, თუ ლოგის სხვაგან შენახვა გირჩევნია.
• WP_DEBUG_DISPLAY განსაზღვრავს, იბეჭდება თუ არა შეცდომები გვერდზე. მისი ნაგულისხმევი მნიშვნელობა true-ა, ამიტომ მოქმედ საიტზე გამართვის სესიამ შეიძლება ყველა სტუმარს ფაილების გზები გაუმხილოს. დააყენე false და ლოგი წაიკითხე.

ხაზი @ini_set( 'display_errors', 0 ) ორმაგი დაზღვევაა: სხვაგვარად WordPress-ის debug რეჟიმმა შეიძლება ჩართოს ჩვენება იმ ჰოსტებზე, სადაც თვით PHP-ის პარამეტრი ჩართულია.

ახლა დაზიანებული გვერდი ერთხელ გახსენი და ფაილ მენეჯერში გახსენი wp-content/debug.log. საჭირო ხაზები ასე გამოიყურება:

[16-Oct-2026 09:12:41 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function  gutenberg_get_block_template() in /wp-content/plugins/old-slider/slider.php:88[16-Oct-2026 09:12:41 UTC] PHP Fatal error:  Allowed memory size of 134217728 bytes  exhausted (tried to allocate 20480 bytes) in /wp-includes/class-wp-hook.php on line 324

წაიკითხე გზა და არა შეტყობინება. /wp-content/plugins/old-slider/ plugin-ს ასახელებს. /wp-content/themes/mytheme/functions.php თემას ასახელებს. გზა /wp-includes/ ან /wp-admin/ საქაღალდეში მეხსიერების შეტყობინებასთან ერთად ჩვეულებრივ დამნაშავეს კი არა, მსხვერპლს აჩვენებს: მოთხოვნის ადრინდელმა ნაწილმა გამოიყენა მეხსიერება, ხოლო ბირთვი ის კოდი აღმოჩნდა, რომელიც მეხსიერების ამოწურვისას მუშაობდა.

თუ debug.log არ გაჩნდა, ჩვეულებრივი მიზეზებია: wp-config.php "stop editing" ხაზის ქვემოთ შეცვალე (კონსტანტები wp-settings.php-ის ჩატვირთვამდე უნდა იყოს), wp-content PHP-ის მომხმარებლისთვის ჩასაწერი არ არის, ან შეცდომა WordPress-ის გაშვებამდე ხდება. ბოლო შემთხვევაში PHP-ის error log ერთადერთი ჩანაწერია.

PHP error log-ის კითხვა#

debug.log მხოლოდ იმას შეიცავს, რაც WordPress-ის დამმუშავებელმა დაინახა. PHP-ის საკუთარი error log უფრო ფართოა: ის იჭერს parse შეცდომებს, ფატალურ შეცდომებს WordPress-ის ჩატვირთვამდე და გაფართოებების გაფრთხილებებს. სად არის, php.ini-ს error_log დირექტივაზეა დამოკიდებული; თუ ის დაყენებული არ არის, შეცდომები ვებსერვერის error log-ში ან პროცესის standard error-ში მიდის.

შეამოწმე სკრიპტით, რადგან პასუხი თითოეულ კონფიგურაციაში განსხვავებულია. ჩასვი ეს ფაილში, ერთხელ გახსენი და შემდეგ წაშალე:

<?phpecho ini_get( 'error_log' ) ?: 'not set - using the server or stderr';echo "\n", ini_get( 'log_errors' ) ? 'log_errors on' : 'log_errors off';echo "\n", php_ini_loaded_file();

თუ shell გაქვს, გვერდის გადატვირთვისას ლოგს თვალი ადევნე:

$ tail -f /path/to/php_errors.log

პანელზე დაფუძნებულ სერვერზე კონსოლი ის ადგილია, სადაც ვებსერვერისა და PHP-ის გამოტანა ჩანს, ხოლო ფაილ მენეჯერი - სადაც PHP-ის მიერ ჩაწერილი ნებისმიერი ლოგ ფაილია. განსხვავება 500-ს შორის, რომლის დროსაც ლოგში PHP-ის ფატალური შეცდომაა, და 500-ს შორის, რომლის დროსაც PHP-ის ლოგი ცარიელია, თავისთავად სასარგებლოა. ლოგში ფატალური შეცდომა ნიშნავს, რომ უნდა გაასწორო მასში დასახელებული კოდი. ცარიელი PHP ლოგი და 500 ნიშნავს, რომ მოთხოვნა PHP-მდე არ მისულა, ანუ პრობლემა ვებსერვერის კონფიგურაციაშია, .htaccess-ში, ან პროცესი მოკლეს. ლოგებთან მუშაობის ზოგადი მიდგომა აღწერილია პოსტში game server logs explained. ის თამაშის სერვერებზეა, მაგრამ ჩვევა იგივეა: ლოგი ბოლოდან იკითხება და დროის ნიშნულები შენს მოთხოვნას ემთხვევა. PHP-ის ლოგირების პარამეტრებისთვის სრულად იხილე php.ini settings that matter.

გამორთე plugin-ები დაფის გარეშე#

თეთრი ეკრანის უმეტეს შემთხვევაში plugin არის მიზეზი და მის გამოსართავად ადმინ გვერდი არ გჭირდება. WordPress plugin-ებს მხოლოდ wp-content/plugins-იდან ტვირთავს. გადაარქვი ამ საქაღალდეს სახელი და ყველა plugin ჩატვირთვას წყვეტს.

1. გახსენი ფაილ მენეჯერი ან დაუკავშირდი SFTP-ით (SFTP and the file manager კავშირის დეტალებს განმარტავს).
2. wp-content/plugins გადაარქვი wp-content/plugins.off-ად.
3. გადატვირთე საიტი. თუ შეცდომა გაქრა, plugin იყო მიზეზი.
4. საქაღალდეს დაუბრუნე სახელი plugins. WordPress ყველა plugin-ს გამორთულად აჩვენებს, რადგან ვერ იპოვა.
5. plugins-ის შიგნით საქაღალდეებს სახელი სათითაოდ ან ნახევრებად გადაარქვი, რომ დამნაშავე იპოვო. დანარჩენები დაფიდან ჩართე.

ცალკეული plugin-ის საქაღალდის გადარქმევა იმავე წესით მუშაობს და უფრო სწრაფია, თუ debug.log-მა ის უკვე დაასახელა. საქაღალდის სახელის ბოლოში დაამატე -disabled, და არა დასაწყისში სიმბოლო, რომ დაინახო, რა შეცვალე.

WP-CLI-ით, თუ shell-ში ის დაყენებულია, იგივე ორი-სამი ბრძანებაა და ფაილებს არ ეხება:

$ wp plugin list --status=active$ wp plugin deactivate --all$ wp plugin activate woocommerce

თუ WP-CLI არ ირთვება, რადგან გაფუჭებული plugin WordPress-ს ჩატვირთვისას ანგრევს, ნებისმიერ ბრძანებას დაამატე --skip-plugins: wp plugin deactivate --all --skip-plugins. არსებობს შესაბამისი --skip-themes-იც. ჩვენ არ დაგვიდასტურებია, რომ ყველა პაკეტის კონსოლი WP-CLI-იან shell-ს გაძლევს, ამიტომ ფაილ მენეჯერის გზა ისეთად ჩათვალე, რომელიც ყოველთვის მუშაობს.

ორი გაფრთხილება. პირველი: mu-plugins ცალკე საქაღალდეა, "must-use", და იტვირთება მაშინაც, როცა არაფერია ჩართული. ზოგი ჰოსტი და cache plugin იქ ფაილს დებს. თუ plugins-ის გადარქმევამ არაფერი შეცვალა, გახსენი wp-content/mu-plugins და ის საქაღალდეც გადაარქვი. მეორე: wp-content/advanced-cache.php და wp-content/object-cache.php cache plugin-ების დატოვებული drop-in ფაილებია. ისინი plugin-ებზე ადრე იტვირთება და წაშლილ plugin-ზე მიმთითებელი ფაილი ყველაფერს გააფუჭებს. თუ ლოგი რომელიმეს ასახელებს, სახელი გადაარქვი.

გადადი სტანდარტულ თემაზე#

თუ plugin-ები არ არის პრობლემა, შემდეგი თემაა. თემის functions.php ყოველ მოთხოვნაზე სრულდება და მასში ერთი შეცდომა მთელ საიტს აგდებს, wp-admin-ის ჩათვლით. ჩვეულებრივი მიზეზებია: თემის რედაქტორში გაკეთებული ცვლილება, თემის განახლება, რომელსაც PHP-ის უფრო ახალი ვერსია სჭირდება, ან child თემა, რომლის parent საქაღალდეს სახელი გადაერქვა.

აქტიური თემის საქაღალდე გზიდან გადაწიე. wp-content/themes-ში გაფუჭებულ თემას გადაარქვი სახელი, მაგალითად mytheme გახდეს mytheme-off. როცა WordPress აქტიურ თემას ვერ პოულობს, ის ნებისმიერ სტანდარტულ თემაზე გადადის, რომელსაც იპოვის, ამიტომ ერთი უნდა იყოს დაყენებული: twentytwentyfive ან ნებისმიერი ახალი სტანდარტული. თუ არცერთია, ატვირთე wordpress.org-დან zip-ის wp-content/themes-ში გახსნით; ფაილ მენეჯერი არქივებს ადგილზე ხსნის.

shell-ით და WP-CLI-ით:

$ wp theme list$ wp theme activate twentytwentyfive

ჩაანაცვლე იმ სტანდარტული თემის სახელით, რომელიც რეალურად დაყენებულია. გადართვის შემდეგ თუ საიტი მუშაობს, ესე იგი, პრობლემა თემაში იყო. თუ თემა მხოლოდ ერთი ტიპის გვერდზე ვარდება, მაგალითად ცალკეულ პოსტებზე ან მაღაზიაში, პრობლემა ამ ტიპის შაბლონ ფაილშია; გზას debug.log დაგისახელებს.

PHP-ის მეხსიერება: memory_limit და WP_MEMORY_LIMIT#

შეტყობინება Allowed memory size of 134217728 bytes exhausted ერთადერთი შეცდომაა, რომელიც საკუთარ გამოსწორებას თავად ასახელებს, თუმცა ყოველთვის სწორს არა. 134217728 ბაიტი 128 MB-ია, რაც PHP-ის memory_limit-ის გავრცელებული ნაგულისხმევი მნიშვნელობაა. "tried to allocate" რიცხვი ბოლო წვეთია და არა ჯამი. ოთხი მნიშვნელობა ერთმანეთზე გავლენას ახდენს:

WP_MEMORY_LIMIT არის ის, რასაც WordPress PHP-ს სთხოვს საიტის საჯარო ნაწილის მოთხოვნისთვის. მას ლიმიტის ამაღლება მხოლოდ იმდენად შეუძლია, რამდენსაც სერვერი იძლევა, ამიტომ მისი memory_limit-ზე მაღლა დაყენება უჩუმრად შეიძლება არ იმუშაოს, თუ ჰოსტი memory_limit-ს pool დონეზე ბლოკავს. WP_MAX_MEMORY_LIMIT უფრო მაღალი ზღვარია, რომელსაც WordPress ადმინისტრაციული ამოცანებისთვის იყენებს, მაგალითად სურათების ზომის შეცვლისა და განახლებებისთვის.

define( 'WP_MEMORY_LIMIT', '256M' );define( 'WP_MAX_MEMORY_LIMIT', '512M' );

თუ ამან არაფერი შეცვალა, თვით memory_limit გაზარდე php.ini-ში, ან საიტის root-ში .user.ini-ში, თუ შენი PHP FPM-ით ან CGI-ით მუშაობს:

memory_limit = 256M

.user.ini რამდენიმე წუთით cache-დება, ამიტომ დაელოდე, სანამ გადაწყვეტ, რომ არ იმუშავა. ამის გრძელი ვერსია, იმის ჩათვლით, თუ რატომ იწვევს .htaccess-ში php_value ხაზები FPM-ზე 500-ს, არის php.ini settings that matter-ში.

ლიმიტის ზრდა ლაქაა და არა გამოსწორება, როცა რაღაც მეხსიერებას ჭამს. ერთი გვერდი, რომელსაც 256 MB-ზე მეტი სჭირდება, თითქმის ყოველთვის ან plugin-ია, რომელიც უზარმაზარ მოთხოვნის შედეგს ტვირთავს, ან გაფუჭებული იმპორტია, ან ციკლი. თუ მეხსიერება იმავე 128 MB-ზე ან 256 MB-ზე იწურება, რაც არ უნდა მაღლა დააყენო, ლოგის ხაზში ფაილის გზა გეტყვის, ვინ აკეთებს ამას.

PHP-ზე მაღლა კიდევ ერთი ზღვარია. container-ზე დაფუძნებულ პაკეტზე პროცესი პაკეტის RAM-ზე მეტს ვერ გამოიყენებს, რაც არ უნდა წეროს memory_limit-მა. 1 GB memory_limit 1 GB პაკეტზე რამდენიმე ერთდროული მოთხოვნით პროცესის მოკვლით მთავრდება და არა PHP-ის მოწესრიგებული შეტყობინებით; სტუმარი 500-ს ან გაწყვეტილ კავშირს ხედავს, PHP-ის ლოგში კი არაფერია. RE:NODE-ზე სერვერი, რომელიც მეხსიერების ლიმიტს მიაღწევს, ბირთვის მიერ ჩერდება და swap-ის ნაცვლად სუფთად ირთვება თავიდან, ხოლო კონსოლის გრაფიკები მეხსიერებას ლიმიტთან ერთად აჩვენებს, ამიტომ ხერხისებრი გრაფიკი, რომელიც ხაზს ეხება და ეცემა, ამის ნიშანია. How much RAM does WordPress need განიხილავს ზომის შერჩევას PHP worker-ების მიხედვით, და სწორედ ასე წყდება, ლიმიტი გაზარდო თუ უფრო დიდი პაკეტი აიღო.

500 შეცდომები, .htaccess და permalink-ები#

500, რომლის უკან PHP-ის შეცდომა არ დგას, თითქმის ყოველთვის ვებსერვერის კონფიგურაციაა. შემდეგი ნაბიჯი იმაზეა დამოკიდებული, რომელ ვებსერვერს იყენებს შენი პაკეტი, და ეს ჰოსტის მიხედვით განსხვავდება. RE:NODE-ის web პაკეტებისთვის ამას არ ვადასტურებთ, ამიტომ ორი შემთხვევა ცალ-ცალკეა მოცემული.

თუ შენი პაკეტი Apache-ს იყენებს, ან ნებისმიერ სერვერს, რომელიც .htaccess-ს კითხულობს, ეს ფაილი ჩვეულებრივი ეჭვმიტანილია. მასში ცუდი დირექტივა, მაგალითად php_value ხაზი PHP-FPM-ზე, ჩასმული წესი მოდულისთვის, რომელიც ჩატვირთული არ არის, ან ზედმეტი სიმბოლო ყველა მოთხოვნაზე 500-ს იძლევა. თავიდან შექმენი:

1. საიტის root-ში .htaccess გადაარქვი .htaccess.bak-ად. ფაილ მენეჯერში დამალული ფაილების გამოსაჩენად შეიძლება ჩამრთველი დაგჭირდეს.
2. გადატვირთე საიტი. მთავარი გვერდი ახლა შეიძლება მუშაობდეს, პოსტები კი 404-ს აბრუნებდეს.
3. დაფაში გადადი Settings, შემდეგ Permalinks-ზე და დააჭირე Save-ს არაფრის შეცვლის გარეშე. WordPress ახალ ფაილს ჩაწერს.

თუ დაფამდე ვერ მიდიხარ, ფაილი ხელით შექმენი WordPress-ის სტანდარტული ბლოკით:

# BEGIN WordPress<IfModule mod_rewrite.c>RewriteEngine OnRewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]RewriteBase /RewriteRule ^index\.php$ - [L]RewriteCond %{REQUEST_FILENAME} !-fRewriteCond %{REQUEST_FILENAME} !-dRewriteRule . /index.php [L]</IfModule># END WordPress

WP-CLI-ით wp rewrite flush --hard ფაილს თავიდან წერს, თუ ის ჩასაწერია.

თუ შენი პაკეტი nginx-ს იყენებს, .htaccess არ არსებობს და ფაილი უბრალოდ იგნორირდება. ლამაზი permalink-ები სერვერის კონფიგურაციაში try_files წესით მუშაობს და მისი არარსებობა მთავარი გვერდის გარდა ყველა URL-ზე 404-ს იძლევა და არა 500-ს. .htaccess-ის გადარქმევა იქ არაფერში გამოგადგება.

500, რომელიც მხოლოდ ერთ მოქმედებაზე ჩნდება, ნაკლებად აშკარა მიზეზებსაც შეიძლება ჰქონდეს:

• დროის ლიმიტები. გვერდი, რომელიც max_execution_time-ზე (ნაგულისხმევად 30 წამი) მეტხანს გრძელდება, PHP-ის ფატალური შეცდომით კვდება. reverse proxy-ზე უფრო ხანგრძლივი ლოდინი 502-ს ან 504-ს იძლევა. ამას import ამოცანები და backup plugin-ები აწყდებიან.
• წვდომის უფლებები. WordPress-ს ყველაფრის წაკითხვა და wp-content-ში ჩაწერა სჭირდება. container-ზე, სადაც ყველაფერი ერთი მომხმარებლის საკუთრებაა, ეს იშვიათად ხდება, მაგრამ სხვა მომხმარებლის მიერ SFTP-ით ატვირთული ფაილი შეიძლება ისეთი რეჟიმით მოვიდეს, რომელსაც PHP ვერ კითხულობს. SFTP cannot edit files: permission denied ამას ეტაპობრივად განმარტავს.
• PHP-ის ვერსია. PHP 7-ისთვის დაწერილი plugin 8.3-ზე ან უფრო ახალზე შეიძლება ფატალურად ჩავარდეს. თუ ლოგში ძველი რამისთვის "Unsupported operand types" ან "Call to undefined function" ჩანს, ყველაფერზე წინ plugin-ის მხარდაჭერილი ვერსიები შეამოწმე.

WordPress-ის ბირთვის ფაილები და critical error შეტყობინება#

"There has been a critical error on this website" არის WordPress, რომელიც ფატალურ შეცდომას იჭერს და თეთრ ეკრანს შეტყობინებით ცვლის. მთავარი ის არის, რომ ის წერილსაც აგზავნის.

Recovery mode

WordPress ადმინისტრატორს წერილს უგზავნის იმ მისამართზე, რომელიც Settings-ში, შემდეგ General-შია მითითებული, სათაურით დაახლოებით "Your Site is Experiencing a Technical Issue". მასში დასახელებულია გაუმართავი plugin ან თემა და სპეციალური შესვლის ბმული. ბმულზე გადასვლა დაფას recovery mode-ში ხსნის, სადაც გაფუჭებული plugin ან თემა მხოლოდ შენი სესიისთვის არის შეჩერებული. ამის შემდეგ მის გამორთვას Plugins გვერდიდან ნორმალურად შეძლებ და recovery mode-იდან გამოხვალ.

სამი პრაქტიკული შენიშვნა:

• ბმული შეზღუდული დროით მოქმედებს, ნაგულისხმევად ერთი დღით, და WordPress ამ პერიოდში შეცდომის ტიპზე მხოლოდ ერთ წერილს აგზავნის, ამიტომ მეორე გადატვირთვა მეორე წერილს არ გამოიწვევს.
• წერილი ადმინის მისამართზე მიდის. თუ ეს მისამართი ისეთი ფოსტაა, რომელსაც აღარ იყენებ, ან შენს საიტს წერილების გაგზავნა არ შეუძლია, მას ვერასოდეს ნახავ.
• საიტი, რომელსაც ფოსტის მიწოდება არ შეუძლია, ხშირი შემთხვევაა. თუ წერილი არ მოდის, ნუ დაელოდები. ზემოთ აღწერილი plugin-ებისა და თემის გადარქმევა იგივე საქმეს აკეთებს.

წერილის სხვაგან გასაგზავნად wp-config.php-ში განსაზღვრე RECOVERY_MODE_EMAIL:

define( 'RECOVERY_MODE_EMAIL', 'you@example.com' );

დაზიანებული ბირთვის ფაილები

თუ ლოგი ფაილს wp-includes-ში ან wp-admin-ში ასახელებს, ან აღნიშნავს კლასის არარსებობას, რომელიც ბირთვმა უნდა განსაზღვროს, შესაძლოა თვით WordPress-ის ფაილებია დაზიანებული - წარუმატებელი განახლების, შეწყვეტილი ატვირთვის ან მავნე კოდის გამო. გამოსავალი ბირთვის ფაილების ადგილზე დაბრუნებაა შენი კონტენტის შეხების გარეშე.

WP-CLI-ით:

$ wp core verify-checksums$ wp core download --force --skip-content

verify-checksums შენს ბირთვის ფაილებს ოფიციალურებს ადარებს. --force ბირთვს გადააწერს, --skip-content კი wp-content-ს ხელს არ ახლებს. WP-CLI-ის გარეშე ჩამოტვირთე იგივე ვერსია wordpress.org-დან, გახსენი და ატვირთე wp-admin და wp-includes არსებულებზე, ასევე root-ში მდებარე ცალკეული ფაილები, wp-config.php-ის გარდა. wp-content-ზე ატვირთვა არასოდეს გააკეთო და არასოდეს წაშალო; ეს საქაღალდე შენს ატვირთულ ფაილებს, თემებს და plugin-ებს ინახავს. საიტს, რომელიც checksum შემოწმებას ვერ გადის და ბირთვის საქაღალდეებში აუხსნელი ზედმეტი ფაილები აქვს, სხვა პრობლემა აქვს, და გასაგრძელებლად what to do when your server is hacked გამოგადგება. გამეორების თავიდან ასაცილებელი გამაგრება აღწერილია WordPress security hardening-ში.

Error establishing a database connection#

ეს შეცდომა WordPress-იდან მოდის და არა PHP-იდან, და ერთ რამეს ნიშნავს: MySQL-თან დასაკავშირებელი გამოძახება ჩავარდა. მიზეზი ოთხია, და შემოწმების თანმიმდევრობა სწრაფიდან ნელისკენაა:

1. არასწორი მონაცემები `wp-config.php`-ში. ყველაზე ხშირია მიგრაციის, პაროლის შეცვლის ან აღდგენის შემდეგ.
2. ბაზის სერვერი გამორთულია ან მიუწვდომელია.
3. ბაზას კავშირები ან რესურსები ამოეწურა.
4. დაზიანებული ცხრილები.

დაიწყე ფაილით. კავშირს ოთხი კონსტანტა განსაზღვრავს:

define( 'DB_NAME', 'wp_site' );define( 'DB_USER', 'wp_user' );define( 'DB_PASSWORD', 'the-generated-password' );define( 'DB_HOST', 'localhost' );

თითოეული ნამდვილ მნიშვნელობას შეადარე. RE:NODE-ის web პაკეტზე ბაზის სლოტი პანელში იქმნება დაგენერირებული host-ით, მომხმარებლით, ბაზის სახელით და პაროლით, ხოლო WordPress-ის ხაზი wp-config.php-ს საკუთარი MySQL ბაზისთვის წერს, ამიტომ ფაილი უკვე უნდა ემთხვეოდეს. თუ არ ემთხვევა, პანელის ბაზის განყოფილება ჭეშმარიტების წყაროა - აქედან ააკოპირე და არა მეხსიერებიდან. ბოლოში დარჩენილი ჰარი ან ჩასმისას დაკარგული ბრჭყალი საკმარისია, რომ ჩავარდეს. DB_HOST ყოველთვის localhost არ არის: სხვა ჰოსტზე არსებულ ბაზას იმ ჰოსტის სახელი სჭირდება, ხოლო არანაგულისხმევი პორტი host:3307 სახით იწერება.

პანელის ღილაკი "Open in phpMyAdmin" ბაზა ცოცხალია თუ არა, ამის შესამოწმებლად ყველაზე სწრაფი გზაა. ის შენ ერთჯერადი ტოკენით შეგიყვანს, რომელიც 60 წამში იწურება. თუ phpMyAdmin იხსნება და შენს ცხრილებს აჩვენებს, სერვერი მუშაობს და პრობლემა wp-config.php-ში მონაცემებია ან host-ის მნიშვნელობა. თუ არ იხსნება, პრობლემა ბაზის სლოტშია და შემდეგი ნაბიჯი პანელიდან support ticket-ია.

shell-იდან MySQL კლიენტით იგივე მონაცემები პირდაპირ შეგიძლია შეამოწმო:

$ mysql -h HOST -u USER -p DATABASE -e "SELECT 1;"

თუ ეს მუშაობს და WordPress მაინც ვერ უკავშირდება, PHP-ის დონეზე რაღაც განსხვავდება, მაგალითად mysqli გაფართოება არ არის, რასაც php -m აჩვენებს. mysqli vs PDO განმარტავს, როგორ ესაუბრება PHP MySQL-ს და რომელი დრაივერებია მნიშვნელოვანი. თუ შეცდომა წყვეტილია, ანუ საიტი მუშაობს და შემდეგ დატვირთვისას ვარდება, ბაზას კავშირები ამოეწურა, და ამ შემთხვევას MySQL connection limits and pooling განიხილავს.

ერთი ვარიანტი ცალკე აღსანიშნავია. თუ საიტის საჯარო ნაწილი ბაზის შეცდომას აჩვენებს, მაგრამ /wp-admin აჩვენებს "One or more database tables are unavailable. The database may need to be repaired", მონაცემები სწორია და ცხრილებია დაზიანებული.

ბაზის შეკეთება#

WordPress-ს ჩაშენებული შესაკეთებელი ხელსაწყო აქვს, რომელიც ნაგულისხმევად გამორთულია, რადგან შესვლას არ ითხოვს. ჩასართავად wp-config.php-ში ერთი ხაზი დაამატე:

define( 'WP_ALLOW_REPAIR', true );

შემდეგ შენს საიტზე გახსენი /wp-admin/maint/repair.php. ის ორ ღილაკს გთავაზობს: Repair Database და Repair and Optimise Database. გაუშვი პირველი. დასრულებისას ხაზი დაუყოვნებლივ წაშალე.

ალტერნატივები:

$ wp db check$ wp db repair

ან phpMyAdmin-ში მონიშნე დაზიანებული ცხრილები და სიის ქვემოთ ჩამოსაშლელი მენიუდან აირჩიე Repair table. გაითვალისწინე, რომ REPAIR TABLE MyISAM ცხრილებზე მუშაობს; InnoDB-ზე, რომელიც WordPress-ის ახლანდელი ნაგულისხმევია, შეკეთება თითქმის არაფერს აკეთებს და ნამდვილი გამოსავალი backup-იდან აღდგენაა. mysqldump backup and restore გვიჩვენებს, როგორ გააკეთო ექსპორტი რამის შეხებამდე, ხოლო database backups and restores უფრო ფართო რუტინაა.

შეკეთებამდე პანელის backup-ები შენი დამცავი ბადეა. RE:NODE-ზე backup-ები მოთხოვნისამებრ შეიძლება გაკეთდეს, ინახება იმ მანქანისგან განცალკევებით, რომელსაც იცავს, და აღდგება ღილაკით. აიღე ერთი საქაღალდეების გადარქმევამდე, wp-config.php-ის რედაქტირებამდე ან შეკეთების გაშვებამდე და ყოველთვის შეგეძლება საწყის წერტილში დაბრუნება. Backup, რომელიც არავის აღუდგენია, ჰიპოთეზაა, ამიტომ იხილე testing a restore before you need it.

ოპერაციების უსაფრთხო თანმიმდევრობა#

როცა საიტი გათიშულია და ხუთი რამის ერთდროულად შეცვლა გინდება, ერთ-ერთი შეცვალე და თითოეულს შორის შეამოწმე. ეს არის თანმიმდევრობა, რომელიც ყველაზე ნაკლებ დროს და რისკს ითხოვს:

1. გახსენი /readme.html და ნახე, პასუხობს თუ არა სერვერი საერთოდ.
2. ჩართე WP_DEBUG_LOG გამორთული WP_DEBUG_DISPLAY-ით, გადატვირთე და წაიკითხე debug.log და PHP error log.
3. აიღე backup, თუ ფაილების ან ბაზის შეცვლას აპირებ.
4. გადაარქვი სახელი wp-content/plugins-ს (და საჭიროებისას mu-plugins-ს).
5. გადაარქვი სახელი აქტიური თემის საქაღალდეს.
6. გაზარდე WP_MEMORY_LIMIT, შემდეგ memory_limit.
7. გადაარქვი სახელი .htaccess-ს და ხელახლა შეინახე permalink-ები, თუ შენი პაკეტი Apache-ს იყენებს.
8. შეადარე DB_NAME, DB_USER, DB_PASSWORD და DB_HOST პანელს.
9. შეამოწმე ან ჩაანაცვლე ბირთვის ფაილები.
10. ბაზა შეაკეთე, როგორც უკანასკნელი ნაბიჯი.

როცა რამე იმუშავებს, ყველაფერი ერთ-ერთად დააბრუნე. აღადგინე plugin-ების საქაღალდე, შემდეგ plugin-ები ნახევრებად ჩართე. მაცდური ისაა, რომ საიტი სტანდარტულ თემაზე და plugin-ების გარეშე დატოვო, და სწორედ ასე კარგავენ საიტები ფუნქციებს თვეობით შეუმჩნევლად. ბოლოს გამართვა გამორთე და debug.log წაშალე.

პროფილაქტიკა იაფია. განახლებები ჯერ staging ასლზე გააკეთე (running a test server beside production ამ ჩვევას აღწერს), ყოველი plugin-ის განახლებამდე ახალი backup გქონდეს და თემის ფაილები დაფის რედაქტორში არ შეცვალო. რედაქტორს ძველ კონფიგურაციებში undo არ აქვს და სინტაქსს არ ამოწმებს, ხოლო ერთი გამოტოვებული წერტილმძიმე თეთრი ეკრანია.

FAQ#

რატომ აჩვენებს ჩემი საიტი თეთრ ეკრანს შეცდომის გარეშე?

იმიტომ, რომ შეცდომების ჩვენება გამორთულია, რაც მოქმედ საიტზე სწორია. შეცდომა არსებობს, მაგრამ ლოგშია. დააყენე WP_DEBUG და WP_DEBUG_LOG true-ზე და WP_DEBUG_DISPLAY false-ზე, გადატვირთე ერთხელ და წაიკითხე wp-content/debug.log. თუ ლოგი ცარიელი რჩება, შეამოწმე PHP error log, რადგან ჩავარდნა შეიძლება WordPress-ის გაშვებამდე მოხდა.

500 შეცდომა ჩემი ჰოსტის ბრალია?

ზოგჯერ, მაგრამ იშვიათად. WordPress-ზე 500-ების უმეტესობა plugin-ია, თემა, ცუდი .htaccess წესი ან მეხსიერების ლიმიტი. ჯერ plugin-ების გადარქმევა და ლოგი სცადე. თუ PHP ლოგი ცარიელია, /readme.html-ც ვარდება და შენი არცერთი ცვლილება არ ემთხვევა, ჰოსტთან ticket გონივრულია. RE:NODE-ის ticket-ები პანელიდან მთელ პერსონალს ეგზავნება.

რამდენით გავზარდო მეხსიერების ლიმიტი?

ჯერ 256M-მდე. თუ შეცდომა 256M-ზეც რჩება, ლიმიტის ახალი ზრდის ნაცვლად გაარკვიე, რა ხარჯავს მეხსიერებას. მეხსიერების ამოწურვა ყოველ ლიმიტზე, რომელსაც სცდი, ციკლს ან გადაჭარბებულად დიდ მოთხოვნას ნიშნავს და არა პატარა ლიმიტს. პაკეტის RAM-ზე მაღალი ლიმიტი მხოლოდ ჩავარდნას გადაიტანს PHP-ის მოწესრიგებული შეტყობინებიდან პროცესის მოკვლაზე.

Recovery mode-ის წერილი არ მივიღე. ახლა რა ვქნა?

შეამოწმე ადმინისტრატორის მისამართი Settings-ში, შემდეგ General-ში, და ნახე spam. საიტი, რომელიც წერილებს ვერ აგზავნის, ამასაც ვერ გამოგიგზავნის. ამის ნაცვლად plugins საქაღალდეს გადაარქვი სახელი; იგივე საქმეს აკეთებს. დააყენე RECOVERY_MODE_EMAIL wp-config.php-ში, რომ შემდეგი იქ მოვიდეს, სადაც კითხულობ.

plugins საქაღალდის გადარქმევა ჩემს პარამეტრებს წაშლის?

არა. plugin-ების პარამეტრები ბაზაში ინახება და გადარქმევა მხოლოდ WordPress-ს აჩერებს კოდის ჩატვირთვაში. როცა საქაღალდეს სახელს დაუბრუნებ, plugin-ები გამორთულად გამოჩნდება და თავიდან ჩართავ. რამდენიმე plugin გამორთვისას ოფციას ანულებს, ამიტომ ტესტამდე backup აიღე.

მჭირდება WP-CLI ამ ყველაფრის გასასწორებლად?

არა. ყოველ ნაბიჯს აქვს გზა ფაილ მენეჯერით ან SFTP-ით, ბაზას კი პანელის phpMyAdmin ღილაკი ფარავს. WP-CLI უფრო სწრაფია, როცა shell-ში დაყენებული გაქვს, და --skip-plugins მას მაშინაც აძლევს მუშაობის საშუალებას, როცა plugin WordPress-ს ჩატვირთვისას არღვევს.