Drupal-ის ჰოსტინგი: მოთხოვნები, Composer და settings.php

Drupal 11-ს სჭირდება PHP 8.3 ან უფრო ახალი, MySQL 8.0-ის, MariaDB 10.6-ის ან PostgreSQL 16-ის კლასის ბაზა, პრაქტიკაში მინიმუმ 128 MB PHP მეხსიერება და ვებ სერვერი, რომელიც ყოველ მოთხოვნას, რომელსაც ფაილად ვერ პოულობს, index.php-ს უგზავნის. ის Composer-ით ყენდება და არა არქივის გახსნით, და ეს ერთი ფაქტი მისი ჰოსტინგის ყველა ასპექტს განსაზღვრავს: build ხდება იქ, სადაც Composer მუშაობს, ხოლო შედეგი - რამდენიმე ათასი ფაილისგან შემდგარი vendor დირექტორიის ჩათვლით - სერვერზე მიდის.

ჰოსტინგზე shell-ით ეს ორი ბრძანებაა. პანელზე დაფუძნებულ ჰოსტინგზე shell-ის გარეშე საიტს საკუთარ მანქანაზე აწყობ და ატვირთავ, რაც შესანიშნავად მუშაობს, როცა იცი, სად მიდის ვებ root. ეს გზამკვლევი ორივეს ფარავს, შემდეგ settings.php-ს ხაზ-ხაზ, nginx-ის წესებს, cron-ს, cache-ს (Valkey-ის ჩათვლით), განახლებებს და შეცდომებს, რომლებსაც ხალხი რეალურად აწყდება.

რომელი Drupal და რას მოითხოვს#

2026 წლის ბოლოს თამაშში სამი ძირითადი ვერსიაა, და ახალი საიტისთვის მხოლოდ ერთია სწორი არჩევანი.

ახალი საიტები Drupal 11-ზე დაიწყე. Drupal 10-ის საიტი ახლა უნდა განახლდეს და არა დეკემბერში; გზა არის 10.3 ან უფრო ახალი 11-მდე, მოდულ-მოდულ, Upgrade Status მოდულის დახმარებით, რომელიც გეუბნება, რა არის შეუთავსებელი. მოთხოვნები minor გამოშვებებთან ერთად იცვლება, ამიტომ რამეს ყიდვამდე ოფიციალური გვერდები შეამოწმე: PHP-ის მოთხოვნები და ბაზის მოთხოვნები.

Drupal 11-ის მოთხოვნები პრაქტიკაში:

მეხსიერება ცალკე სიტყვას იმსახურებს. Drupal საიტი რამდენიმე ათეული contributed მოდულით მოთხოვნაზე უფრო მეტ PHP მეხსიერებას იყენებს, ვიდრე ეკვივალენტური WordPress საიტი, და deploy-ის შემდეგ cache-ების თავიდან აგება ყველაზე მძიმე მომენტია. 1 GB გეგმა პატარა Drupal საიტს ამუშავებს; 2 GB კომფორტული საწყისი წერტილია ყველაფრისთვის, სადაც Views-ით დატვირთული გვერდები, Media და Search API არის, და PHP-ის memory_limit ასეთებზე 256 MB უნდა იყოს. php.ini პარამეტრები, რომლებსაც მნიშვნელობა აქვს memory_limit-ს, max_execution_time-ს და OPcache-ს ფარავს.

არსებობს ასევე Drupal CMS - Drupal core-ზე აგებული შეფუთული დისტრიბუცია site builder-ებისთვის, გავრცელებული ფუნქციების წინასწარ მორგებული recipe-ებით. ის ისევე ყენდება და ჰოსტდება; აქ ყველაფერი მასზეც ვრცელდება.

კოდის აწყობა Composer-ით#

მხარდაჭერილი საწყისი წერტილი drupal/recommended-project შაბლონია:

$ composer create-project drupal/recommended-project example.com$ cd example.com$ composer require drush/drush$ composer require drupal/admin_toolbar drupal/pathauto drupal/redis

შედეგს კონკრეტული განლაგება აქვს, და მისი გაგება ჰოსტინგის პრობლემების უმეტესობას აცილებს:

example.com/  composer.json        what you asked for  composer.lock        exact versions installed - commit this  vendor/              PHP libraries, Drush, Symfony - not web-accessible  web/                 the web root    index.php    core/    modules/contrib/    themes/contrib/    sites/default/

მხოლოდ web/ უნდა მიეწოდებოდეს. vendor/ და composer.json მის გვერდით, ვებ root-ის გარეთ დგას, ასე რომ HTTP-ით მათ ვერავინ მოითხოვს. ეს მთავარი სტრუქტურული განსხვავებაა WordPress-ისა და Joomla-სგან, სადაც ყველაფერი ვებ root-ში ცხოვრობს.

composer.json და composer.lock ვერსიების კონტროლში შეინახე შენს custom მოდულებთან და თემებთან ერთად, ხოლო vendor/, web/core და web/modules/contrib build-ის შედეგად განიხილე. composer.lock-ს ყოველთვის commit გაუკეთე - სწორედ ის უზრუნველყოფს, რომ build შენს ლეპტოპზე და build ექვსი თვის შემდეგ ერთსა და იმავე საიტს აწარმოებდეს.

დაყენება ჰოსტინგზე shell-ის გარეშე#

პანელზე დაფუძნებული ჰოსტინგი ხშირად გაძლევს file manager-სა და SFTP-ს, მაგრამ არა login shell-ს, ამიტომ Composer სერვერზე ვერ გაეშვება. ეს დაბრკოლება არ არის. ააწყვე ლოკალურად, შემდეგ build ატვირთე.

1. დაამთხვიე PHP ვერსიები. ლოკალურად გაუშვი იგივე major და minor PHP ვერსია, რაც სერვერზეა. Composer დამოკიდებულებებს იმ PHP-ისთვის ხსნის, რომლითაც მუშაობს, და PHP 8.4-ზე აწყობილმა lock ფაილმა შეიძლება ისეთი პაკეტები ჩამოიტანოს, რომლებიც 8.3-ზე გაშვებაზე უარს ამბობენ. დაამაგრე ის composer.json-ში "config": { "platform": { "php": "8.3.0" } }-ით, თუ შენი მანქანა რაღაც უფრო ახალს უშვებს.
2. ააწყვე development პაკეტების გარეშე: composer install --no-dev --optimize-autoloader.
3. გადაწყვიტე, სად მიდის ვებ root. თუ შეგიძლია მთელი პროექტის ატვირთვა და საიტის web/-ზე მიმართვა, ასე გააკეთე. თუ ჰოსტი ფიქსირებულ დირექტორიას ემსახურება - public_html, www, public - Drupal-ის ვებ root-ს გადაარქვი შესაბამისი სახელი, ფაილების გადაადგილების ნაცვლად: composer.json-ში შეცვალე ყოველი web/ გზა extra.installer-paths-ის ქვეშ და extra.drupal-scaffold.locations.web-root დააყენე დირექტორიის სახელზე, შემდეგ კვლავ გაუშვი composer install. პროექტი ატვირთე ამ დირექტორიაზე ერთი დონით ზემოთ, რომ vendor მის გარეთ დარჩეს.
4. ატვირთე ერთ არქივად. ათასობით პატარა ფაილი SFTP-ით გაცილებით მეტ დროს იღებს, ვიდრე ერთი zip. File manager, რომელიც არქივებს იქვე ხსნის, ამას ერთ ატვირთვად აქცევს; SFTP და file manager ორივე გზას ფარავს.
5. შექმენი ბაზა და მომხმარებელი, შემდეგ გახსენი საიტი და გაუშვი ინსტალერი.

თუ ჰოსტი ჩაწერის საშუალებას მხოლოდ ვებ root-ის შიგნით გაძლევს, Drupal-ის გაშვება მაინც შეგიძლია vendor-ით მის შიგნით, მაგრამ მაშინ უნდა დარწმუნდე, რომ ვებ სერვერი უარყოფს მოთხოვნებს vendor/-ზე, composer.json-სა და composer.lock-ზე - ეს ფაილები ყველაფრის ზუსტ ვერსიებს ამხელს, რასაც უშვებ. განლაგება, სადაც ვებ root ერთი დონით ქვემოთაა, უკეთესია, თუ მისი მიღება შეგიძლია.

RE:NODE-ზე Engines გეგმები ის ხაზია, რომელიც ასეთი CMS-ისთვისაა შერჩეული. Drupal-ს თავად აყენებ SFTP-ით ან file manager-ით - one-click ინსტალერი არ არის, და ამიტომ შენს ვერსიას სხვა არავინ ამაგრებს - და ყოველ გეგმას ორი ბაზის სლოტი აქვს, რომლებიც პანელიდან იქმნება გენერირებული host-ით, მომხმარებლითა და პაროლით. Drupal საიტს ერთი სჭირდება; მეორე staging ასლისთვისაა.

settings.php, ხაზ-ხაზ#

ინსტალერი sites/default/default.settings.php-ს settings.php-ში აკოპირებს და მასში ბაზის მონაცემებს წერს. რამდენიმე პარამეტრი ხელით უნდა დაემატოს ან შემოწმდეს.

$databases['default']['default'] = [  'driver'    => 'mysql',  'database'  => 'drupal',  'username'  => 'drupal_site',  'password'  => getenv('DRUPAL_DB_PASSWORD') ?: 'from-the-panel',  'host'      => 'db.example.internal',  'port'      => '3306',  'prefix'    => '',  'collation' => 'utf8mb4_general_ci',  'init_commands' => [    'isolation_level' => 'SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED',  ],];$settings['hash_salt'] = 'a-long-random-string';$settings['config_sync_directory'] = '../config/sync';$settings['file_private_path'] = '../private';$settings['trusted_host_patterns'] = ['^example\.com$', '^www\.example\.com$'];$settings['update_free_access'] = FALSE;

რისთვისაა თითოეული ხაზი:

• `host` და `port` ის ადგილია, სადაც ხალხი ცდება, ზუსტად ისე, როგორც WordPress-ში. localhost მხოლოდ მაშინ მუშაობს, როცა ბაზა იმავე მანქანაზე მუშაობს; ბაზის სლოტით ან ცალკე ბაზის სერვერით გამოიყენე ის hostname და პორტი, რომელიც მოგცეს.
• `init_commands` `READ COMMITTED`-ით MySQL ოჯახის ბაზებს ეხება. Drupal-ის სტატუსის ანგარიში მას გირჩევს, რადგან ნაგულისხმევი REPEATABLE READ დონე Drupal-ის ჩაწერის ნიმუშებზე მეტ deadlock-ს იწვევს. უფრო ახალმა ინსტალერებმა შეიძლება ეკვივალენტური isolation_level key თავად ჩაწერონ; ორიდან ერთი საკმარისია.
• `hash_salt` გამოიყენება ერთჯერადი შესვლის ბმულებისთვის, ფორმის token-ებისთვის და სხვა ხელმოწერებისთვის. ინსტალერი ერთს აგენერირებს; საიდუმლოდ შეინახე და ერთნაირი დატოვე ყველა სერვერზე, რომელიც იმავე საიტს უშვებს.
• `config_sync_directory` ის ადგილია, სადაც კონფიგურაცია ექსპორტდება და საიდანაც იმპორტდება. ვებ root-ის გარეთ დადე, როგორც ნაჩვენებია, რომ ექსპორტირებული კონფიგურაციის ჩამოტვირთვა შეუძლებელი იყოს.
• `file_private_path` რთავს პრივატულ ფაილებს, რომლებიც მხოლოდ Drupal-ის წვდომის შემოწმებით მიეწოდება. ესეც ვებ root-ის გარეთ.
• `trusted_host_patterns` უსაფრთხოების პარამეტრია და არა არჩევითი. მის გარეშე Drupal ნებისმიერ Host header-ს იღებს და შეიძლება მოატყუონ, რომ პაროლის აღდგენის წერილებში თავდამსხმელის დომენზე ბმულები დააგენერიროს. სტატუსის ანგარიში აფრთხილებს, სანამ არ დაყენდება.

ინსტალაციის შემდეგ settings.php და sites/default დირექტორია მხოლოდ წასაკითხი გახადე. Drupal ამას ამოწმებს და სტატუსის ანგარიშში ჩივის, თუ მათში ჩაწერა შეუძლია.

Reverse proxy-ის უკან Drupal-ს ეს უნდა უთხრა, სანამ ის X-Forwarded-For-სა და X-Forwarded-Proto-ს ენდობა:

$settings['reverse_proxy'] = TRUE;$settings['reverse_proxy_addresses'] = ['192.0.2.10'];

მისამართები ისაა, საიდანაც შენი proxy უკავშირდება. ამის გარეშე ყოველი ვიზიტორი ისე ჩანს, თითქოს proxy-დან მოდის, flood control ყველას ერთად ბლოკავს, და გენერირებულ URL-ებს შეიძლება HTTPS საიტზე http:// ჰქონდეს. რას აკეთებს reverse proxy header-ებს ხსნის.

nginx-ის წესები#

Drupal-ს მოყვება .htaccess ფაილი თავისი rewrite წესებითა და დაცვის ნაკრებით - .yml, .twig, composer.json და მსგავს ფაილებზე წვდომის აკრძალვით. nginx .htaccess-ს მთლიანად უგულებელყოფს, ამიტომ ეს დაცვები სერვერის კონფიგურაციაში თავიდან უნდა შეიქმნას. მისი ბირთვი:

location / {    try_files $uri /index.php?$query_string;}location @rewrite {    rewrite ^ /index.php;}location ~ ^/sites/.*/files/styles/ {    try_files $uri @rewrite;}location ~ (^|/)\. { return 403; }location ~ ^/sites/.*/private/ { return 403; }location ~* \.(engine|inc|install|make|module|profile|po|sh|sql|theme|twig|tpl|yml|yaml)$ {    return 403;}location ~ /vendor/ { deny all; }

styles ბლოკს იმაზე მეტი მნიშვნელობა აქვს, ვიდრე ჩანს: image style-ის წარმოებულები პირველ მოთხოვნაზე გენერირდება, ამიტომ იქ დაკარგული ფაილი Drupal-თან უნდა მივიდეს და არა 404 დააბრუნოს. მის გარეშე საიტზე ყოველი ზომაშეცვლილი სურათი გატეხილია. შეადარე დაცვების სრული სია .htaccess ფაილს შენს საკუთარ web/ დირექტორიაში, რომელიც შენი Drupal ვერსიისთვის ავტორიტეტული სიაა.

მართულ ჰოსტინგზე nginx-ის კონფიგურაციის თავად რედაქტირება შეიძლება არ შეგეძლოს. შეამოწმე, არის თუ არა სტანდარტული front-controller წესი (try_files ... /index.php) უკვე ადგილზე - თუ /user/login მუშაობს, არის. თუ image style-ები ან პრივატული ფაილები ცუდად იქცევიან, სწორედ ამაზე უნდა ჰკითხო შენს ჰოსტს.

Cron და ფონური სამუშაო#

Drupal-ს cron სჭირდება საძიებო ინდექსაციისთვის, ვადაგასული cache-ებისა და სესიების გასუფთავებისთვის, განახლებების შემოწმებისთვის, რიგების დამუშავებისთვის და ყველაფრისთვის, რასაც მოდულები გეგმავენ. მისი გაშვების სამი გზა არსებობს.

• Automated Cron, core მოდული, cron-ს გვერდის მოთხოვნის ბოლოს უშვებს, როცა საკმარისი დრო გავიდა - ნაგულისხმევად ყოველ სამ საათში, რაც /admin/config/system/cron-ზე ირგება. პატარა საიტებისთვის კარგია; ვიზიტორი, რომელიც მას იწვევს, უფრო ნელ პასუხს იღებს.
• Cron URL, რომელიც იმავე გვერდზე ჩანს როგორც https://example.com/cron/<key>. ნებისმიერ გარე scheduler-ს შეუძლია მისი მოთხოვნა - მონიტორინგის სერვისს, სხვა მანქანაზე დაგეგმილ job-ს. Key საიდუმლოდ შეინახე; ყველას, ვისაც URL აქვს, cron-ის გაშვება შეუძლია.
• Drush, drush cron, სისტემური crontab-იდან იქ, სადაც shell გაქვს. ყველაზე საიმედო ვარიანტი და ის, რომელიც cron-ს ვებ ტრაფიკზე არ აბამს.

თუ გარე ტრიგერს იყენებ, Automated Cron გამორთე, რომ cron ვიზიტორების მოთხოვნებშიც არ გაეშვას. Cron გამოსახულებების ახსნა განრიგის სინტაქსს ფარავს.

Cache და Valkey-ის დამატება#

Drupal-ის core cache კარგია და ნაგულისხმევად ჩართულია:

• Internal Page Cache ანონიმური ვიზიტორებისთვის მთელ გვერდებს ინახავს.
• Dynamic Page Cache cache-ში ინახავს გვერდების იმ ნაწილებს, რომლებიც ბევრი მომხმარებლისთვის ერთნაირია, შესულების ჩათვლით, cache context-ების გამოყენებით.
• BigPipe ჯერ cache-ირებულ გვერდის გარსს აგზავნის, პერსონალიზებულ ნაწილებს კი შემდეგ ნაკადად აწვდის.
• CSS-ისა და JavaScript-ის აგრეგაცია, Configuration-ში, შემდეგ Performance, production-ში ჩართული უნდა იყოს.

ნაგულისხმევად ყველა cache bin ბაზის ცხრილებში ცხოვრობს. დატვირთულ საიტზე ეს ბაზის დიდი ტრაფიკია მონაცემებისთვის, რომლებსაც მდგრადობა არ სჭირდება, და cache bin-ების Valkey-ში გადატანა სტანდარტული გაუმჯობესებაა. drupal/redis მოდული Redis პროტოკოლზე ლაპარაკობს და Valkey-ს უცვლელად უკავშირდება. ჯერ მოდული ჩართე, შემდეგ settings.php-ში დაამატე:

$settings['redis.connection']['interface'] = 'PhpRedis';$settings['redis.connection']['host'] = '203.0.113.20';$settings['redis.connection']['port'] = 6380;$settings['redis.connection']['password'] = getenv('VALKEY_PASSWORD');$settings['cache']['default'] = 'cache.backend.redis';$settings['cache_prefix'] = 'example_com_';$settings['container_yamls'][] = 'modules/contrib/redis/example.services.yml';

PhpRedis-ს phpredis გაფართოება სჭირდება; Predis სუფთა PHP ალტერნატივაა, რომელიც composer require predis/predis-ით ყენდება. დააყენე უნიკალური cache_prefix თითო საიტზე, თუ რამდენიმე ერთ Valkey-ს იზიარებს. ბაზა ჭეშმარიტების წყაროდ რჩება: cache ნებისმიერ დროს შეიძლება გასუფთავდეს drush cr-ით ან Clear all caches ღილაკით. Valkey გეგმა 256 MB-დან იწყება, რაც Drupal-ის cache bin-ების უმეტესობისთვის საკმარისზე მეტია; Valkey-ის მეხსიერება და eviction პოლიტიკები ხსნის, რატომ შეეფერება მხოლოდ cache-ისთვის განკუთვნილ ინსტანციას eviction-იანი პოლიტიკა.

განახლებები და კონფიგურაციის deploy-ები#

Drupal უსაფრთხოების განახლებებს გამოქვეყნებული განრიგით უშვებს, ჩვეულებრივ ოთხშაბათობით. Core-ისა და პოპულარული მოდულების უსაფრთხოების გამოშვებები drupal.org-ზე ცხადდება, და Update Status მოდული ელფოსტას გიგზავნის, როცა შენი საიტი ჩამორჩება. წაიკითხე advisory-ები; "highly critical" core გამოშვება, როგორიც 2018 წლის Drupalgeddon-ის პრობლემები იყო, საათებში იწყებს ექსპლუატაციას.

თავად განახლება, Composer-ით:

$ composer update "drupal/core-*" --with-all-dependencies$ drush updatedb$ drush cache:rebuild

Shell-ის გარეშე composer update ლოკალურად გაუშვი, ატვირთე შეცვლილი vendor/ და web/core/ (და ნებისმიერი განახლებული მოდული), შემდეგ ადმინისტრატორად გახსენი /update.php, რომ ბაზის განახლებები გაუშვა. ჯერ backup აიღე, ყოველ ჯერზე, და განახლების დროს საიტი maintenance mode-ში გადაიყვანე, რომ შუა გზაზე ბაზაში არავინ ჩაწეროს. Backup-ები, რომლებიც მართლა აღდგება არგუმენტია ამ backup-ის ტესტირებისთვის.

კონფიგურაციის ცვლილებები - content type-ები, ველები, view-ები - development-იდან production-ზე კონფიგურაციის მართვით უნდა გადავიდეს და არა ორჯერ დაკლიკებით: drush config:export development ასლზე, YAML ფაილების commit, deploy, drush config:import production-ზე. UI-ის ეკვივალენტი Configuration-შია, შემდეგ Development, შემდეგ Configuration synchronisation.

პრობლემების მოგვარება#

ინსტალერი ჩერდება "Requirements problem"-ზე. წაიკითხე სია: ჩვეულებრივ აკლია PHP გაფართოება, Drupal 11-ისთვის PHP ვერსია 8.3-ზე დაბალია, ან sites/default/files ჩასაწერი არ არის.

"The provided host name is not valid for this server". trusted_host_patterns არ ემთხვევა hostname-ს, რომელსაც სტუმრობ. დაამატე, www-ის ჩათვლით, თუ გამოიყენება.

თეთრი ეკრანი ან "The website encountered an unexpected error". შეამოწმე ბოლო log შეტყობინებები /admin/reports/dblog-ზე, ან PHP-ის შეცდომების log, თუ ადმინისტრაციული ნაწილი მიუწვდომელია. Cache-ების თავიდან აგებისას მეხსიერების ამოწურვა ხშირია; გაზარდე memory_limit.

მთავარი გვერდის გარდა ყველა გვერდი 404-ს აბრუნებს. Front-controller-ის rewrite აკლია - ტიპური nginx-ზე, როცა მხოლოდ Apache-ის .htaccess-ის იმედი ჰქონდათ.

Image style-ებში სურათები გატეხილია. ზემოთ მოცემული styles წესი აკლია, ან sites/default/files ჩასაწერი არ არის.

Redirect loop-ები HTTPS-ის ჩართვის შემდეგ. Proxy header-ებს არ ენდობა; დააყენე reverse_proxy და მისი მისამართები.

FAQ#

შემიძლია Drupal-ის დაყენება Composer-ის გარეშე?

Drupal 11-ისთვის მხარდაჭერილი გზით არა. Core-ის არქივის ჩამოტვირთვები არსებობს, მაგრამ contributed მოდულები თავიანთ დამოკიდებულებებს Composer-ით აცხადებენ, და მათი ხელით მართვა პირველივე მოდულზე ტყდება, რომელსაც ბიბლიოთეკაზე დამოკიდებულება აქვს. ააწყვე Composer-ით ნებისმიერ მანქანაზე, შემდეგ შედეგი ატვირთე.

რამდენი ჰოსტინგი სჭირდება Drupal საიტს?

პატარა ვიზიტკა საიტი 1 GB-ზე მუშაობს ერთი ან ორი CPU ბირთვით. საიტს Views-ით დატვირთული გვერდებით, Media-თი, Search API-ით და გარკვეული შესული ტრაფიკით 2 GB ან მეტი სჭირდება და PHP-ის memory_limit 256 MB. მეხსიერება და PHP worker-ების რაოდენობა ჩვეულებრივ CPU-მდე ხდება ლიმიტი.

უფრო რთულია Drupal-ის ჰოსტინგი, ვიდრე WordPress-ის?

ის build-ის ეტაპზე მეტს ითხოვს - Composer, ცალკე ვებ root, კონფიგურაციის მართვა - და ოდნავ მეტ მეხსიერებას. სანაცვლოდ, მისი cache და სტრუქტურირებული კონტენტი უფრო შორს მასშტაბირდება, სანამ რამის დამატება დაგჭირდება. ჰოსტინგის მხრივ ორივე PHP აპლიკაციაა ბაზით.

როდის უნდა დავტოვო Drupal 10?

Drupal 10-ის უსაფრთხოების მხარდაჭერა 2026 წლის 9 დეკემბერს სრულდება. მანამდე განაახლე Drupal 11-მდე; საიტები, რომლებიც ამ თარიღის შემდეგ ჯერ კიდევ Drupal 10-ზე არიან, უსაფრთხოების შესწორებებს აღარ იღებენ.

მჭირდება Valkey Drupal-ისთვის?

არა. Drupal-ის ბაზაზე დაფუძნებული cache-ები პატარა და საშუალო მასშტაბზე მუშაობს. Cache bin-ების Valkey-ში გადატანა ბაზას დატვირთვას აშორებს და დატვირთულ საიტებს ეხმარება, განსაკუთრებით მათ, სადაც ბევრი შესული მომხმარებელია.