WordPress-ის ხელით დაყენება: ბაზა, wp-config და პირველი შესვლა

WordPress-ის ხელით დაყენება ოთხი რამეა: ფაილები ვებ root-ში, ბაზა მომხმარებლით, რომელსაც მასში ჩაწერა შეუძლია, wp-config.php, რომელიც ამ მონაცემებსა და რვა შემთხვევით salt-ს შეიცავს, და ერთი ვიზიტი /wp-admin/install.php-ზე. ჩვეულებრივ კავშირზე მთელი საქმე დაახლოებით ათ წუთს იღებს, საიდანაც ცხრა ატვირთვის ლოდინია.

შემდეგ ყველაფერი, რაც არასწორად მიდის, თითქმის ყოველთვის ოთხი შეცდომიდან ერთ-ერთია: ბაზის host localhost არ არის, ფაილები არასწორ მომხმარებელს ეკუთვნის, ბაზაში ჩაწერილი საიტის მისამართი ადამიანების აკრეფილს არ ემთხვევა, ან PHP თემისთვის ძალიან ძველია. ეს გზამკვლევი ინსტალაციას აკეთებს და შემდეგ თითოეულს სათანადოდ გადის, რადგან ინსტალაცია თავად მარტივი ნახევარია.

რა გჭირდება დაწყებამდე#

WordPress განზრახ მოუთხოვნელია. თავად პროექტის რეკომენდაციაა PHP 7.4 ან უფრო ახალი და MySQL 8.0 ან MariaDB 10.5 კლასის ბაზა, HTTPS-ის არსებობით. რეალური მინიმუმი უფრო დაბალია, მაგრამ წელს დაწერილი plugin PHP 8-ს ივარაუდებს, ამიტომ 8.1 მიიღე ქვედა ზღვრად, 8.2 ან 8.3 კი გონივრულ არჩევანად. ნუ აირჩევ PHP ვერსიას, რომელიც უფრო ახალია, ვიდრე შენი თემა და გადახდის plugin-ები გამოცდილია - ეს ერთადერთი განახლებაა, რომელიც მაღაზიას სანდოდ ტეხავს.

რამე რომ აკრიფო, ჰოსტინგზე ორი რამ უნდა იცოდე: რომელ მომხმარებლად მუშაობს PHP და გაქვს თუ არა shell წვდომა. პირველი წყვეტს ფაილების უფლებებს. მეორე წყვეტს, შეგიძლია თუ არა WP-CLI-ის გამოყენება, ან მთელი საქმე file manager-ითა და phpMyAdmin-ით უნდა გააკეთო. პანელზე დაფუძნებული ჰოსტინგი ჩვეულებრივ მხოლოდ მეორე გზას გაძლევს - იქ კონსოლი ვებ სერვერის საკუთარი გამოტანაა და არა login shell - და ეს სავსებით საკმარისია.

ფაილები სერვერზე ატვირთე#

კანონიკური ჩამოტვირთვაა https://wordpress.org/latest.zip (ან latest.tar.gz). არასოდეს დააყენო ვინმეს გამოგზავნილი ასლიდან, "nulled" ბანდლიდან ან ძიების შედეგში ნაპოვნი zip-იდან: თემების დირექტორიაში შეყვანილი კოდი ყველაზე გავრცელებული გზაა, რომლითაც საიტი უკვე დაზიანებული იწყებს არსებობას.

shell წვდომით:

$ cd /var/www/example.com$ wget https://wordpress.org/latest.tar.gz$ tar -xzf latest.tar.gz --strip-components=1$ rm latest.tar.gz

--strip-components=1 ის ნაწილია, რომელსაც ხალხი ამოაგდებს. არქივი შეიცავს ზედა დონის wordpress/ საქაღალდეს, ამიტომ მის გარეშე იღებ /var/www/example.com/wordpress/index.php-ს და საიტს, რომელიც მხოლოდ example.com/wordpress-ზე პასუხობს. ეს კანონიერი განლაგებაა, თუ გინდა, მაგრამ აირჩიე განზრახ.

shell წვდომის გარეშე ატვირთე latest.zip file manager-ით და იქვე გახსენი - file manager, რომელიც არქივებს სერვერზე ხსნის, 60 MB-იან, 2000 პატარა ფაილიან ატვირთვას ერთი ფაილის ერთ ატვირთვად აქცევს, რაც SFTP-ით დაახლოებით ოცჯერ უფრო სწრაფია. შემდეგ wordpress/-ის შიგთავსი ერთი დონით ზემოთ გადაიტანე და ცარიელი საქაღალდე წაშალე.

ფაილები უნდა მოხვდეს იმ დირექტორიაში, რომელსაც ვებ სერვერი ემსახურება. გავრცელებული სახელებია public_html, www, htdocs ან public. თუ არასწორში ატვირთე, მიიღებ დირექტორიის სიას ან ნაგულისხმევ გვერდს, და wp-config.php-ში ვერაფერი შეცვლის ამას. SFTP და file manager გვიჩვენებს, როგორ აიღო მონაცემები და იპოვო root.

შექმენი ბაზა და მისი მომხმარებელი#

WordPress საკუთარ თავს ბაზას არ შექმნის. მას სჭირდება უკვე არსებული ბაზა და მომხმარებელი მასზე სრული უფლებებით - და მხოლოდ მასზე. თუ კონტროლ პანელს ბაზების განყოფილება აქვს, გამოიყენე ის; მის მიერ გენერირებული მონაცემები უკეთესია, ვიდრე შენი არჩეულები. თუ SQL წვდომა გაქვს:

CREATE DATABASE wordpress CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;CREATE USER 'wp_site'@'%' IDENTIFIED BY 'a-long-random-password';GRANT ALL PRIVILEGES ON wordpress.* TO 'wp_site'@'%';FLUSH PRIVILEGES;

სამი დეტალი, რომელიც დამატებით წამებს ღირს:

• `utf8mb4` და არა `utf8`. ამ ოჯახში ძველი utf8 სიმბოლოზე სამ ბაიტს ინახავს და emoji-ს ან რამდენიმე დამწერლობას ვერ იტევს. პოსტი, რომელიც ბოლოვდება წინადადების შუაში იქ, სადაც emoji იყო, სწორედ ეს არის, და მისი შემდეგ გასწორება ყველა ცხრილზე collation-ის კონვერტაციას ნიშნავს.
• ერთი მომხმარებელი თითო საიტზე. GRANT ALL ON wordpress.* ამ მომხმარებელს საკუთარი ბაზის გარეთ არაფერს აძლევს. სამ საიტზე საერთო მომხმარებელი ნიშნავს, რომ ერთი გატეხილი plugin სამივეს აღწევს.
• `ALL PRIVILEGES` არჩევითი არ არის. WordPress-ს ინსტალაციისას და ყოველ განახლებაზე, რომელიც ცხრილს ამატებს, სჭირდება ALTER და CREATE. მხოლოდ წაკითხვა-ჩაწერის უფლება ინსტალაციას წარმატებით გაივლის და პირველივე plugin-ზე ჩავარდება, რომელიც სქემას მოაქვს.

სანამ წინ წახვალ, ჩაიწერე ოთხი მნიშვნელობა: ბაზის სახელი, მომხმარებელი, პაროლი და host. host-ს ხალხი ყველაზე ხშირად ცდება. ის localhost მხოლოდ მაშინაა, როცა ბაზა PHP-ის მანქანაზე მუშაობს. სხვა შემთხვევაში ეს hostname-ია, და თუ პორტი ნაგულისხმევი არ არის, ბოლოში ემატება: DB_HOST იღებს db.internal.example:3307-ს.

RE:NODE-ზე ვებ გეგმებს ორი ბაზის სლოტი აქვს, რომლებიც პანელიდან იქმნება. ის თვითონ აგენერირებს host-ს, მომხმარებელს, ბაზის სახელსა და პაროლს, ხოლო Open in phpMyAdmin ღილაკი შეგიყვანს ერთჯერადი token-ით, რომელიც სამოცი წამის შემდეგ იწურება, ამიტომ პაროლი ბრაუზერის ფორმაში არასოდეს იკრიფება. ეს ოთხი მნიშვნელობა პირდაპირ wp-config.php-ში გადაიტანე. phpMyAdmin-ის import და export გზამკვლევი იმავე პანელს საპირისპირო მხრიდან განიხილავს, როცა არსებულ საიტს გადმოიტან.

wp-config.php, ხაზ-ხაზ#

wp-config-sample.php გადაარქვი wp-config.php-ად და შეასწორე. ფაილი დატოვე საიტის root-ში, თუ არ იცი, რატომ გადააქვს, და არასოდეს დატოვო მის გვერდით wp-config.php.bak ან wp-config.old სახელის ასლი - ისინი უბრალო ტექსტად გაიცემა და ბაზის პაროლს გადასცემს.

define( 'DB_NAME',     'wordpress' );define( 'DB_USER',     'wp_site' );define( 'DB_PASSWORD', 'a-long-random-password' );define( 'DB_HOST',     'localhost' );define( 'DB_CHARSET',  'utf8mb4' );define( 'DB_COLLATE',  '' );$table_prefix = 'wp_';define( 'WP_DEBUG',         false );define( 'WP_DEBUG_LOG',     false );define( 'WP_DEBUG_DISPLAY', false );define( 'FS_METHOD',          'direct' );define( 'DISALLOW_FILE_EDIT', true );define( 'WP_MEMORY_LIMIT',    '256M' );define( 'WP_ENVIRONMENT_TYPE', 'production' );

რას აკეთებს რეალურად თითოეული მათგანი:

• `DB_COLLATE` ცარიელი უნდა დარჩეს. WordPress charset-ისთვის სწორ collation-ს თვითონ ირჩევს; ხელით დაყენება ის გზაა, რომლითაც საიტებს მიგრაციის შემდეგ შერეული collation-ები უჩნდება და join-ებს არღვევს.
• `$table_prefix` ნაგულისხმევად wp_-ია. მის შეცვლას ხშირად უსაფრთხოებად ყიდიან; ეს ასე არ არის, რადგან ყველაფერს, რასაც შენი ცხრილების წაკითხვა შეუძლია, პრეფიქსის ამოკითხვაც წამებში შეუძლია. ის მართლა სასარგებლოა ორი საიტის ერთ ბაზაში ჩასადებად, და მისი შეცვლის ერთადერთი მიზეზი ესაა.
• `WP_DEBUG` production-ში ყოველთვის გამორთული. როცა გჭირდება, WP_DEBUG და WP_DEBUG_LOG დააყენე true-ზე და WP_DEBUG_DISPLAY false-ზე: შეცდომები მაშინ wp-content/debug.log-ში მოხვდება და არა ვიზიტორებთან, რომლებსაც შენი ფაილების გზები არ სჭირდებათ.
• `FS_METHOD` `direct`-ზე აჩერებს იმას, რომ WordPress plugin-ის ყოველ დაყენებაზე FTP მონაცემებს გთხოვდეს. ის მხოლოდ მაშინ მუშაობს, როცა PHP-ის მომხმარებელს wp-content-ში ჩაწერა შეუძლია, რაც ქვემოთ უფლებების თავია.
• `WP_MEMORY_LIMIT` ნაგულისხმევად 40M-ია წინა ნაწილისთვის, WP_MAX_MEMORY_LIMIT კი 256M ადმინისტრაციული გვერდებისთვის. 40M თანამედროვე თემისთვის არ კმარა. ეს მუდმივა მხოლოდ იმ ფარგლებში ამცირებს ან ზრდის, რასაც თვით PHP იძლევა, ამიტომ ეს ამბის ნახევარია - php.ini პარამეტრები, რომლებსაც მნიშვნელობა აქვს მეორე ნახევარია.
• `WP_ENVIRONMENT_TYPE` plugin-ებს ეუბნება, production-ზე არიან, staging-ზე, development-ზე თუ local-ზე. სწორად დააყენე საიტის ყველა ასლზე, და backup და გადახდის plugin-ები, რომლებიც ამას პატივს სცემენ, შენი staging კლონიდან მომხმარებლებს წერილებს აღარ გაუგზავნიან.

კიდევ ორი, რომელიც საბოლოოდ გინდა, მაგრამ არა ინსტალაციისას:

define( 'WP_HOME',    'https://example.com' );define( 'WP_SITEURL', 'https://example.com' );

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

Salt-ები და რას იცავს ისინი სინამდვილეში#

ნიმუშ ფაილში რვა ადგილმჭერი მუდმივაა: AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY და შესაბამისი AUTH_SALT, SECURE_AUTH_SALT, LOGGED_IN_SALT და NONCE_SALT. ისინი პაროლები არ არის და არსად აკრიფებ. WordPress მათ იყენებს login cookie-ებისა და ადმინისტრაციული ფორმების nonce-ების ხელმოსაწერად.

თუ დატოვებ როგორც put your unique phrase here, საიტის მიერ გაცემული ყოველი სესიის cookie-ის გაყალბება შეუძლია ყველას, ვინც ნიმუშ ფაილს კითხულობდა - ანუ ყველას. დააგენერირე ნამდვილები:

$ curl https://api.wordpress.org/secret-key/1.1/salt/

ეს endpoint რვა მზა define() ხაზს აბრუნებს. ჩასვი ისინი ადგილმჭერების ადგილას. თუ მანქანას გარე წვდომა არ აქვს, ნებისმიერი რვა სტრიქონი 64 შემთხვევითი სიმბოლოსგან ისევე კარგად მუშაობს; მათ უბრალოდ გრძელი, შემთხვევითი და საიდუმლო უნდა იყოს.

ფაილების მფლობელი და უფლებები#

აქ ჩერდება ხელით ინსტალაციები, და სწორი პასუხი ერთ რამეზეა დამოკიდებული: რომელ მომხმარებლად მუშაობს PHP. აქ მას www-data დავარქვათ; შენს ჰოსტზე ის შეიძლება იყოს nginx, apache ან თითო საიტზე ცალკე მომხმარებელი.

$ cd /var/www/example.com$ chown -R www-data:www-data .$ find . -type d -exec chmod 755 {} \;$ find . -type f -exec chmod 644 {} \;$ chmod 640 wp-config.php

არასოდეს გამოიყენო 777. ის ასობით ფორუმის თემის პასუხია და ნიშნავს "ამ მანქანაზე ნებისმიერს შეუძლია ამ ფაილის გადაწერა", რაც გაზიარებულ აპარატურაზე მეზობელ საიტსაც მოიცავს. თუ ატვირთვა 755-ზე ვერ ხერხდება, პრობლემა მფლობელია და არა რეჟიმი - დირექტორია არასწორ მომხმარებელს ეკუთვნის, ჩვეულებრივ იმიტომ, რომ ფაილები SFTP-ით შენი პირადი ანგარიშით აიტვირთა და არა PHP-ის მომხმარებლით.

container-ზე დაფუძნებულ პანელზე container-ის შიგნით მხოლოდ ერთი მომხმარებელია, ამიტომ მფლობელობა კითხვა არ არის, რომელსაც პასუხი უნდა გასცე: რასაც file manager ჩაწერს, PHP-ს შეუძლია წაიკითხოს და განაახლოს. ეს პანელის ერთ-ერთი იმ იშვიათი ნამდვილი გამარტივებაა ჩვეულებრივ ვირტუალურ სერვერთან შედარებით, და ამიტომ მუშაობს FS_METHOD direct-ზე იქ დამატებითი ფიქრის გარეშე.

გაუშვი ინსტალერი#

გახსენი https://example.com/wp-admin/install.php. თუ WordPress ბაზას აღწევს, ოთხ რამეს გკითხავს.

1. საიტის სათაური. მოგვიანებით იცვლება, შედეგების გარეშე.
2. მომხმარებლის სახელი. არა admin, არა საიტის სახელი, არა შენი სახელი, თუ ის ავტორის სახელიც არის. ავტომატური შესვლის მცდელობები სწორედ ამ სამს ცდის.
3. პაროლი. გამოიყენე გენერირებული და ჩასვი password manager-ში.
4. ელფოსტა. ნამდვილი, კონტროლირებადი ყუთი. პაროლის აღდგენა და კრიტიკული შეცდომების შეტყობინებები იქ მიდის, და საიტს, რომლის ადმინისტრატორის ელფოსტა უკან ბრუნდება, აღდგენის გზა არ აქვს.

არის ასევე Discourage search engines ჩეკბოქსი. ის ერთ პარამეტრს სვამს და noindex header-ს წერს; ის სწორია საიტისთვის, რომელსაც აშენებ, და კატასტროფულია, თუ გაშვების შემდეგ მონიშნული დარჩება. შეამოწმე Settings, შემდეგ Reading, გაშვების დღეს. საიტი, რომელიც გაშვებიდან თვის შემდეგ "არ რანჟირდება", დაახლოებით მესამედ ამ ჩეკბოქსით არის მონიშნული.

ინსტალერი ცხრილებს ქმნის, პირველ მომხმარებელს წერს და /wp-admin-ზე გიშვებს. მერე გასასუფთავებელი არაფერია - install.php რჩება, და დაყენებულ საიტზე მისი ხელახლა გაშვება მხოლოდ შეტყობინებას აჩვენებს.

თუ shell წვდომა გაქვს, WP-CLI იმავე სამუშაოს ორი ბრძანებით აკეთებს და ბევრად უფრო ადვილი სკრიპტავია:

$ wp core config --dbname=wordpress --dbuser=wp_site --dbpass='...' --dbhost=localhost$ wp core install --url=https://example.com --title="Example" \    --admin_user=owner --admin_email=you@example.com --prompt=admin_password

Permalink-ები, HTTPS და საიტის მისამართი#

სამი პარამეტრი წყვეტს, ისე იქცევა თუ არა საიტი. გააკეთე ისინი ამ თანმიმდევრობით.

Permalink-ები. Settings, შემდეგ Permalinks, შემდეგ Post name, შემდეგ Save - შენახვა აახლებს წესებს. Apache-ზე ეს .htaccess-ში ბლოკს წერს, და თუ ფაილი ჩასაწერი არ არის, WordPress წესებს გაჩვენებს ჩასასმელად. nginx-ზე .htaccess არ არსებობს; rewrite სერვერის კონფიგურაციაშია და ასე გამოიყურება:

location / {    try_files $uri $uri/ /index.php?$args;}

თუ მთავარი გვერდის გარდა ყველა URL 404-ს აბრუნებს, ეს არის მიზეზი - წესი აკლია, ან nginx-ზე ხარ და .htaccess-ისგან რაღაცას ელი. მართულ ჰოსტინგზე წესი ჩვეულებრივ უკვე დგას და მას არასოდეს ხედავ.

HTTPS. სერტიფიკატი ინსტალაციამდე ამუშავე, რომ საიტის მისამართი ბაზაში ჩაწერილი პირველი სტრიქონიდანვე https:// იყოს. მოგვიანებით შეცვლა მთელ ბაზაში ძიება-ჩანაცვლებას ნიშნავს, რაც WordPress-ის ახალ ჰოსტზე გადატანის თავია და არა პარამეტრი.

Proxy header. როცა TLS PHP-ის წინ სრულდება - ნებისმიერი reverse proxy, ნებისმიერი CDN - PHP დაშიფრულ მოთხოვნას ვერ ხედავს, ამიტომ WordPress აგებს http:// URL-ებს, გადამისამართებს მათზე, ბრუნდება უკან და ბრაუზერი redirect loop-ს აცხადებს. გამოსწორება wp-config.php-შია, ბოლოში მდგარი require_once ABSPATH . 'wp-settings.php'; ხაზის ზემოთ:

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] )    && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' ) {    $_SERVER['HTTPS'] = 'on';}

დაამატე მხოლოდ მაშინ, თუ შენს კონტროლქვეშ მყოფი proxy მართლა სვამს ამ header-ს, თორემ HTTPS-ის გაყალბებას ტრივიალურს გახდი. RE:NODE-ის ვებ გეგმებს proxy სლოტი აქვს: A ჩანაწერი მიუთითე იმ ჩანართზე ნაჩვენებ მისამართზე და სერტიფიკატი ავტომატურად გაიცემა და განახლდება, ვიზიტორის რეალური მისამართი კი X-Forwarded-For-ში მოვა. რას აკეთებს reverse proxy დანარჩენ header-ებს განმარტავს, ხოლო შენი დომენი და მისი სერტიფიკატი DNS-ის ნახევარს ფარავს.

როცა არ მუშაობს#

Error establishing a database connection. ოთხი მონაცემიდან ერთი არასწორია, ან ბაზის სერვერი PHP-დან მიუწვდომელია. ჯერ phpMyAdmin-ში შეამოწმე მონაცემები - თუ იქ მუშაობს და WordPress-ში არა, განსხვავება თითქმის ყოველთვის DB_HOST-ია, და თითქმის ყოველთვის localhost იქ, სადაც ნამდვილი hostname სჭირდება.

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

Allowed memory size exhausted. PHP-მ memory_limit-ს მიაღწია. გაზარდე WP_MEMORY_LIMIT, და თუ ეს არაფერს ცვლის, PHP-ის საკუთარი ლიმიტი უფრო დაბალია და ჯერ ის უნდა გაზარდო.

The upload failed to write to disk, ან uploads საქაღალდე ჩასაწერი არ არის. wp-content/uploads-ის მფლობელი, ან სავსე დისკი. უფლებების შეცვლამდე შეამოწმე თავისუფალი ადგილი.

A file exceeds the upload_max_filesize directive. ეს PHP-ის ლიმიტია და არა WordPress-ის. საჭიროა upload_max_filesize და post_max_size ერთად გაიზარდოს, და შესაძლოა წინ მდგარ proxy-ზეც body-ის ზომის ლიმიტი.

Mixed content გაფრთხილებები. გვერდი HTTPS-ით მოვიდა და სურათი HTTP-ით მოითხოვა. URL-ები ბაზაში ძველი სქემით ინახება; გაასწორე ძიება-ჩანაცვლების ხელსაწყოთი, რომელიც serialised მონაცემებს ესმის, არასოდეს უბრალო SQL REPLACE-ით.

Redirect loop ინსტალაციისთანავე. ზემოთ აღწერილი proxy header-ის შემთხვევა, ან WP_HOME და WP_SITEURL არ ემთხვევა მისამართის ზოლში არსებულ hostname-ს - იმის ჩათვლით, როცა www და არა-www ვერსიები სხვადასხვა საიტად ითვლება.

FAQ#

მჭირდება one-click ინსტალერი?

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

შეიძლება WordPress-ის ქვედირექტორიაში დაყენება და root-იდან მომსახურება?

დიახ. ფაილები ჩადე /wordpress-ში, WP_SITEURL დააყენე https://example.com/wordpress-ზე და WP_HOME https://example.com-ზე, შემდეგ index.php და .htaccess root-ში დააკოპირე და index.php-ში ის ერთი ხაზი შეასწორე, რომელიც wp-blog-header.php-ს მოითხოვს, რომ ქვედირექტორიაზე მიუთითებდეს. ეს ვებ root-ს მოწესრიგებულს ინახავს; უსაფრთხოების ზომა არ არის.

როგორ გავაგზავნინო WordPress-ით ელფოსტა?

პრაქტიკაში არა ვებ სერვერიდან. ჰოსტინგის IP-დან გაგზავნილი წერილი SPF, DKIM და DMARC შესაბამისობის გარეშე spam-ში ხვდება ან პირდაპირ უარყოფილია, და ბევრი ჰოსტი - RE:NODE-ის ჩათვლით - ფოსტას საერთოდ არ უშვებს. დააყენე SMTP plugin და მიუთითე ტრანზაქციული ფოსტის პროვაიდერზე ან შენს საკუთარ ყუთზე. SPF, DKIM და DMARC ახსნილი გვიჩვენებს, რატომ აქვს ჩანაწერებს მაინც მნიშვნელობა.

უნდა შევცვალო wp_ ცხრილის პრეფიქსი?

მხოლოდ რამდენიმე საიტის ერთ ბაზაში ჩასადებად. უსაფრთხოების ზომად ის არაფერს გაძლევს: ნებისმიერ კოდს, რომელსაც შენი ცხრილების მოთხოვნა შეუძლია, მათი ჩამოთვლაც შეუძლია. მისი შეცვლა მოქმედ საიტზე ნიშნავს ყველა ცხრილის გადარქმევას და ორი სტრიქონის შესწორებას options და user-meta ცხრილებში, და ნახევრად სწორად გაკეთება ადმინისტრაციულ პანელს ტეხავს.

რა უნდა გავაკეთო პირველი შესვლისთანავე?

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

რა რესურსი სჭირდება ახალ WordPress საიტს?

1 GB, 0.5 vCPU გეგმა პატარა ვიზიტკა საიტს კომფორტულად ამუშავებს. მეხსიერება ლიმიტი ხდება მაშინ, როცა plugin-ების რაოდენობა და PHP worker-ების რაოდენობა ერთად იზრდება და არა ტრაფიკის ზრდისას - ამიტომ plugin-ებით სავსე საიტს დღეში ორმოცდაათი ვიზიტორით შეიძლება მეტი მეხსიერება სჭირდებოდეს, ვიდრე მსუბუქს ხუთი ათასით.