لو بتشتغل JetEngine زيي، فأكيد الخبر وصلك: Crocoblock عملوا بيلدر خاص بيهم اسمه CrocoBuilder. مش إضافة على Elementor ولا على Bricks — بيلدر مستقل من الصفر. السؤال اللي هيجي في دماغك فوراً: “أنقل ولا أكمّل على Elementor؟” هنفصّص اللي قالوه في الإعلان الرسمي، ونشوف الجديد فعلاً إيه، ومين المفروض يهتم.
ما هو CrocoBuilder؟
CrocoBuilder هو منشئ صفحات (Page Builder) مستقل من Crocoblock، مبني بجوار منظومة JetPlugins لا فوق بنية بيلدر آخر. تصفه الشركة بأنه “AI-Native Dynamic Frontend Development Builder”، أي بيئة تطوير واجهات أمامية لها واجهة بصرية، صُممت من البداية للمحتوى الديناميكي والذكاء الاصطناعي معاً.
يقوم على ثلاث ركائز:
- بنية Atomic DOM: العنصر الذي تضعه في المحرر هو نفسه العنصر الذي يظهر في HTML، بلا أغلفة (Wrappers) ولا أسماء فئات مولّدة.
- نظام تصميم بـ CSS حقيقي: الفئات والمتغيرات والأنماط المشتركة تُكتب في ملف الأنماط نفسه الذي يستخدمه موقعك، وتعمل داخل البيلدر وخارجه.
- طبقة ذكاء اصطناعي: مساعد AI وتكامل MCP يقرآن نظام التصميم الحالي (الخطوط والألوان وأسماء الفئات) قبل توليد أي مكوّن.
ملاحظة: الإعلان الرسمي واضح في نقطة مهمة — CrocoBuilder ليس “بديل Elementor للجميع”. هو موجّه للمطورين والوكالات التي تبني مواقع ديناميكية معقدة. لو موقعك محتوى ثابت، الشركة نفسها بتقولك إن بيلدر أخف هيكون أنسب.
لمن صُنع CrocoBuilder؟
بحسب Crocoblock، الجمهور المستهدف ثلاث فئات:
- مطورو المواقع الديناميكية حيث نظام التصميم يحتاج صيانة، والبيلدر جزء من منظومة تقنية أكبر.
- الوكالات التي تبني النوع نفسه من المواقع تكراراً: أدلة (Directories)، منصات عضوية، أنظمة حجز، أسواق متعددة البائعين — وتحتاج مكوّنات قابلة لإعادة الاستخدام تقنياً لا مجرد قوالب نسخ ولصق.
- المستقلون على مشروع واحد معقد: يضبطون المتغيرات والفئات العامة مرة في بداية المشروع فيبقى البناء متسقاً.
CrocoBuilder
أهم 6 أفكار في CrocoBuilder
- بنية
Atomic DOM
عنصر واحد في المحرر = عنصر واحد في HTML. لا أغلفة ولا فئات مولّدة.
- تصميم
نظام تصميم بـ CSS حقيقي
فئات ومتغيرات وأنماط مشتركة بأسمائك، تعمل داخل البيلدر وخارجه، وتُصدَّر كـ CSS أو JSON.
- ديناميكي
Query Loop + Query Builder
معادل Listing Grid داخل البيلدر، بنفس منطق JetEngine الذي تعرفه.
- AI
مساعد يقرأ نظامك أولاً
يقرأ الخطوط والألوان والفئات قبل التوليد، فيخرج المكوّن بهوية مشروعك.
- فريق
GitHub Versioning
Pull Requests وسجل Commits وتراجع للصفحات والقوالب من النواة.
- وكلاء
تكامل MCP
وكيل AI مثل Claude ينشئ الصفحات والمكونات والاستعلامات عبر API البيلدر.
البنية: عناصر ذرّية بدل الودجت الثقيلة
معظم البيلدرز تتعامل مع الـ DOM كنتيجة جانبية: ترتّب العناصر بصرياً، والبيلدر يولّد الكود مع أغلفة يحتاجها داخلياً وتظهر في HTML موقعك شئت أم أبيت.
يبدأ CrocoBuilder بمجموعة عناصر أساسية صغيرة عمداً: Heading وText وImage وLink وSVG وNav Menu. كل منها عنصر HTML واحد؛ العنوان هو <h1>–<h6> مباشرة، والـ SVG وسم <svg> مضمّن مع مُعقِّم مدمج ومحرر للكود.
عنصر Link يستحق التوقف: في أغلب البيلدرز، زر برابط وأيقونة يحتاج ودجت خاصاً بخيارات ثابتة. هنا Link حاوية — ضع بداخلها نصاً أو SVG أو صورة أو بطاقة كاملة فيصبح كل ذلك رابطاً واحداً.
عنصرا التخطيط Block وGrid على النهج نفسه: تختار وسم HTML الدلالي (Section، Main، Article، Header، UL…) ويظهر في الـ DOM كعنصر واحد بالضبط.
في Elementor: حاوية Elementor (Container) بتطلع
<div>واحد تقريباً مع فئاتe-con، والودجت بتضيف طبقة أو اتنين. الفرق مش كارثي في المواقع العادية، لكن في صفحات الـ Listing الكبيرة بيتجمع. لو بتراجع HTML موقعك في DevTools وبتتضايق من العمق، ده بالظبط اللي CrocoBuilder بيعالجه.
Collections و Query Loop: المحتوى الديناميكي
- Collection: تبني المحتوى مرة واحدة ثم تبدّل سلوكه بين Tabs وAccordion وSlider وColumns من قائمة منسدلة. لو العميل غيّر رأيه من تبويبات إلى سلايدر في منتصف المشروع، فهو خيار واحد لا إعادة بناء.
- Query Loop: المعادل الديناميكي لـ Listing Grid في JetEngine داخل البيلدر. يستعلم عن أنواع المحتوى ويطبق الفلاتر ويعرض النتائج بقالب تكرار تبنيه بصرياً. منشئ الاستعلامات (Query Builder) متاح من شريط الأدوات العلوي بالمنطق نفسه الذي تعرفه في JetEngine.
في JetEngine + Elementor: ده نفس الشغل اللي بنعمله بـ Listing Grid + Query Builder. لو الـ Query Builder بتاع JetEngine في دمك، منحنى التعلم هنا شبه صفر — الشركة بتقول صراحة إن المنطق والواجهة متطابقان. احصل على JetEngine
نظام التصميم: أكثر من “Global Kit”
هذه أقوى نقطة في الإعلان. أغلب البيلدرز تمنحك مكاناً لتحديد خط العناوين واللون الأساسي وتسميه “Global Kit”. Crocoblock تسميه بحق “إعداد قالب لا نظام تصميم”. أدوات CrocoBuilder، كلها من رابط Tools في الشريط العلوي:
| الأداة | ما تفعله |
|---|---|
| CSS Classes Manager | تحفظ الفئة بالاسم الذي أعطيته أنت (.card-header مثلاً) وتستخدمها في البيلدر أو في قالب مخصص أو في ملف CSS مكتوب يدوياً — الفئة نفسها في كل مكان |
| Common Styles | محددات مسمّاة (.button-primary، .card) بأنماط تُعرَّف مرة ويرثها أي عنصر بإضافة الفئة |
| CSS Variables | --color-primary و--font-heading و--radius-card متاحة في أدوات البيلدر وفي CSS الخام وفي أي ملف خارجي — هي متغيرات CSS فعلية لا تجريد فوقها |
| Import/Export | استيراد ملف Bootstrap أو إطار CSS داخلي ليصبح متاحاً في المدير، وتصدير النظام كله كملف CSS أو JSON لإعادة استخدامه بين المشاريع |
| Component Builder | مكوّن بخصائص قابلة للتحرير في سياقه: تبني “Pricing Card” وتسلّمها للعميل فيعدّل السعر والمزايا دون لمس البنية |
التفاعلات والحالات والإظهار الشرطي
- Interactions على نموذج مُشغِّل/إجراء: المُشغِّلات (Mouse Enter/Leave، Page Load، Enter/Leave Viewport، Click) والإجراءات (إظهار/إخفاء عنصر، تعيين/حذف Attribute). أنماط كانت تحتاج ودجت مخصصاً أو JavaScript تُبنى الآن من عناصر عامة.
- State Manager: حالات Hover وActive وFocus وFocus Visible وBefore لكل عنصر مع إمكانية تعريف حالات مخصصة، من لوحة الأنماط نفسها.
- Display Conditions: نظام Dynamic Visibility من JetEngine داخل البيلدر — إظهار أو إخفاء أي عنصر حسب دور المستخدم أو قيمة حقل أو معامل في الرابط أو نوع الجهاز.
- Mobile Breakpoint Manager: تعرّف نقاط التوقف بنفسك بالاسم والعرض بدل مجموعة ثابتة.
المساعد الذكي وتكامل MCP
هنا تُثمر القرارات المعمارية. تكتب “أنشئ قسم Hero لعيادة أسنان” فيقرأ AI Assistant متغيرات CSS وأسماء الفئات والألوان والخطوط في مشروعك ويولّد تخطيطاً يلتزم بها، بعناصر قابلة للتحرير لا كتلة كود تلصقها وتصونها منفصلة.
تكامل MCP يربط CrocoBuilder بأي وكيل ذكاء اصطناعي متوافق — تكتب المهمة في Claude مثلاً فينشئ الصفحات والمكونات والاستعلامات والأنماط مباشرة على الموقع عبر API البيلدر.
بصراحة: كل بيلدر دلوقتي بيحط كلمة AI في اسمه. الفرق الحقيقي اللي Crocoblock بتدّعيه إن المساعد بيقرأ نظام التصميم قبل ما يولّد، فالناتج بيطلع بألوانك وخطوطك مش بألوان عشوائية. ده ادعاء منطقي معمارياً، لكن مش هقدر أحكم على جودته قبل ما أجربه على مشروع حقيقي — وده هيكون فيديو منفصل.
Theme Builder و GitHub Versioning
- Theme Builder بعرض شجري للموقع كله (الهيدر والفوتر وقوالب الأرشيف والمقال المفرد و404 والبحث) من لوحة واحدة، وهو مكافئ JetThemeCore بشروط العرض نفسها.
- GitHub-based Versioning يزامن محتوى البيلدر مع مستودع GitHub: Pull Requests وسجل Commits وتراجع للصفحات والقوالب بنفس سير عمل الفريق مع ملفات القالب والإضافات.
تنبيه: ميزة GitHub دي لو شغّالة كما هو موصوف، فهي حاجة مفيش بيلدر ووردبريس تاني بيقدمها من النواة. بالنسبة للوكالات اللي بتشتغل بفريق، دي وحدها ممكن تكون سبب التجربة.
CrocoBuilder أم Elementor Pro + JetEngine؟
مقارنة أولية — قبل الاختبار العملي
CrocoBuilder مقابل Elementor Pro + JetEngine
من واقع الإعلان الرسمي وخبرتنا مع Elementor. RTL والأداء بانتظار اختبار حقيقي.
| المعيار | CrocoBuilder | Elementor Pro + JetEngine |
|---|---|---|
| نظافة HTML الناتج | عنصر = عنصر | أغلفة إضافية |
| نظام تصميم (فئات/متغيرات) | CSS حقيقي | Global Kit فقط |
| المحتوى الديناميكي | Query Loop | Listing Grid |
| إظهار شرطي وحالات | مدمج | Dynamic Visibility |
| GitHub Versioning | من النواة | غير متوفر |
| تكامل MCP للوكلاء | مدمج | محدود |
| سهولة للمبتدئين | منحنى أعلى | أسهل |
| قوالب وإضافات جاهزة | جديد — قليلة | آلاف |
| دعم RTL موثّق | غير مذكور | مدمج |
الخلاصة الصريحة: لو موقعك يعمل على Elementor Pro + JetEngine ويؤدي عمله، لا يوجد في هذا الإعلان ما يستدعي نقلاً عاجلاً. الفرق يظهر في ثلاث حالات:
- تبني مواقع ديناميكية كبيرة ويؤلمك حجم الـ DOM في Elementor.
- تشتغل بفريق وتحتاج نظام تصميم موحّداً و Versioning عبر GitHub.
- تريد بناء الواجهات عبر وكيل AI بـ MCP، وهو ما لا يوفره Elementor بالشكل نفسه.
نقطة يجب التحقق منها قبل أي قرار للسوق العربي: دعم RTL. الإعلان لا يذكر الاتجاه من اليمين لليسار إطلاقاً. بما أن الأنماط CSS خام والعناصر ذرّية، نظرياً التحكم كامل بيدك — لكن هذا يعني أيضاً أن العبء عليك لا على البيلدر. سأختبره وأنشر النتيجة.
الأسئلة الشائعة
س: هل أحتاج JetEngine لاستخدام CrocoBuilder؟
ج: لا، يعمل كبيلدر مستقل. لكنه مصمم للعمل مع JetEngine بتكامل أصلي بلا طبقة وسيطة، وهو الأقوى في هذا السيناريو.
س: هل CrocoBuilder بديل عن Elementor؟
ج: Crocoblock نفسها تقول إنه ليس بديلاً لعموم مستخدمي Elementor، بل بيلدر للمطورين والوكالات في المواقع الديناميكية. JetPlugins ما زالت تدعم Elementor وBricks وGutenberg وDivi.
س: هل يناسب المبتدئين؟
ج: لا. مستوى التحكم (DOM ذرّي، مزامنة CSS الخام، نقاط توقف مخصصة، خصائص المكونات) ميزة للتقنيين ومنحنى تعلم أعلى لغيرهم.
س: هل يدعم CrocoBuilder اللغة العربية و RTL؟
ج: الإعلان الرسمي لا يذكر RTL. لأن الأنماط CSS حقيقية، التحكم ممكن يدوياً، لكن لا يوجد تأكيد رسمي لدعم مدمج. انتظر اختباراً عملياً قبل الاعتماد عليه في موقع عربي.
س: ما الفرق بين Query Loop و Listing Grid؟
ج: الوظيفة واحدة — عرض نتائج استعلام بقالب تكرار. Query Loop هو النسخة المدمجة في CrocoBuilder، وListing Grid هو ودجت JetEngine داخل Elementor أو Bricks. Query Builder مشترك بينهما.
الخلاصة
CrocoBuilder رهان معماري لا مجرد بيلدر بصري جديد: DOM ذرّي، نظام تصميم يعيش في CSS حقيقي، ذكاء اصطناعي يعمل داخل مشروعك، وGitHub في النواة. لمن استثمر في JetPlugins هو القطعة الناقصة؛ لمن يبني مواقع محتوى عادية بـ Elementor فالأمر لا يعنيه الآن.
هجرّبه على موقع عربي كامل وأشوف الـ RTL والأداء بعيني — لو عندك مشروع JetEngine وحابب نقيّم سوا هل ينفعله ولا لأ، احجز جلسة ونبص عليه.
المصدر الأصلي: Meet CrocoBuilder, Crocoblock’s AI-Native WordPress Page Builder
