إدارة الاستضافة عادةً تقطع عليك مسار التطوير. تكتب الكود في محرر، وتفتح لوحة استضافة لإنشاء موقع، وتبدّل إلى الطرفية لحزم المشروع أو رفعه، وترجع للوحة عشان تراجع عملية نشر، وتفتح أدوات أكثر لما تحتاج تتعامل مع DNS أو السجلات أو موارد الخادم.
Hostinger Connector يخفف هالتنقّل بين النوافذ. يربط خدمات Hostinger بأدوات البرمجة بالذكاء الاصطناعي عبر Model Context Protocol (MCP)، بحيث تقدر تسأل مساعد ذكاء اصطناعي يفحص أو يدير الموارد المدعومة في الاستضافة بدون ما تطلع من المحرر.
هذا يبان عملي. لكنه يطرح سؤال أهم: هل تقدر تثق بمساعد ذكاء اصطناعي عشان ينفذ مهام استضافة حقيقية بدقة؟
عشان أتأكد، اختبرت Hostinger Connector مع VS Code وGitHub Copilot على حساب Hostinger حقيقي. استخدمت تطبيق Express.js صغير اسمه PulseWatch واتبعت سير العمل من التثبيت إلى النشر المباشر. واختبرت بعدين إعادة النشر، وسجلات البناء، والسجلات، والاسترجاع بعد ما خربت عمدًا أمر التشغيل للتطبيق.
هنا كيف قيمت Hostinger Connector في الجوانب اللي تهم المطور أكثر: التكلفة، نطاق المزايا، سهولة الاستخدام اليومي، دقة تنفيذ المهام الحقيقية، والدعم اللي يسانده إذا صار شيء. كل درجة تعكس اللي لقيته فعلاً أثناء الاختبار، مو صفحة التسويق.
| المعيار | الدرجة | ليش هالدرجة |
|---|---|---|
| الأسعار | 9.7/10 | الـ Connector ما عليه رسوم اشتراك إضافية أبدًا، وهو مرفق مجانًا مع كل خطة. التكلفة الوحيدة هي مورد الاستضافة الأساسي اللي أنت تحتاجه أصلًا. |
| المزايا | 9.5/10 | نطاق المزايا يتجاوز النشر إلى المواقع، النطاقات، DNS، قواعد البيانات، حملات البريد الإلكتروني، موارد VPS، السجلات، والتشخيص، ويغطي مجال أوسع من أداة نشر عادية. |
| سهولة الاستخدام | 9.1/10 | التثبيت وOAuth كانا سريعين وما احتاجا أي إعداد يدوي، وإعادة النشر كانت سهلة. إعداد موقع Node.js الأول احتاج hPanel لأن الذكاء الاصطناعي ما قدر يحدد هدف صالح، وهي الثغرة الوحيدة في إعداد سلس تقريبًا. |
| دقة التنفيذ | 8.5/10 | تحليل المشروع، تعديل الكود، الحزم، النشر، والاسترجاع كلها نجحت بشكل جيد. لكن الذكاء الاصطناعي أعاد استخدام نطاق مخترع وفسر فحص الوصولية بشكل أوسع من اللازم قبل وجود الهدف أصلًا. |
| الدعم | 9.5/10 | Kodee أعطى جوابًا دقيقًا ومحددًا لسؤال تقني حقيقي من أول مرة، والموظف البشري في المتابعة كان أدق بعد. التصعيد احتاج طلبين مباشرين، لكن إجابات الذكاء الاصطناعي والبشري كانت موثوقة بعد ما وصلت. |
| الإجمالي | 9.3/10 | أداة سير عمل مفيدة لمستخدمي Hostinger اللي يشتغلون في محررات مدعومة بالذكاء الاصطناعي. ما تكلف شيء إضافي، وتغطي مجموعة واسعة من المزايا، وكل من الإعداد والدعم صمدوا جيدًا في الاختبار. دقة التنفيذ مع أهداف النشر الجديدة هي النقطة اللي لازم تنتبه لها. |
Hostinger Connector ما ينبيع كمنتج مستقل. Hostinger تقول إن Connector مرفق مجانًا مع كل خطة، وهذا يعني ما فيه رسوم شهرية منفصلة تضيفها إلى فاتورة الاستضافة.
لكن كلمة “مجانًا” تحتاج سياق. Connector يدير موارد Hostinger؛ ما يستبدلها. لا يزال لازم يكون عندك استضافة مؤهلة، أو سحابة، أو VPS، أو نطاق، أو بريد، أو أي خدمة Hostinger ثانية عشان المهام اللي تبي ينفذها.
وقت كتابة هالمراجعة، صفحة Connector الرئيسية كانت تعرض Business Web Hosting وCloud Startup.
| الخطة | السعر الترويجي | المدة المقدمة | سعر التجديد | تطبيقات ويب | مواقع |
|---|---|---|---|---|---|
| Business | $3.79/month | $181.92 for 48 months | $16.99/month | 5 | 50 |
| Cloud Startup | $7.99/month | $383.52 for 48 months | $25.99/month | 10 | Unlimited |
الأسعار كانت معروضة قبل الضرائب المطبقة. الأسعار الترويجية ومعدلات التجديد ممكن تتغير، فراجع إجمالي الدفع الحالي بدل ما تحكم على الخطة من السعر الشهري المعروض فقط.
معلومة سعرية: لا تشتري خطة أعلى فقط عشان تقدر تستخدم Connector. اختر الخطة بحسب عدد المواقع وتطبيقات الويب اللي تحتاجها، والموارد اللي تتطلبها، ومستوى الدعم اللي تبيه. Connector طبقة إدارة مرفقة، مو المنتج الأساسي اللي يتم تسعيره.
Hostinger تعلن عن ضمان استرداد خلال 30 يوم للمشتريات المؤهلة من الاستضافة. ما فيه سياسة استرداد منفصلة للـ Connector لأنه ما عليه رسوم مستقلة.
العمليات المتاحة بالضبط تعتمد على خدمات Hostinger الموجودة في حسابك والأدوات اللي يعرّضها عميل الذكاء الاصطناعي المتصل.
Hostinger توثق أيضًا حدود المعدل. حسب FAQ الخاص بالـ Connector، السماح الافتراضي هو 60 طلبًا في الدقيقة و1,000 طلب في الساعة، ومعلومات حدود المعدل تُرجع في ترويسات الاستجابة.
هالحدود سخية للاستخدام التفاعلي، لكن سير العمل الآلي أو المتكرر جدًا لا يزال لازم يتجنب النداءات المكررة غير الضرورية.
قبل ما أقدر أحكم إذا كان Hostinger Connector ينشر ويدير الاستضافة بشكل جيد، كنت بحاجة أعرف وش يتطلب عشان يشغل من الأساس.
أداة مبنية على البقاء داخل المحرر تفقد جاذبيتها بسرعة إذا كان الإعداد يعني تعديل ملفات إعداد، أو إنشاء رموز API، أو إعادة مصادقة متكررة. هالقسم يغطي الإعداد فقط. واختبار المهام العملية يجي بعده مباشرة.
ثبت Hostinger Connector من VS Code Marketplace. طلع أول نتيجة لما بحثت عن “Hostinger”، والناشر كان Hostinger Official، وتثبت من أول محاولة خلال أقل من دقيقتين.
| التفصيل | النتيجة |
|---|---|
| البحث في المتجر | نجح، وظهر مباشرة |
| التحقق من الناشر | Hostinger Official |
| التثبيت | اكتمل في أقل من دقيقتين |
| إصدار الامتداد وقت الاختبار | 1.3.1 |
| عمليات التثبيت في المتجر | 8,140 |
| تقييم المستخدم | 5 نجوم، بناءً على تقييمين |
هالسطر الأخير يحتاج تنبيه. خمس نجوم شكلها قوي، لكن عينة من تقييمين فقط ما تعني لي شيء تقريبًا عن تجربة المستخدم المعتادة. ما أنصح أبني نص المراجعة على هالرقم.
شرط مسبق فاجأني: Hostinger Connector يوفر أدوات Hostinger، لكنه يحتاج وكيل ذكاء اصطناعي شغال بالفعل داخل المحرر عشان يستدعيها.
الامتداد نفسه ما عنده شيء يتواصل معه من دون ذلك. في VS Code، هالوكيل هو GitHub Copilot Chat، لأنه حاليًا واجهة الذكاء الاصطناعي اللي يتيحها VS Code لاستدعاءات أدوات MCP. كان Copilot عندي شغال أصلًا، فهالشي ما أبطأني، لكن لازم القارئ يعرف إن Connector فائدته مرهونة بالوكيل الذكي اللي وراءه.
بدون وكيل مثبت ومسجل دخول، ما فيه شيء يرتبط به.
وش ما احتاجه التثبيت:
تثبيت الامتداد نفسه كان من أسهل أجزاء الاختبار كله. القيد الحقيقي الوحيد هو اعتماد Hostinger ما يبرزه قدامك: الامتداد يحتاج وكيل ذكاء اصطناعي نشط داخل المحرر عشان يسوي أي شيء.
بعد ما صار الامتداد موجود، كان السؤال التالي هل ربطه بحساب حقيقي بيكون بنفس السهولة.
ربط الحساب استخدم OAuth عبر زر “1-Click Connect”. فتح VS Code صفحة تفويض Hostinger في المتصفح، والتقط جلسة Hostinger الحالية، وطلب مني الموافقة على وصول باسم hostinger-mcp.
بعد ما ضغطت Allow، رجعت إلى VS Code وظهر لي “Connected via OAuth”.
| التحقق | النتيجة |
|---|---|
| الاتصال بنقرة واحدة | نجح |
| المتصفح فتح تلقائيًا | نجح |
| تم اكتشاف جلسة Hostinger موجودة | نجح |
| كان مطلوب رمز API يدوي | لا |
| ظهرت شاشة التفويض | نعم |
| تم شرح الأذونات | نعم، لكن بشكل عام |
| العودة إلى VS Code نجحت | نجح |
شاشة التفويض قالت لي إن Connector يقدر يدير المواقع، والاستضافة، والنطاقات، والاشتراكات، وخدمات Hostinger الثانية.
هذا تصنيف عام، مو تفصيل أذونات بندًا بندًا. ودي كان فيه تفصيل أكثر هنا، لأن “إدارة الاشتراكات” و”إدارة المواقع” شيء مختلف جدًا من ناحية المخاطرة.
اللي عطاني بعض هالتحكم كان لوحة منفصلة داخل الامتداد تعرض كل فئة أدوات وتسمح لي أشغلها أو أوقفها كل وحدة لحالها:
| فئة الأدوات | الأدوات المتاحة | الحالة الافتراضية |
|---|---|---|
| Websites | 80 | مفعلة |
| Domains | 26 | مفعلة |
| Subscriptions and Payments | 7 | مفعلة |
| Email Marketing | 12 | مفعلة |
| Ecommerce | 12 | معطلة |
| VPS | 62 | معطلة |
هذا 199 أداة بالمجموع، و125 منها مفعلة افتراضيًا. خليت Ecommerce وVPS مطفّلين إلى أن كنت مستعد أختبرهم مباشرة، والامتداد التزم بهالحدود طوال الاختبار.
هذا نوع من تفاصيل الأمان ما يطلع في صفحة التسويق من Hostinger، لكنه مهم لأي شخص يفكر كم صلاحية يعطي مساعد ذكاء اصطناعي. أعتبره نقطة قوة حقيقية.
فصل الحساب متاح من نفس اللوحة، بدون الحاجة تغير كلمة مرور Hostinger أو تدور على رمز مخزن.
التفويض كان سريع وما احتجت أتعامل مع رمز بنفسي، لكن شاشة الأذونات عامة أكثر من اللازم بدل ما تكون مفصلة. عناصر التحكم على مستوى الفئات داخل الامتداد تحد فعلًا من المخاطر أكثر من شاشة OAuth نفسها.
Hostinger تسرد الدعم للعملاء التالية أسماؤهم، ومجمعة من شاشة الإعداد داخل الامتداد:
| المحرر أو العميل | مذكور من Hostinger |
|---|---|
| VS Code | نعم |
| Cursor | نعم |
| Windsurf | نعم |
| Devin Desktop | نعم |
| Antigravity | نعم |
| Claude Code | نعم |
| OpenAI Codex CLI | نعم |
أنا استخدمت VS Code مع GitHub Copilot كبيئة الاختبار الرئيسية.
الإعداد قال لي إن Connector سهل الوصول. لكنه ما قال لي بعد إذا فعلاً ينجز الشغل بشكل جيد بعد ما يتصل، وهذا هو السؤال الأصعب اللي رحت له بعدين.
تثبيت وربط إضافة شيء سهل. المهم فعلاً هو هل ينجز شغل الاستضافة الحقيقي بشكل صحيح، فبنيت تطبيق Express.js صغير اسمه PulseWatch وحطيت Connector على نفس المسار اللي يمشيه أي مطور بعد التثبيت: يفحص الحساب، يلقى هدف النشر، ينشر المشروع، يحدّثه، يراجع النتائج، ويتعافى من خطأ تعمدت أسويه.
| الاختبار | وش أبغى أعرف |
|---|---|
| قراءة بيانات الحساب | هل يقدر يفهم حساب الاستضافة بدقة؟ |
| إيجاد هدف النشر | هل يقدر يحدد الموقع الصحيح بدون تخمين؟ |
| تحليل مشروع Node.js | هل يفهم التطبيق قبل ما يلمسه؟ |
| نشر PulseWatch | هل يقدر ينقل مشروع حقيقي من المحرر إلى الاستضافة الحية؟ |
| نشر تحديث للمحتوى | هل هو مفيد للشغل التطويري الروتيني؟ |
| فحص البنى والسجلات | هل يعطيني دليل مفيد بعد النشر؟ |
| نشر نسخة مكسورة | هل يكشف فشل حقيقي في التطبيق؟ |
| استرجاع التطبيق | هل يقدر يرجع إصدار معروف وسليم بأمان؟ |
PulseWatch كان بسيط عمدًا: خادم Express، صفحة رئيسية، start script في package.json، ونقطة /api/health ترجع JSON. هالنقطة الصحية صارت مهمة بعدين.
منصة الاستضافة ممكن تقول إن البناء اكتمل حتى لو التطبيق يفشل عند التشغيل. نقطة صحية مباشرة أعطتني طريقة مستقلة أتأكد فيها هل العملية المنشورة فعلًا ترد، بدل ما أثق بشارة الحالة.
بدأت بأوامر للقراءة فقط قبل ما أخلي المساعد يقترب من أي تغيير حي. إذا ما قدر يوصف حسابي بدقة، فما عندي سبب قوي أثق فيه في النشر أو DNS أو مهام VPS.
أداة عرض المواقع في Connector رجعت خمس مواقع:
لكن حسابي فعليًا كان فيه أكثر من كذا. hPanel عرض مواقع موزعة على خطط Premium وBusiness وGrowth، بما فيها مواقع WordPress، ومواقع PHP/HTML، ومشاريع Website Builder، وعدة نطاقات مؤقتة.
وفي أمر منفصل سألته عن خطط الاستضافة النشطة، وقال لي إن عندي “خطة استضافة نشطة واحدة”. لكن hPanel كان يوضح ثلاث خطط: Premium وGrowth وBusiness.
| التحقق | النتيجة |
|---|---|
| عرض المواقع المعروفة | نجح |
| عرض كل خطط الاستضافة | فشل |
| اكتشاف خطة Business غير المستخدمة | فشل |
| إجراء أي تغييرات على الحساب | لا |
وبالإنصاف للـ Connector، لما واجهته وقلت له إن فيه تعارض، صحح نفسه، وفصل بوضوح بين اللي تحقق منه وبين اللي افترضه، وما كرر المعلومة الغلط.
هذا أفضل من إنه يصر على الخطأ، لكنه يعني إن أول جواب على سؤال يخص الحساب ككل ما لازم يؤخذ على أنه مسلم به.
القراءة فقط نجحت، لكن أول جواب لأي سؤال على مستوى الحساب كان ناقص. صححه بعد ما واجهته، وهذا مهم، لكن كان المفروض ما أضطر أواجهه.
هالثغرة في رؤية الحساب كانت مقدمة لمشكلة أكبر. الاختبار الحقيقي إذا كانت مهمة أو لا جاء بعدين، لما طلبت من Connector يلقى موقع ما كان أحد قال له اسمه من قبل.
هنا ظهر أكبر شيء في الاختبار. طلبت من المساعد يحدد موقع Node.js جديد بدون ما أسمي النطاق، وبدون ما يلمس أي موقع موجود.
اختيار الهدف مطلب أمان أساسي لأداة تقدر تتصرف على حساب حي، فكنت أبغى أشوف كيف يتعامل مع الغموض بدل الإجابة النظيفة الجاهزة.
هذا اللي صار، بالترتيب:
| الخطوة | وش سوّى Connector | النتيجة |
|---|---|---|
| 1 | أعاد استخدام اسم نطاق من محاولة سابقة فاشلة: pulsewatch-temp-20260714.hostingersite.com | هذا النطاق ما رجع أبدًا في أي نداء لقائمة المواقع |
| 2 | شغّل فحص وصولية على هالنطاق | رجع is_accessible: true |
| 3 | اعتبر النتيجة تأكيدًا إن الموقع موجود | غير صحيح. الوصولية مو نفس وجود سجل موقع قابل للنشر |
| 4 | حاول النشر باستخدام معرّفات موارد ما تحقق منها كأرقام طلب استضافة | Hostinger رجعت [Hosting:9999] Not found، مرتين |
المشكلة الأساسية: المعرّفين اللي استخدمهم كانوا معرّفات موارد نطاق، مو أرقام طلب استضافة. وما تأكد من هالفرق قبل ما يستدعي أداة إنشاء موقع حي باستخدامهم.
لما طلبت منه يشرح، أعطى في النهاية سردًا صحيحًا: كانت عنده أداة قائمة مواقع شغالة طول الوقت، لكنه ما ناداها مرة ثانية بعد ما أنشأت موقعًا جديدًا عبر hPanel، فملأ الفجوة بنطاق غير متحقق منه بدل ما يحدّث بياناته.
ولما طلبت منه مباشرة يعيد تشغيل أداة القائمة ويتحقق من وجود سجل جديد، نادى ثلاث أدوات غير مرتبطة ببيانات النشر وقال “ما ظهر موقع جديد”، مع أن نداءات الأدوات اللي استخدمها ما كانت تقدر تدعم هالاستنتاج.
ولا شيء من هذا أنشأ موقعًا زائدًا في حسابي. المحاولات الفاشلة ما تركت شيئًا خلفها. لكن النمط يستحق أنه ينقال بوضوح. مع بيانات ناقصة، المساعد عبّى الفراغ بافتراض منطقي ظاهريًا، واعتبر إشارة ضعيفة دليلًا قويًا، وتصرّف على حساب حي قبل ما يتأكد من هالافتراض.
هذا أهم اكتشاف في هالقسم. Connector بيخمن الهدف ويتصرف على هالتخمين بدل ما يوقف ويسأل. هنا فشل بأمان، لكن عادة التعامل مع إشارة ضعيفة وكأنها إثبات هي الشيء اللي لازم تنتبه له في حسابك أنت.
وبما إن Connector ما قدر يلقط الهدف بنفسه، ما بقي عندي إلا خيار واحد: أبني الهدف بنفسي وأشوف إذا هالشي يغيّر شيء.
بما إن Connector ما قدر يحدد الهدف الجديد بشكل موثوق بنفسه، كملت الإعداد الأولي يدويًا عبر hPanel عشان أشوف وش يجهز Hostinger قبل ما يصير النشر عبر Connector ممكن.
المسار كان: إنشاء موقع جديد → تطبيق ويب Node.js → نطاق مؤقت → Hostinger اختار تلقائيًا مركز بيانات في المملكة المتحدة مع زمن وصول تقديري 147ms → وثلاث طرق نشر للاختيار بينها.
الشاشة الثالثة هنا تستاهل تنبيه بحد ذاتها. Hostinger تعرض “Build with Hostinger Connector” كطريقة نشر إلى جانب GitHub import والرفع اليدوي للملفات. اخترتها وأنا متوقع إنها تكمل إعداد الموقع.
بدل كذا، حولتني إلى صفحة التثبيت الخاصة بالـ Connector، وأنا كنت مثبتها بالفعل. هذه ثغرة حقيقية في مسار الإعداد. الخيار المعروض كمسار أصلي للـ Connector ما فعّل شيء فعليًا.
رجعت واخترت الرفع اليدوي للملفات. Hostinger قبلت أرشيف مشروعي (11.46 KB، مع استثناء node_modules)، وشاشة الإعداد أظهرت اكتشافًا تلقائيًا صحيحًا:
ضغطت Deploy. اكتمل بنجاح، وHostinger أعطتني نطاقًا مؤقتًا حقيقيًا: orange-walrus-700988.hostingersite.com. هذا نطاق مختلف عن اللي اخترعه Connector سابقًا. فتحت الصفحة الرئيسية و /api/health يدويًا وتأكدت إن الاثنين يشتغلون.
المسار اليدوي اشتغل بدون أي تعقيد بمجرد ما توقفت أنتظر Connector يلاقيه. زر “Build with Hostinger Connector” في هالشاشة لازم ينصلح أو ينشال. حاليًا يوعد بشي ما يسويه.
صار فيه موقع حقيقي ومؤكد الآن. والسؤال التالي كان هل Connector بيتصرف بشكل مختلف بعد ما صار عنده شيء واضح يلقطه.
بعد ما صار فيه موقع حقيقي ومؤكد، رجعت للـ Connector وطلبت منه يفحص هالنطاق بالضبط. هالمرة اشتغل بشكل نظيف.
| التحقق | النتيجة |
|---|---|
| تعرف على الموقع كهدف نشر Node.js | نجح |
| وجد سجل النشر المكتمل | نجح |
| وجد سجل بناء Node.js المطابق | نجح |
| النشر والبناء يشتركان في نفس UUID | نجح |
هذا أكد شيء مهم: الإخفاقات السابقة كانت في تحديد وإنشاء هدف جديد، مو في قدرة Connector على التعامل مع موقع Node.js إذا كان موجود أصلًا.
بعدها اختبرت الميزة اللي Hostinger تروج لها أكثر شيء: تعديل سطر كود محليًا ونشره بدون فتح hPanel.
طلبت من المساعد يغير سطر واحد من نص الصفحة الرئيسية، من “Monitor Every Service. Catch Every Issue.” إلى “Monitor Every Service. Resolve Issues Faster.”
| الخطوة | النتيجة |
|---|---|
| وجد النص الحالي | نجح |
| غيّر فقط السطر المطلوب | نجح |
| تحقق من التطبيق محليًا قبل النشر | نجح |
حزم المشروع مع استثناء node_modules و .git | نجح |
| نشره إلى الموقع المؤكد الموجود | نجح |
| فحص حالة النشر والبناء بعدين | نجح |
كل التحديث أخذ تقريبًا دقيقة. المساعد وصف النشر الجديد على أنه “pending” مباشرة بعد الإرسال، فقط لأنه فحص قبل ما Hostinger تخلص المعالجة.
وبعد ما حدثت الموقع الحي بنفسي، كان العنوان الجديد ظاهرًا بالفعل.
سجلات البناء اللي رجعها بعدين كانت محددة ومفيدة: 67 حزمة مضافة، 68 مفحوصة، صفر ثغرات، ولا أخطاء.
بالنسبة للمواقع الموجودة أصلًا، هذا قريب جدًا من سير العمل اللي تعد فيه Hostinger: تعدل، تتحقق محليًا، تنشر، وتؤكد، وكل هذا بدون مغادرة المحرر، خلال حوالي دقيقة. هذا أقوى نتيجة في الاختبار كله.
النشر النظيف يقول لي فقط إن المسار السهل يشتغل. عشان أعرف وش يسوي Connector تحت الضغط فعليًا، خربت التطبيق عمدًا.
الأداة ما تكسب الثقة إلا إذا صمدت أمام فشل حقيقي، مو مجرد عرض نظيف. خربت التطبيق عمدًا عشان أشوف هل تقارير الحالة والسجلات في Connector تقدر تساعدني فعليًا أشخّص المشكلة.
قبل أي تعديل، المساعد سوّى نسخة احتياطية من package.json إلى package.json.bak، وهذه عادة جيدة بحد ذاتها.
بعدها خليته يغير start script من “start”: “node server.js” إلى “start”: “node missing-server.js”، وهو ملف غير موجود.
التشغيل محليًا أكد فشلًا حقيقيًا وقابلًا لإعادة الإنتاج: Error: Cannot find module ‘…/missing-server.js’.
نشرت النسخة المكسورة رغم هذا، عمدًا، عشان أشوف وش Hostinger بتسجل.
| الحالة المعروضة | وش أثبتت | وش ما أثبتت |
|---|---|---|
| Build: completed | تم تثبيت الاعتمادات، وانتهت مرحلة البناء | إن التطبيق اشتغل فعلًا |
| Deployment: completed | Hostinger قبلت الإصدار وعالجته | إن كل المسارات سليمة |
سجلات البناء المتاحة عبر Connector أظهرت تثبيت الاعتمادات بنجاح وما أظهرت غير هذا. خطأ وقت التشغيل الخاص بالملف المفقود ما ظهر فيها. أي مطور يشوف شارة “completed” خضراء ما عنده سبب يشك إن الموقع معطل.
الاسترجاع سار بسلاسة. المساعد رجع package.json من النسخة الاحتياطية، وتحقق من التطبيق محليًا، وأعاد النشر، وتأكد من الإصلاح عن طريق استدعاء نقطة /api/health الحية مباشرة بدل ما يثق بحالة النشر وحدها.
هالنقطة رجعت استجابة تشغيلية، وكانت الدليل الوحيد في الاختبار كله اللي فعليًا أثبت إن التطبيق يشتغل.
هذا هو الاكتشاف الثاني الكبير. حالة “مكتمل” ما تعني إن التطبيق يشتغل، وسجلات Connector نفسها ما بتقول لك هالشي. الاسترجاع نفسه اشتغل بشكل جيد بعد ما عرفت إن فيه مشكلة أصلاً.
بعد فشل ما قدرت شارة الحالة تكشفه، كنت أبغى أعرف وين بعد ممكن ثقته تتقدم على قدرته الحقيقية. متغيرات البيئة كانت الاختبار التالي.
طلبت من المساعد يضيف متغير بيئة بسيط، ويتأكد إن الإعداد موجود كقدرة مخصصة في Connector قبل ما يلمس أي شيء، ويوقف إذا ما كان موجود.
بحث في الأدوات المتاحة، وما لقى أي إجراء مخصص لإدارة متغيرات البيئة في Node.js، وتوقف قبل ما يسوي أي تغييرات في الكود أو النشر.
هذا هو السلوك اللي كنت أبي أشوفه في باقي الاختبار. لما واجه حدًا حقيقيًا، وقف بدل ما يخمّن. ما أقدر أستنتج إن Hostinger Connector ما يدعم متغيرات البيئة في أي مكان ضمن أدواته، فقط إن ما ظهر أي إجراء من هذا النوع خلال هذا الاختبار.
| الاختبار | النتيجة | النتيجة الأساسية |
|---|---|---|
| نسخ المانيفست العامل احتياطيًا | نجح | تم إنشاء ملف الاسترجاع قبل التعديل |
| إدخال نقطة تشغيل مفقودة | نجح | تمت إضافة فشل مضبوط |
| إعادة إنتاج الفشل محليًا | نجح | MODULE_NOT_FOUND تم تأكيده |
| نشر النسخة المكسورة | نجح | Hostinger قبلت الأرشيف |
| حالة البناء تكشف الفشل | فشل | البناء لا يزال يظهر كمكتمل |
| سجلات البناء تكشف خطأ وقت التشغيل | فشل | خطأ الملف المفقود ما ظهر |
| استرجاع المانيفست العامل | نجح | تم استرجاع أمر التشغيل الأصلي |
| إعادة نشر النسخة العاملة | نجح | اكتمل النشر |
| التحقق من نقطة الصحة المباشرة | نجح | الـ API رجع حالة تشغيلية |
Hostinger Connector نفذ المهام المحددة والروتينية بشكل جيد:
كان أضعف لما المهمة احتاجت تفسير عبر بيانات حساب ناقصة:
هذا النمط مفيد لما تقرر كم استقلالية تعطي المساعد.
استخدم أوامر عامة للمراجعة منخفضة المخاطر. واستخدم أوامر دقيقة مع متطلبات تأكيد صريحة للعمليات اللي تغير البنية التحتية الحية.
مثال بدل:
| انشر هذا التطبيق على موقع Hostinger مؤقت جديد. |
استخدم:
| اعرض المواقع اللي يرجعها Hostinger حاليًا. حدّد موقع Node.js فقط إذا ظهر في النتيجة. اعرض لي النطاق الدقيق والدليل قبل النشر. لا تولّد أو تستنتج أو تعيد استخدام نطاق ما رجعته Hostinger. |
الأمر الثاني يضيّق مساحة الافتراض عند المساعد.
تشغيل Hostinger Connector كان سهل، بدون أي تعقيد إعداد معتاد، والتحكمات التفصيلية لفئات الأدوات أعطتني سلطة حقيقية على وش يقدر يلمسه الذكاء الاصطناعي.
بمجرد وجود موقع حقيقي بنطاق معروف، الأداة أدت الشغل بشكل جيد: تعديل سطر واحد من النص انتقل من التعديل إلى المباشر في حوالي دقيقة، مع سجلات بناء مفيدة تثبت ذلك.
المشكلة ظهرت قبل كذا، مو بعدين. لما واجه هدف جديد ما قدر يلقاه، اخترع نطاق وتصرف عليه قبل التحقق. وكمان صنّف نشرًا مكسورًا على أنه “completed” بينما التطبيق فعليًا كان متوقفًا، بدون ما يظهر خطأ التشغيل في سجلاته. ولا واحدة من هذي المشاكل تعني إن الأداة غير موثوقة للمواقع الموجودة أصلًا، لكن الاثنين معًا يعني إن الأهداف الجديدة وما بعد النشر تحتاج نظرة ثانية قبل تثق فيها.
Hostinger تبني دعمها حول الدردشة الحية والخدمة الذاتية بدل المكالمات الهاتفية، فركزت اختباري على المكان اللي معظم المستخدمين بيوصلون له فعلًا: المساعد الذكي داخل hPanel، التصعيد البشري اللي وراه، وقاعدة المعرفة اللي المطور بيرجع لها قبل ما يفتح محادثة أصلًا.
| القناة | التوفر | ملاحظات |
|---|---|---|
| الدردشة الحية (Kodee، الذكاء الاصطناعي) | 24/7 | تتوفر عبر “Ask AI” في hPanel |
| الدردشة الحية (بشري) | عبر التصعيد فقط | مو قائمة مباشرة، يتم تحويلها عبر Kodee |
| البريد الإلكتروني / التذكرة | support@hostinger.com | مذكور وقت رد يصل إلى يوم عمل واحد |
| الهاتف | غير متوفر | ما فيه خط هاتف عام للدعم |
| Knowledge Base | خدمة ذاتية | support.hostinger.com |
| الشرح والدروس وAcademy | خدمة ذاتية | أدلة خطوة بخطوة وقناة YouTube |
وبما إن الدردشة الحية هي القناة اللي Hostinger توجه المطورين لها لأي شيء عاجل، وهي القناة اللي غالبًا بتستخدمها وأنت تحل مشكلة نشر، اختبرت هالمسار مباشرة بدل ما أرسل تذكرة إيميل.
فتحت الدردشة الحية عبر “Ask AI” في hPanel وسألت Kodee سؤال له جواب ممكن يطلع غلط: هل حالة “completed” في بناء مشروع Node.js تعني إن التطبيق شغال فعلًا، ووين ألاقي دليل على العكس.
جواب Kodee الأول كان محدد وصحيح:
“Completed” غالبًا تعني إن مرحلة البناء انتهت بنجاح؛ لكنها ما تضمن إن التطبيق سليم بعد التشغيل. عشان تكتشف أمر تشغيل خاطئ أو انهيار وقت التشغيل، افحص سجلات التشغيل: في hPanel روح إلى Websites → Dashboard → Deployments لسجلات البناء، وبعدها افتح ملف stderr.log في مجلد nodejs لأخطاء البدء مثل Port already in use أو Module not found.
الجواب هذا لوحده كان بيحل نفس الغموض اللي اصطدمت فيه في اختبار الاسترجاع من الفشل قبل شوي.
لكن، برضه كنت أبغى أشوف إذا أقدر أوصل لموظف حقيقي، فقلت لـ Kodee إني أبغى أأكد هالشي مع موظف دعم مباشرة.
لكن الحصول على شخص كان أصعب مما توقعت. طلبت بشكل مباشر أتكلم مع وكيل حي، وجاني تحويل راجع إلى Kodee مرتين، وكل مرة كانت الصياغة إنه أسرع من الانتظار:
أفهم ليش تبي كذا. أقدر أساعدك هنا في التحقق من البناء، وأمر التشغيل، وسجلات التشغيل، وهذا غالبًا أسرع طريقة لتحديد المشكلة.
قبل ما نرسلها لاختصاصي. أقدر أحل المشكلة وأوفّر عليك الانتظار.
| المحاولة | طلبي | رد Kodee |
|---|---|---|
| 1 | “Can you connect me with a live agent?” | عرض يحلها بنفسه |
| 2 | “I’d still like to speak with a human agent. Please connect me.” | عرض مرة ثانية، وطلب النطاق وأمر التشغيل |
| 3 | Click “Go to human” / typed “I want to continue with a human” | تم التصعيد |
احتاج طلبين مباشرين وصريحين قبل Kodee يتوقف عن إرجاعي لنفسه. بالنسبة لسؤال أقدر أحله بنفسي، هالاحتكاك بسيط. لكن لشخص عنده انقطاع ويبي شخص، هذا مصدر إزعاج حقيقي.
اللي صار بعدين ما كان تحويلًا حيًا بمعنى تحويل مباشر داخل الدردشة. Kodee شرح النموذج الفعلي بوضوح:
I have shared your request with a specialist from our team who will personally review our chat and send me their answer, which I will then relay back to you here.
هذا مراجعة غير متزامنة، مو انتقال مباشر. Kodee يبقى الواجهة؛ وخبير بشري يراجع المحادثة في الخلفية، وKodee ينقل لك الرد بعدين. هالفارق مهم للقراء اللي يقررون إذا يصعّدون أو لا، لأن “وكيل بشري” هنا ما يعني إن شخص جديد ينضم إلى نافذة الدردشة مثل أغلب أنظمة المحادثة الحية.
دفعت نفس الخيط التقني أكثر وأنا أنتظر، وسألت Kodee يأكد مسار السجل بالضبط وهل stderr.log دائمًا يكون فيه بيانات. أعطى جوابًا جيدًا بنفسه، وذكر بشكل صحيح إن السجل ممكن يكون فاضي إذا التطبيق ما اشتغل بالكامل أو كتب خطأه في مكان ثاني.
وصول مراجعة الاختصاصي جاء خلال حوالي 3 دقائق، وموقع داخل الدردشة باسم Mayas، وكان أفضل من جواب Kodee بدل ما يكرر نفسه:
domains/[your-domain]/nodejs/stderr.log هو الموقع الصحيح. ما يكون دائمًا متولد أو مليان بيانات. ما بتشوف فيه مدخلات إلا لما يكتب التطبيق إلى stderr، مثل الاستثناءات غير المعالجة أو الرفضات غير المعالجة. إذا كان أمر التشغيل غلط والعملية خرجت بصمت، فقد يكون stderr.log فارغًا أو غير موجود.
Mayas أضاف أيضًا نقطتي تحقق بديلتين ما ذكرهم Kodee: فحص stdout.log لآخر مخرجات قبل الانهيار، والبحث عن غياب سطر تأكيد البدء كعلامة على أن التطبيق ما اشتغل أبدًا.
| التحقق | النتيجة |
|---|---|
| الجواب التقني الأول كان صحيح | نعم |
| التصعيد البشري متاح | نعم، لكن قاومه مرتين قبل ما يوافق |
| نموذج التصعيد | مراجعة غير متزامنة ونقل للرد، مو تحويل مباشر |
| اسم المراجع البشري | Mayas |
| زمن الاستجابة للمراجعة البشرية | حوالي 3 دقائق |
| جواب الإنسان أدق من جواب الذكاء الاصطناعي | نعم |
قاعدة معرفة Hostinger منظمة إلى فئات منتجات عامة: Getting Started، hPanel، Website Builder، Hostinger Horizons، Domains، DNS، Files Management، Email، MySQL Databases، Website، VPS، Agency Hosting Plans، Hostinger Reach، SSL Certificates، PHP، Profile Management، Billing، Affiliates and Referrals، Features، cPanel، وAbout Hostinger.
ولا وحدة من هالفئات مخصصة لـ Hostinger Connector. الطريقة الوحيدة اللي لقيت فيها المقال الصحيح كانت بالبحث المباشر عن “Hostinger Connector”، والنتيجة طلعت خمس مقالات، أغلبها له علاقة بعيدة فقط، بما فيها دليل لمكوّن تسويق بالعمولة ومقال عام عن استضافة Node.js.
المقال اللي يوثق إعداد الـ Connector فعلًا اسمه “How to Set Up Web Hosting MCP on Local IDEs”، ومصنف تحت Features → General Information.
البحث باسم المنتج التسويقي الحقيقي لقيه، لكن لو القارئ كان يتصفح الفئات أو يدور على “MCP” بدون ما يعرف تسمية Hostinger، ممكن يفوته بسهولة، وعدم تطابق الاسم التسويقي مع الاسم الموجود في التوثيق شيء لازم تعرفه قبل ما تدور.
المقال نفسه ممتاز بعد ما تلاقيه. كان محدث آخر مرة قبل ستة أيام من اختباري، ويغطي:
النقطة الأخيرة وافقت شيء واجهته مباشرة في الاختبار: Devin Desktop يكتشف تلقائيًا، بينما OpenAI Codex يحتاج الطريقة اليدوية. المقال صح في هالتفريق.
الرد التقني الأول من Kodee على سؤال صعب كان صحيحًا ومحددًا، وهذا مو شيء كل مساعد دعم بالذكاء الاصطناعي ينجح فيه. ومقال قاعدة المعرفة اللي يسنده حديث ومفصل بعد ما تلقاه، لكن الاسم التسويقي للمنتج واسم المقال التوثيقي ما يطابقان، فالبحث أدق من التصفح عبر الفئات.
النقطة الأضعف هي مسار التصعيد البشري. Kodee رجعني لنفسه مرتين قبل ما ينفذ طلب واضح بالتواصل مع شخص، وحتى وقتها “وكيل بشري” يعني مراجعة غير متزامنة وترد عبر نفس الدردشة، مو تحويل مباشر. وبمجرد ما راجعها شخص، كان الجواب أفضل من جواب Kodee نفسه، أدق ومعه خطوتين تشخيصيتين إضافيتين ما ذكرهم Kodee.
بالنسبة لمعظم الأسئلة، Kodee لوحده بيعطيك جوابًا صحيحًا بسرعة. لكن إذا أنت فعلًا تبي شخص يراجع الجواب، توقع إنك تطلب أكثر من مرة، وتوقع انتظار قصير لرد يُنقل لك بدل محادثة مباشرة حية.
إيه، إذا أنت مطور تستضيف عند Hostinger أصلًا وتبي النشر الروتيني يتم من داخل المحرر. الإعداد أخذ دقائق، وOAuth ألغى الحاجة لمفاتيح API، وبمجرد وجود موقع بنطاق معروف، Connector نشر تحديثًا مباشرًا خلال حوالي دقيقة مع سجلات تسانده. وردود Kodee نفسها كانت دقيقة لدرجة إنها حلت مشكلة تقنية حقيقية من أول مرة.
لكن التحدي هو الثقة، مو الراحة. لما واجه هدفًا جديدًا ما قدر يلقاه، اخترع Connector نطاقًا وتصرف عليه قبل التحقق.
وكمان صنّف نشرًا مكسورًا على أنه “completed” بينما التطبيق كان فعليًا متوقفًا، وما ظهر خطأ التشغيل في سجلاته. استخدمه لتسريع الشغل على مواقع موجودة أصلًا، وراجع أي شيء يسويه على هدف جديد، وافحص الموقع الحي بنفسك بعد أي نشر مهم.
| اسم الخطة | مساحة | وحدة المعالجة المركزية | ذاكرة عشوائية | نظام تشغيل | السعر | |
|---|---|---|---|---|---|---|
| Free Trial | غير محدود | - | ر.س.0.00 | التفاصيل | ||
| KVM 1 | 50 جيجابايت | 1 مراكز | 4 جيجابايت | ر.س.20.71 | التفاصيل | |
| KVM 2 | 100 جيجابايت | 2 مراكز | 8 جيجابايت | ر.س.28.66 | التفاصيل | |
| KVM 4 | 200 جيجابايت | 4 مراكز | 16 جيجابايت | ر.س.41.42 | التفاصيل | |
| KVM 8 | 400 جيجابايت | 8 مراكز | 32 جيجابايت | ر.س.82.87 | التفاصيل |
| Description | Expert Review |
|---|---|
| استضافة اقتصادية ذات أداء عالٍ وأدوات إدارة سه... | Read Shared Hosting Review |
| استضافة WordPress سريعة وآمنة مع تثبيت بنقرة واحدة ... | Read Wordpress Hosting Review |
| استضافة VPS قابلة للتوسع مع موارد مخصصة ووصول بص... | Read VPS Review |
| استضافة سحابية سريعة ومرنة مع وقت تشغيل ممتاز �... | Read Cloud Hosting Review |
| حلول استضافة آمنة وخاصة مع مواقع مراكز بيانات �... | Read Offshore Hosting Review |
| استضافة بريد إلكتروني آمنة وموثوقة مع ميزات من... | Read Email Hosting Review |
| استضافة بايثون موثوقة مع بيئات مرنة للمطورين. | Read Python Hosting Review |
| استضافة PHP عالية الأداء مع دعم كامل للمواقع وال... | Read PHP Hosting Review |
| استضافة Windows VPS موثوقة مع تحكم كامل وخيارات تخص�... | Read Windows VPS Review |
| استضافة سريعة ومرنة مُصممة لتطبيقات Node.js بأداء... | Read Nodejs Hosting Review |
| استضافة مُحسَّنة لمتاجر WooCommerce بسرعة عالية وتك... | Read Woocommerce Hosting Review |
| استضافة خوادم مخصصة لتجارب لعب Minecraft السلسة | Read Minecraft Server Hosting Review |
| حلول استضافة قابلة للتوسع مع ميزات متقدمة للوك... | Read Agency Hosting Review |
| استضافة سريعة وآمنة مُحسّنة لمواقع التجارة ال�... | Read Magento Hosting Review |
| استضافة عالية الأداء مبنية على لينكس لعمليات م... | Read Linux Hosting Review |
| حلول استضافة جافا قوية لتطبيقات ومشاريع الويب ... | Read Java Hosting Review |
| استضافة محسّنة لمواقع التجارة الإلكترونية بأد... | Read Ecommerce Hosting Review |
| استضافة Django موثوقة ذات سرعات عالية وبيئة آمنة. | Read Django Hosting Review |
| استضافة cPanel سهلة الاستخدام مع أداء قوي ودعم مو�... | Read Cpanel Hosting Review |
| استضافة قوية للشركات مع سرعات عالية, أمان, وقاب... | Read Business Hosting Review |
| Easy-to-use website builder with drag-and-drop tools and customizable templates. | Read Website Builder Review |
| Optimized hosting for Joomla sites with one-click installation and reliable performan... | Read Joomla Hosting Review |
| Powerful hosting with full PostgreSQL database support for data-driven applications. | Read PostgreSQL Hosting Review |
| Flexible hosting with MongoDB integration for scalable, modern web applications. | Read MongoDB Hosting Review |
| AI-powered website creation platform for building professional sites in minutes. | Read Horizons Review |
| Reliable hosting for n8n workflow automation with easy setup and management. | Read n8n Hosting Review |
| VPS hosting with Docker support for containerized application deployment and scaling. | Read Docker VPS Review |
| استضافة خادم SMTP مخصص لتسليم إيميلات موثوق وآمن... | Read SMTP Server Review |
| استضافة سريعة ومحسّنة ومصممة خصيصًا لتطبيقات R... | Read Ruby on Rails Review |
| استضافة غنية بالمزايا مع تكامل OpenClaw لبناء وإدا... | Read OpenClaw Review |
| استضافة سريعة وموثوقة مع سيرفرات مقرّها الممل�... | Read UK Hosting Review |
| استضافة اقتصادية وموثوقة مع سيرفرات موجودة في ... | Read India Review |
| Read Singapore Review | |
| Read Australia Review | |
| Read AI Agent Review | |
| Read Paperclip VPS Review | |
| Read Hermes Agent Review | |
| Read Web Apps Hosting Review | |
| Read Hostinger Reach Review | |
| Read MCP Review | |
| Read hpanel Review | |
| Read Odoo Review | |
| Read Laravel Review | |
| Read MERN VPS Review | |
| Read Ubuntu Review | |
| Read Drupal Hosting Review | |
| Read Express.js Review | |
| Read React Review | |
| Read Nextjs Review |
Hostinger Connector هو تكامل مبني على MCP يربط بيئات برمجة الذكاء الاصطناعي المدعومة بخدمات Hostinger.
يسمح لمساعد الذكاء الاصطناعي باستدعاء أدوات Hostinger المدعومة لمهام تتعلق بالمواقع الإلكترونية، والنشر، والنطاقات، وDNS، وقواعد البيانات، والبريد الإلكتروني، وموارد VPS.
Connector ليس منصة استضافة مستقلة ولا يحل محل hPanel. بل يوفّر طريقة أخرى للتعامل مع موارد Hostinger.
Hostinger حاليًا يذكر:
• VS Code
• Cursor
• Devin
• Antigravity
• Claude
• Codex
كما يذكر Hostinger أن عملاء MCP المتوافقين الآخرين قد يكونون مدعومين. قد يختلف الإعداد وسلوك الأدوات بين العملاء.
هوستنجر كونكتور مجاني للتثبيت ومشمول مع باقات هوستنجر. ما فيه اشتراك منفصل لـ Connector ضمن الأسعار الظاهرة في هالمراجعة. لا يزال لازم تدفع مقابل خدمة هوستنجر الأساسية، مثل استضافة المواقع، أو الاستضافة السحابية، أو VPS.
لا. يستخدم Hostinger Connector مصادقة OAuth. أثناء إعداد VS Code، سجلت الدخول عبر تدفق التفويض المستند إلى المتصفح من Hostinger. لم أنشئ مفتاح API، أو ألصق رمزًا في المحرر، أو أخزن بيانات الاعتماد في ملف إعدادات.
لا. تقول Hostinger إن استدعاءات Connector API تتعامل مع الحساب الحي. استخدم موقع اختبار أو نطاق أو VPS مخصص وقت ما تتعلم سير العمل. لا تفترض أن المطالبة محاكاة فقط لأنها صيغت عبر دردشة AI.
نعم. توثيق Hostinger يذكر الحدود الافتراضية التالية:
– 60 طلب في الدقيقة
– 1,000 طلب في الساعة
ويذكر Hostinger أيضًا أن تفاصيل تحديد المعدل تُرجَع في ترويسات الاستجابة.
يُفترض أن تكون هذي الحدود كافية للاستخدام التفاعلي العادي. تجنّب الطلبات المتكررة غير الضرورية، خصوصًا إذا كان رد سابق يحتوي بالفعل على المعلومات المطلوبة.
ايه. نشرت تطبيق Express.js على Hostinger وبعدها استخدمت Connector عشان أنشر نسخة محدثة من VS Code. Hostinger اكتشف Express، وخلّى Node.js 22.x هو المختار، واستخدم جذر المشروع كدليل الجذر أثناء النشر الأولي من hPanel. وبمجرد ما صار الموقع موجود كوجهة Node.js معروفة، نجح النشر المتكرر عبر Connector.
مو بالضرورة. في اختباري المخصص، أفاد Hostinger بإكمال البناء بعد ما غيّرت سكربت البدء عشان يشير إلى ملف JavaScript مفقود. سجلات البناء اللي تم استرجاعها أظهرت تثبيت التبعيات بنجاح لكنها ما كشفت فشل البدء وقت التشغيل. تأكد دائمًا من الموقع المباشر أو استدعِ نقطة فحص الصحة بعد النشر.
مو بالكامل. يقدر Connector يقلل عدد المرات اللي يحتاج فيها المطورون يطلعون من المحرر، خصوصًا في عمليات النشر الروتينية وفحص الحسابات. يظل hPanel مفيدًا لإدارة الحسابات بشكل مرئي، والإعداد الأولي، والتهيئة التفصيلية، والحالات اللي ما يقدر فيها الذكاء الاصطناعي يكتشف المورد المطلوب أو يعرضه بشكل صحيح.
أجب على بعض الأسئلة البسيطة وابحث عن الحل المثالي لك!
بدء البحث في الاستضافة
يقدم HostAdvice.com مراجعات وتقييمات احترافية بخدمات استضافة مواقع الانترنت مستقلة تماما عن أي جهة أو كيان آخر. تقييماتنا عادلة وأمينة وتطبق نفس معايير التقييم على كل المراجعات التي تتم.
يتم استلام تعويض نقدي من الشركات التي نقوم بتقييمها. تعويض الخدمات والمنتجات ليس له تأثير على توجه أو استنتاجات تقييماتنا. ولا تؤثر هذه التعويضات على ترتيبنا لشركات استضافة المواقع المحددة.
تغطي هذه التعويضات تكاليف الإنفاق على المراجعين، شراء الحسابات، والاختبار.
