# منع LiteSpeed من قطع سكربتات PHP الطويلة
Source: https://docs.webgee.com/ar/hosting/wordpress/execute-php-scripts-with-no-timeout-when-using-litespeed



بعض سكربتات PHP تعمل دقائق بحق — نسخ احتياطية كاملة، واستيرادات كبيرة، وإعادة
بناء فهارس قواعد البيانات، ومهام WP-Cron. وLiteSpeed يوقف الطلبات الطويلة أو
الصامتة افتراضيًا، فقد يقتلها في منتصفها. ينطبق على كل الاستضافة المشتركة
والموزِّعة، التي تعمل بـ LiteSpeed.

وحمايتان منفصلتان تسبّبان هذا، وتحتاجان علاجين مختلفين. ومعظم السكربتات الطويلة
تحتاج الاثنين.

| المتغيّر        | يمنع LiteSpeed من                        | يُحتاج حين                                |
| --------------- | ---------------------------------------- | ----------------------------------------- |
| `noabort`       | قتل PHP حين يُغلَق اتصال الزائر          | يُبدأ السكربت ثم يُترَك، كما يفعل WP-Cron |
| `noconntimeout` | إغلاق اتصال لم يُرسل شيئًا منذ مدة طويلة | يعمل السكربت طويلًا قبل أن ينتج مخرجات    |

وكلاهما خاص بـ LiteSpeed ويجب تغليفهما في كتلة `IfModule` كي تُتجاهَل القواعد
على أي خادم ويب آخر.

## اضبطهما في ‎.htaccess [#اضبطهما-في-htaccess]

أضف هذا إلى ملف `.htaccess` في الجذر المستنَدي لموقعك:

```apache
<IfModule Litespeed>
SetEnvIf Request_URI "(wp-cron|backupbuddy|importbuddy)\.php" noabort noconntimeout
</IfModule>
```

وذلك يستهدف السكربتات الثلاثة الأكثر تأثرًا. استبدل الأسماء بما يسمّى به سكربتك
الطويل.

ولتطبيقه على كل طلب في الموقع بدلًا من ذلك:

```apache
<IfModule Litespeed>
SetEnv noabort 1
SetEnv noconntimeout 1
</IfModule>
```

<Callout type="warn">
  تطبيق هذا على كل طلب يزيل الحماية التي توقف سكربتًا شاردًا عن استهلاك الموارد
  إلى ما لا نهاية. وعلى الاستضافة المشتركة يُحسب ذلك على حدود حسابك. استهدف
  السكربتات المحدّدة التي تحتاجه.
</Callout>

## فضّل SetEnv على قواعد إعادة الكتابة [#فضّل-setenv-على-قواعد-إعادة-الكتابة]

يمكن بلوغ النتيجة نفسها بأعلام إعادة الكتابة:

```apache
<IfModule Litespeed>
RewriteEngine On
RewriteRule (wp-cron|backupbuddy|importbuddy)\.php - [E=noabort:1,E=noconntimeout:1]
</IfModule>
```

واستخدم `SetEnv` و`SetEnvIf` بدلًا منها حيثما أمكن. فقواعد إعادة الكتابة حسّاسة
لموضعها بالنسبة إلى القواعد الأخرى — وكتلة إعادة الكتابة الخاصة بووردبريس
خصوصًا — فالقاعدة الموضوعة بعد كتلة ووردبريس قد لا تُبلَغ أبدًا. أما `SetEnv`
فيمكن وضعه في أي مكان في الملف.

ولا تستخدم النهجين معًا للسكربت نفسه.

## حدّ PHP نفسه يظل ساريًا [#حدّ-php-نفسه-يظل-ساريًا]

هذان المتغيّران يتحكّمان في **LiteSpeed**. ولـ PHP حدّ منفصل، وقد يظل يوقف
سكربتًا:

```ini
max_execution_time = 300
```

اضبطه في **MultiPHP INI Editor** داخل cPanel. راجع
[إصدارات PHP وإعداداتها](/ar/development).

فإن توقّف سكربت عند وقت ثابت — 30 ثانية أو 60 بالضبط — فذلك حدّ PHP دائمًا
تقريبًا لا حدّ LiteSpeed.

## قبل أن تلجأ إلى هذا [#قبل-أن-تلجأ-إلى-هذا]

السكربت الذي يحتاج دقائق عَرَض غالبًا لا متطلَّب.

* **WP-Cron** استبداله بمهمة cron حقيقية أفضل من إبقائه حيًا. فـ cron في النظام
  يستدعي WP-CLI أوثق ولا يعتمد على وصول زائر.
* **نسخ الإضافات الاحتياطية** تكتب نسخًا كاملة من الموقع داخل حصة قرصك، ويزيلها
  تنظيف WebGee. استخدم JetBackup بدلًا منها — راجع
  [الملفات التي تحذفها WebGee تلقائيًا](/ar/hosting/understanding-our-internal-auditing-and-cleanup-process).

## تحقّق [#تحقّق]

شغّل السكربت وتأكّد من اكتماله. فإن ظل يتوقف، فافحص إن كان يتوقف عند وقت ثابت —
فذلك يشير إلى `max_execution_time` لا إلى LiteSpeed.

## اقرأ أيضًا [#اقرأ-أيضًا]

* [تحسين لوحة ووردبريس أو WooCommerce البطيئة](/ar/hosting/wordpress/how-to-improve-a-slow-wordpress-or-woocommerce-dashboard)
* [الملفات التي تحذفها WebGee تلقائيًا](/ar/hosting/understanding-our-internal-auditing-and-cleanup-process)