الدليل: هندسة ميدياويكي
منذ البداية، تم تطوير ميدياويكي خصيصًا ليكون برنامج ويكيبيديا. لقد عمل المطورون على تسهيل إعادة الاستخدام من قبل مستخدمي الطرف الثالث، لكن تأثير ويكيبيديا وتحيزها ساهم في تشكيل بنية ميدياويكي عبر تاريخها.
تعد ويكيبيديا واحدة من أفضل عشرة مواقع إلكترونية في العالم، حيث تستقبل حاليًا حوالي 400 مليون زائر فريد شهريًا. تحصل على أكثر من 100.000 نقرة في الثانية. ويكيبيديا غير مدعومة تجاريًا بالإعلانات؛ يتم دعمه بالكامل من قبل منظمة غير ربحية، وهي مؤسسة ويكيميديا، والتي تعتمد على التبرعات كنموذج تمويل أساسي لها. وهذا يعني أن ميدياويكي لا يجب أن تدير موقعًا من أفضل عشرة مواقع فحسب، بل يجب أن تفعل ذلك أيضًا بميزانية صغيرة. لتلبية هذه المطالب، تمتلك ميديا ويكي تحيزًا كبيرًا نحو الأداء والخزن الآلي والتحسين. يتم إعادة تشغيل الميزات الثمينة التي لا يمكن تمكينها في ويكيبيديا أو تعطيلها من خلال متغير التكوين؛ هناك توازن لا نهاية له بين الأداء والميزات.
لا يقتصر تأثير ويكيبيديا على بنية ميدياويكي على الأداء. على عكس أنظمة إدارة المحتوى العامة، تمت كتابة ميدياويكي في الأصل لغرض محدد للغاية: دعم المجتمع الذي يقوم بإنشاء وتنظيم المعرفة القابلة لإعادة الاستخدام بحرية على منصة مفتوحة. هذا يعني، على سبيل المثال، أن ميديا ويكي لا تشمل الميزات العادية الموجودة في CMSs الشركات (مثل سير العمل السهل للنشر أو ACLs) ، ولكن تقدم مجموعة متنوعة من الأدوات للتعامل مع الرسائل غير المرغوب فيها والفوضى.
لذا، منذ البداية، أثر احتياجات وفعال مجتمع متطور باستمرار من مشاركين ويكيبيديا على تطوير مديا ويكي، وعكس ذلك. لقد كانت بنية ميدياويكي مدفوعة عدة مرات بمبادرات بدأها أو طلبها المجتمع، مثل إنشاء ويكيميديا كومنز، أو ميزة المراجعات ذات العلامات. قام المطورون بتغييرات معمارية كبيرة، مثل معالج ميدياويكي 1.12 المسبق، لأن الطريقة التي استخدم بها ميدياويكي من قبل ويكيبيدييين جعلها ضرورية.
اكتسب ميدياويكي أيضًا قاعدة مستخدمين خارجية قوية من خلال كونه برنامجًا مفتوح المصدر منذ البداية. يعلم المستخدمون الخارجيون أنه طالما أن موقع ويب رفيع المستوى مثل ويكيبيديا يستخدم ميدياويكي، فسيتم صيانة البرنامج وتحسينه. كانت ميديا ويكي تركز حقا على مواقع ويكيميديا، ولكن تم بذل جهود لجعلها أكثر عمومية وتلبية احتياجات هؤلاء المستخدمين من الطرف الثالث بشكل أفضل. على سبيل المثال، يُستخدم ميديا ويكي مع مرسومة تحميل على شبكة الإنترنت ممتازة، مما يجعل عملية التثبيت أقل ألمًا بكثير من عندما كان يتعين القيام بكل شيء عبر خط الأوامر، ويحتوي البرنامج على مسارات مُشفرة صلبة لويكيبيديا.
ومع ذلك، يظل ميدياويكي برنامج ويكيبيديا، وهذا يظهر عبر تاريخه وهندسته المعمارية.
قاعدة مديا ويكي و ممارساتها
| طبقة المستخدم | [w:مصفح الويب في المصفح اليوب] | ||
|---|---|---|---|
| طبقة الشبكة | Varnish | ||
| Apache webserver | |||
| طبقة منطقية | [Special:MyLanguage/Manual:Code ميدياويكي PHP البرمجية] | ||
| PHP | |||
| طبقة البيانات | File system | MySQL Database (program and content) | Caching system |
PHP
تم اختيار PHP كإطار عمل لبرنامج "المرحلة الثانية" في ويكيبيديا في عام 2001؛ لقد تطور برنامج ميدياويكي بشكل عضوي منذ ذلك الحين، ولا يزال يتطور. معظم مطوري ميديا ويكي متطوعون يساهمون في وقتهم الفراغي، وكان عدد قليل جدا في السنوات الأولى. قد تبدو بعض قرارات تصميم البرمجيات أو الإغفالات خاطئة عند الرجوع إلى الماضي، ولكن من الصعب انتقاد المؤسسين لعدم تنفيذ بعض التجريدات التي ثبت الآن أنها بالغة الأهمية، عندما كانت قاعدة التعليمات البرمجية الأولية صغيرة جدًا، والوقت المستغرق لتطويرها قصير جدًا .
على سبيل المثال، تستخدم ميديا ويكي أسماء الفصول غير المحددة، والتي يمكن أن تسبب الصراعات عندما يضيف مطوري PHP core و PECL فصول جديدة.
ونتيجة لذلك، كان يجب إعادة تسمية فئة MediaWiki Namespace إلى MWNamespace لتتوافق مع PHP 5.3.
إن استخدام البادئة باستمرار لجميع الفئات (على سبيل المثال "MW") كان من شأنه أن يسهل تضمين ميدياويكي داخل تطبيق أو مكتبة أخرى.
لا يُمكن أن يكون الاعتماد على PHP أفضل خيار للأداء، لأنه لم يستفيد من التحسينات التي شهدتها بعض اللغات الديناميكية الأخرى. كان استخدام جاوا سيكون أفضل بكثير للأداء، وتبسيط تنفيذ مقياس للمهام الصيانة الخلفية. من ناحية أخرى، PHP تحظى بشعبية كبيرة، مما يسهل توظيف مطورين جدد.
حتى لو كانت مديا ويكي لا تزال تحتوي على رمز "شنيع" ، تم إحداث تحسينات كبيرة على مر السنين ، وتم تقديم عناصر معمارية جديدة إلى مديا ويكي طوال تاريخها.
They include the Parser, SpecialPage, and Database classes, the Image class and the FileRepo class hierarchy, ResourceLoader, and the Action hierarchy.
بدأت ميديا ويكي بدون أي من هذه الأشياء، ولكنها تدعم جميعها الميزات التي كانت موجودة منذ البداية.
يهتم العديد من المطورين في المقام الأول بتطوير الميزات، وغالبًا ما يتم تجاهل الهندسة المعمارية، ثم اللحاق بها لاحقًا، حيث تصبح تكلفة العمل ضمن بنية غير كافية واضحة.
نظرًا لأن ميدياويكي هي منصة للمواقع رفيعة المستوى مثل ويكيبيديا، فقد قام المطورون الأساسيون ومراجعو التعليمات البرمجية بفرض قواعد أمنية صارمة.
لتسهيل كتابة تعليمات برمجية آمنة، يوفر ميديا ويكي للمطورين أغلفة حول مخرجات HTML واستعلامات قاعدة البيانات للتعامل مع الهروب.
لتنظيف مدخلات المستخدم، يستخدم أحد فئة WebRequest، التي تحلل البيانات التي تم تمريرها في عنوان URL أو عبر نموذج POSTed.
إنه يزيل "مقاطع الاقتباس السحري" ، ويزيل أحرف الإدخال غير المشروعة ويطبق تسلسلات يونيكود.
Cross-site request forgery (CSRF) is avoided by using tokens, and cross-site scripting (XSS) by validating inputs and escaping outputs, usually with PHP's htmlspecialchars() function.
توفر ميديا ويكي أيضًا (و تستخدم) مضغوطة HTML مع فئة Sanitizer ، و وظائف قاعدة البيانات التي تمنع حقن SQL.
تكوين
تقدم ميديا ويكي مئات إعدادات التكوين، المخزنة في المتغيرات العالمية في PHP.
Their default value is set in DefaultSettings.php, and the system administrator can override them by editing LocalSettings.php.
اعتادت ميدياويكي على الاعتماد على المتغيرات العالمية بشكل كبير ، بما في ذلك لتكوين ومعالجة السياق.
يسبب الجوالات آثار أمنية خطيرة مع وظيفة PHP register_globals (التي لم تكن ميديا ويكي بحاجة إليها منذ الإصدار 1.2).
هذا النظام يحد أيضا من الاستخراجات المحتملة للتكوين، ويجعل من الصعب تحسين عملية البدء.
علاوة على ذلك، تتم مشاركة مساحة اسم التكوين مع المتغيرات المستخدمة للتسجيل وسياق الكائن، مما يؤدي إلى تعارضات محتملة.
من وجهة نظر المستخدم، جعلت متغيرات التكوين العالمية أيضًا مديا ويكي صعبة التكوين والحفاظ عليها.
لقد كان تطوير ميدياويكي عبارة عن قصة نقل السياق ببطء من المتغيرات العالمية إلى الكائنات.
يسمح تخزين سياق المعالجة في متغيرات أعضاء الكائن بإعادة استخدام هذه الكائنات بطريقة أكثر مرونة.
قاعدة بيانات وتخزين النص
كانت ميديا ويكي تستخدم قاعدة بيانات إعلامية متراجعة منذ البرمجيات المرحلة الثانية. نظام إدارة قواعد البيانات الافتراضي (والأفضل دعمًا) لـ ميدياويكي هو MySQL، وهو النظام الذي تستخدمه جميع مواقع ويكيميديا، لكن أنظمة إدارة قواعد البيانات الأخرى (مثل PostgreSQL وOracle وSQLite) لديها تطبيقات مدعومة من المجتمع. يمكن لمسؤول النظام اختيار نظام إدارة قواعد البيانات (DBMS) أثناء تثبيت ميدياويكي، ويوفر MediaWiki كلا من تجريد قاعدة البيانات وطبقة تجريد الاستعلام التي تبسط الوصول إلى قاعدة البيانات للمطورين.
يحتوي التخطيط الحالي على عشرات الجداول.
العديد منها يتعلق بمحتوى الويكي (على سبيل المثال page، revision، category، و recentchanges).
الجداول الأخرى تشمل بيانات عن المستخدمين (user, user_groups) ، الملفات الإعلامية (image, filearchive) ، التخزين الآلي (objectcache, l10n_cache, querycache) والأدوات الداخلية (job لصف العمل) ، بين أمور أخرى.
يتم استخدام الفهارس والجداول التلخيصية على نطاق واسع في ميدياويكي، نظرًا لأن استعلامات SQL التي تفحص عددًا كبيرًا من الصفوف يمكن أن تكون مكلفة للغاية، خاصة على مواقع ويكيميديا.
عادةً ما يتم تثبيط الاستعلامات غير المفهرسة.
مرت قاعدة البيانات بالعشرات من تغييرات المخطط على مر السنين، أبرزها هو فصل تخزين النص وتتبع المراجعة في ميدياويكي 1.5.
في النموذج 1.4، تم تخزين المحتوى في جدولين مهمين، cur (الذي يحتوي على النص والبيانات المعدلة الحالية للصفحة) و old (الذي يتضمن مراجعات سابقة) ؛ تم الحفاظ على الصفحات الممسوحة في archive.
عندما تم إجراء تعديل، تم نسخ المراجعة الحالية السابقة إلى الجدول old، وتم حفظ التعديل الجديد في cur.
عند إعادة تسمية الصفحة، كان لا بد من تحديث عنوان الصفحة في البيانات التعريفية لجميع مراجعات old، وهو ما قد يستغرق وقتًا طويلاً.
عندما يتم حذف صفحة ما، يجب نسخ إدخالاتها في الجدولين cur وold إلى الجدول archive قبل حذفها؛ وهذا يعني نقل نص جميع المراجعات، وهو ما قد يكون كبيرًا جدًا وبالتالي يستغرق وقتًا.
في النموذج 1.5، تم تقسيم بيانات تعريف المراجعة ونص المراجعة: تم استبدال الجدولين cur وold بـ page (بيانات تعريف الصفحات)، وrevision (بيانات تعريف جميع المراجعات، القديمة أو الحالية) وtext (نص جميع المراجعات، القديمة أو الحالية أو تم الحذف).
الآن، عند إجراء التحرير، لا يلزم نسخ بيانات تعريف المراجعة حول الجداول: يكفي إدراج إدخال جديد وتحديث المؤشر page_latest.
بالإضافة إلى ذلك، لم تعد بيانات تعريف المراجعة تتضمن عنوان الصفحة بعد الآن، بل معرفها فقط: وهذا يلغي الحاجة إلى إعادة تسمية جميع المراجعات عند إعادة تسمية الصفحة.
يقوم الجدول revision بتخزين البيانات الوصفية لكل مراجعة، ولكن ليس النص الخاص بها؛ بدلاً من ذلك، تحتوي على معرف نصي يشير إلى الجدول text، الذي يحتوي على النص الفعلي.
عند حذف صفحة، يظل نص جميع مراجعات الصفحة موجودًا ولا يلزم نقله إلى جدول آخر.
يتكون الجدول text من تعيين المعرفات إلى النقط النصية؛ يشير حقل العلامات إلى ما إذا كان النص الثنائي الكبير مضغوطًا بواسطة gzipp (لتوفير المساحة) أو إذا كان النص الثنائي الكبير مجرد مؤشر إلى وحدة تخزين نص خارجية.
تستخدم مواقع ويكيميديا مجموعة تخزين خارجية مدعومة من MySQL مع نقاط من بضع عشرات من المراجعات.
يتم تخزين المراجعة الأولى للنقطة بالكامل، ويتم تخزين المراجعات التالية لنفس الصفحة على هيئة اختلافات مقارنة بالمراجعة السابقة؛ ثم يتم ضغط النقط بواسطة gzipped.
ونظرًا لأنه يتم تجميع المراجعات في كل صفحة، فإنها تميل إلى أن تكون متشابهة، وبالتالي تكون الاختلافات صغيرة نسبيًا ويعمل gzip بشكل جيد.
نسبة الضغط التي تم تحقيقها على مواقع ويكيميديا تقترب من 98٪.
ويكي ويكي أيضاً دعم مدمج لتحقيق التوازن الحملي، و أضاف في وقت مبكر من عام 2004 في ميديا ويكي 1.2 (عندما حصلت ويكي ويكي على خادمها الثاني - وهو أمر كبير في ذلك الوقت). ميزان الحمل (رمز PHP من ميديا ويكي الذي يقرر إلى أي خادم للاتصال) هو الآن جزء حاسم من بنية تحتية ويكيميديا، والذي يفسر تأثيره على بعض قرارات الخوارزمية في الرمز. يمكن لمسؤول النظام أن يحدد في إعدادات ميدياويكي أن هناك خادم قاعدة بيانات رئيسي واحد، وأي عدد من خوادم قاعدة البيانات التابعة؛ يمكن تعيين وزن لكل خادم. سيقوم موازن التحميل بإرسال جميع عمليات الكتابة إلى المعلم، وسيقوم بموازنة القراءات وفقًا للأوزان. كما أنه يتتبع تأخر النسخ المتماثل لكل عبد. إذا تجاوزت فترة تأخير نسخ العبد 30 ثانية، فلن تتلقى أي استفسارات قراءة للسماح لها بالتحقيق؛ إذا تأخرت جميع العبيد أكثر من 30 ثانية، فسوف تضع ميديا ويكي نفسها تلقائياً في وضع القراءة فقط.
يضمن "حامي التسلسل الزمني" الخاص بميدياويكي ألا يتسبب تأخر النسخ مطلقًا في رؤية المستخدم لصفحة تدعي أن الإجراء الذي قام به للتو لم يحدث بعد. يتم ذلك عن طريق تخزين منصب السيد في جلسة المستخدم إذا أدى الطلب الذي قدمه إلى استعلام كتابة. في المرة التالية التي يقدم فيها المستخدم طلب قراءة، يقرأ موازن التحميل هذا الموضع من الجلسة، ويحاول تحديد تابع وصل إلى موضع النسخ المتماثل هذا لخدمة الطلب. إذا لم يكن هناك شيء متاح، فسوف ينتظر حتى يتوفر واحد. قد يبدو الأمر للمستخدمين الآخرين كما لو أن الإجراء لم يحدث بعد، لكن التسلسل الزمني يظل ثابتًا لكل مستخدم.
الطلبات والتخزين المؤقت والتسليم
سير عمل تنفيذ طلب الويب
index.php هو نقطة الوصول الرئيسية لميدياويكي، ويتعامل مع معظم الطلبات التي تتم معالجتها بواسطة خوادم التطبيقات (أي الطلبات التي لم يتم تقديمها بواسطة البنية التحتية التخزين المؤقت؛ انظر أدناه).
يقوم الكود الذي تم تنفيذه من index.php بإجراء فحوصات أمنية، وتحميل إعدادات التكوين الافتراضية من includes/DefaultSettings.php، وتخمين التكوين باستخدام includes/Setup.php، ثم تطبيق إعدادات الموقع الموجودة في LocalSettings.php.
ثم يقوم بعد ذلك بإنشاء كائن MediaWiki ($mediawiki)، وإنشاء كائن Title ($wgTitle) اعتمادًا على العنوان ومعلمات الإجراء من الطلب.
يمكن أن يتخذ index.php مجموعة متنوعة من معلمات الإجراء في طلب URL؛ الإجراء الافتراضي هو view، والذي يوضح العرض العادي لمحتوى المقالة.
على سبيل المثال، يعرض الطلب https://en.wikipedia.org/w/index.php?title=Apple&action=view محتوى مقالة "Apple" على ويكيبيديا الإنجليزية[1].
تتضمن الإجراءات المتكررة الأخرى edit (لفتح مقال لتحريره)، وsubmit (لمعاينة مقال أو حفظه)، و3$ (لإظهار سجل المقالة)، و4$ (لإضافة مقال إلى قائمة مراقبة المستخدم).
تشمل الإجراءات الإدارية delete (لتحذيف مقالة) و protect (لتحظر تحرير مقالة).
ثم يتم الاتصال بـ MediaWiki::performRequest() لتعامل معظم طلبات URL.
فهو يتحقق من العناوين السيئة، وقيود القراءة، وعمليات إعادة التوجيه المحلية بين الويكي، وحلقات إعادة التوجيه، ويحدد ما إذا كان الطلب مخصصًا لصفحة عادية أو خاصة.
Normal page requests are handed over to MediaWiki::initializeArticle(), to create an Article object for the page ($wgArticle), and then to MediaWiki::performAction(), which handles "standard" actions.
بمجرد اكتمال الإجراء، يقوم MediaWiki::doPostOutputShutdown() بتحقيق النهاية في الطلب من خلال إجراء معاملات DB، وإخراج HTML وإطلاق التحديثات المؤجلة من خلال صف العمل.
MediaWiki::restInPeace() ينفذ التحديثات المؤجلة ويغلق المهمة بأمان.
إذا كانت الصفحة المطلوبة عبارة عن صفحة خاصة (أي ليست صفحة محتوى ويكي عادية، ولكنها صفحة خاصة متعلقة بالبرمجيات مثل Statistics)، فسيتم استدعاء SpecialPageFactory::executePath بدلاً من initializeArticle()؛ ثم يتم استدعاء البرنامج النصي PHP المقابل.
يمكن للصفحات الخاصة أن تفعل كل أنواع الأشياء السحرية، ولكل منها غرض محدد، وعادة ما يكون مستقلاً عن أي مقالة أو محتواها.
تتضمن الصفحات الخاصة أنواعًا مختلفة من التقارير (التغييرات الأخيرة والسجلات والصفحات غير المصنفة) وأدوات إدارة wiki (كتل المستخدم وتغييرات حقوق المستخدم) وغيرها.
يعتمد سير عمل التنفيذ على وظيفتهم.
تحتوي العديد من الوظائف على رمز إنشاء ملفات التعريف، مما يجعل من الممكن متابعة سير عمل التنفيذ لتصحيح الأخطاء، في حالة تمكين إنشاء ملفات التعريف.
يتم تصميم الملفات الشخصية عن طريق استدعاء وظائف wfProfileIn و wfProfileOut لبدء وتوقف تصميم المفردات على التوالي؛ كل من وظائف تأخذ اسم الوظيفة كمعيار.
في مواقع ويكيميديا، يتم إجراء التنميط لنسبة مئوية من جميع الطلبات، للحفاظ على الأداء.
يرسل ميدياويكي حزم UDP إلى خادم مركزي يجمعها وينتج بيانات ملفات التعريف.
تجميع صفحة غير مخزنة مؤقتًا
عند عرض صفحة ما، قد يتم أخذ كود HTML من ذاكرة التخزين المؤقت (انظر أدناه)؛ إذا لم يكن الأمر كذلك، يتم أولاً توسيع القوالب ووظائف المحلل اللغوي والمتغيرات. This gives the expanded wikitext, an intermediate result which can be seen with Special:ExpandTemplates, and depends on:
- النص الإلكتروني؛
- القوالب المشار إليها بشكل مباشر أو غير مباشر؛
- وظائف المحلل اللغوي المشار إليها بشكل مباشر أو غير مباشر؛
- قيم المتغيرات المشار إليها بشكل مباشر أو غير مباشر.
بعد ذلك، يتم تحويل نص الويكي الموسع هذا إلى كود HTML؛ يتم إرساله إلى المستخدم، ويحتوي على إشارات إلى ملفات CSS وJavaScript وملفات الصور. يمكن للمستخدم رؤية هذه النتيجة المتوسطة من خلال تطبيق خيار "عرض المصدر" في المتصفح. يعتمد كود HTML لصفحة معينة على:
- ونص الويكي الموسع؛
- الوضع، مثل العرض أو التحرير (انظر أدناه)؛
- وجود صفحات مرتبطة داخليًا (تعطي رابط العرض أو التحرير)؛
- الجلد وتفضيلات المستخدم الأخرى؛
- اسم المستخدم
- حالة المستخدم (المزيد من الروابط إذا كان نظامًا، وما إلى ذلك)؛
- مساحة الاسم (يحدد الرابط إلى صفحة النقاش، أو في حالة صفحة النقاش، الصفحة المعنية)؛
- ما إذا كان المستخدم يشاهد الصفحة (يعطي رابط المشاهدة أو عدم المشاهدة)؛
- ما إذا كانت صفحة النقاش الخاصة بالمستخدم قد تم تحريرها مؤخرًا (تعطي رسالة).
وأخيرًا، يعرض المتصفح HTML باستخدام الملفات التي يشير إليها. النتيجة التي يراها المستخدم على الشاشة تعتمد على:
- رمز HTML
- الملفات المشار إليها بواسطة كود HTML، مثل الصور المضمنة وملفات CSS من جانب الخادم وملفات JavaScript؛
- إعدادات المتصفح والمتصفح، بما في ذلك ربما ملف CSS محلي، ودقة الشاشة.
إذا كانت JavaScript تستجيب لحدث مثل النقر بالماوس، فإن الصفحة التي تظهر على الشاشة تعتمد أيضًا على هذه الأحداث. ينطبق هذا، على سبيل المثال، في حالة وجود جدول قابل للفرز.
عندما يختار المستخدم علامة التبويب "تحرير"، يتم إرسال نص الويكي نفسه إليه، للصفحة بأكملها أو لقسم واحد فقط. عندما يضغط المستخدم على إظهار المعاينة، يتم إرسال الإصدار الجديد من نص الويكي إلى الخادم، الذي يرسل الإصدار الجديد المقابل من كود HTML، والذي يتم عرضه مرة أخرى وعرضه أعلى أو أسفل الإصدار الجديد للمستخدم من نص الويكي (الذي عاد الخادم أيضًا). بعد المزيد من التغييرات والمعاينات، يضغط المستخدم على حفظ الصفحة، ويرسل الإصدار "النهائي" الخاص بالمستخدم إلى الخادم، والذي يسجل الآن التعديل ويرسل HTML للإصدار الجديد (مرة أخرى). في بعض الحالات، يتم أيضًا إجراء تحويل تلقائي لنص الويكي في هذه المرحلة.
التخزين المؤقت
تم تحسين ميديا ويكي نفسها لأداءها لأنها تلعب دورا مركزيا في مواقع ويكيميديا، ولكنها أيضًا جزء من النظام البيئي التشغيلي الأكبر الذي أثّر على معماريّتها. فرضت البنية التحتية للتخزين المؤقت في ويكيميديا قيودًا على ميدياويكي؛ لقد عمل المطورون على حل هذه المشكلات، ليس من خلال محاولة تشكيل البنية التحتية للتخزين المؤقت المحسنة على نطاق واسع لويكيميديا حول ميدياويكي، ولكن من خلال جعل ميدياويكي أكثر مرونة، حتى تتمكن من العمل ضمن تلك البنية التحتية، دون المساس بالأداء واحتياجات التخزين المؤقت.
في مواقع ويكيميديا، يتم التعامل مع معظم الطلبات بواسطة وكلاء التخزين العكسي (Squids) ، ولا يصلون إلى خوادم تطبيقات ميديا ويكي أبدًا. تحتوي Squids على إصدارات ثابتة من الصفحات المعروضة بالكامل، ويتم تقديمها للقراءة البسيطة للمستخدمين الذين لم يسجلوا الدخول إلى الموقع. تدعم ميدياويكي بشكل طبيعي Squid و Varnish ، وتتكامل مع هذه الطبقة التخزينية عن طريق ، على سبيل المثال ، إخطارهم بتطهير صفحة من التخزينة عندما يتم تغييرها. بالنسبة للمستخدمين الذين قاموا بتسجيل الدخول، والطلبات الأخرى التي لا يمكن تقديمها بواسطة Squids، يقوم Squid بإعادة توجيه الطلبات إلى خادم الويب (Apache).
يحدث المستوى الثاني من التخزين الآلي عندما تقوم ميديا ويكي بتقديم الصفحة وتجميعها من عدة أشياء، يمكن تخزين العديد منها لتقليل المكالمات المستقبلية. تتضمن هذه الكائنات واجهة الصفحة (الشريط الجانبي، القوائم، نص واجهة المستخدم) والمحتوى الصحيح، الذي تم تحليله من نص الويكي. أصبحت ذاكرة التخزين المؤقت للكائنات في الذاكرة متاحة في ميدياويكي منذ الإصدار 1.1 المبكر (2003)، وهي مهمة بشكل خاص لتجنب إعادة تحليل الصفحات الطويلة والمعقدة.
يمكن تخزين بيانات جلسة الدخول أيضًا في memcached ، مما يتيح للجلسات العمل بشكل شفاف على العديد من خوادم الويب الأمامية في إعداد توازن الحمل (تعتمد ويكيميديا بشكل كبير على توازن الحمولة ، باستخدام LVS مع PyBal).
منذ الإصدار 1.16, تستخدم ميديا ويكي مخزن محفظي خاص للمواد المتعلقة بالنص الموضعي لصفحة المستخدم؛ تم إضافة هذا بعد ملاحظة أن جزءًا كبيرًا من الأشياء المحفوظة في مخزن محفوظ تتكون من رسائل UI الموضعية في لغة المستخدم. يستند النظام على استرداد سريع للرسائل الفردية من قواعد البيانات المستمرة (CDB) ، أي الملفات ذات أزواج القيمة المفتاحية. تقليل أجهزة CDB تكلفة الذاكرة العامة والوقت الإبتدائي في الحالة النموذجية؛ كما يستخدمون أيضًا لخزنة Special:MyLanguage/interwiki cache للخزنة.
تتكون طبقة التخزين المؤقت الأخيرة من ذاكرة التخزين المؤقت لرمز تشغيل PHP، والتي يتم تمكينها عادةً لتسريع تطبيقات PHP. يمكن أن تكون التجميع عملية طويلة؛ لتجنب تجميع نصوص PHP إلى رمز الاختيار في كل مرة يتم استدعائها، يمكن استخدام تسريع PHP لتخزين رمز الاختبار المجمّع وتشغيله مباشرة دون تجميع. سوف يعمل MediaWiki فقط مع العديد من المسرعات مثل APC وPHP Accelerator.
بسبب انحيازها إلى ويكيميديا، تم تحسين ميدياويكي لهذه البنية التحتية الكاملة والمتعددة الطبقات والموزعة للتخزين المؤقت. ومع ذلك، فإنه يدعم أيضاً إعدادات بديلة للمواقع الصغيرة. على سبيل المثال، فهو يوفر نظامًا اختياريًا مبسطًا للتخزين المؤقت للملفات، حيث يقوم بتخزين نتائج الصفحات المعروضة بالكامل، كما يفعل Squid. أيضا، طبقة تخزين الأشياء المجردة في ميديا ويكي تسمح لها بتخزين الأشياء المحفوظة في تخزين في العديد من الأماكن، بما في ذلك نظام الملفات، قاعدة البيانات، أو مخزن الاحتفاظ بالرمز.
مثل العديد من تطبيقات الويب، أصبحت واجهة ميديا ويكي أكثر تفاعلاً واستجابةً على مر السنين، ويرجع ذلك إلى استخدام جاوا سكرفت. جهود سهولة الاستخدام التي بدأت في عام 2008، بالإضافة إلى التعامل المتقدم مع الوسائط (مثل تحرير ملفات الفيديو عبر الإنترنت)، دعت إلى تحسينات مخصصة لأداء الواجهة الأمامية.
لتحسين إمدادات JavaScript و CSS، تم تطوير وحدة ResourceLoader. بدأ في عام 2009، وتم الانتهاء منه في عام 2011 وأصبح سمة أساسية في ميدياويكي منذ الإصدار 1.17. يعمل ResourceLoader عن طريق تحميل أصول JS و CSS على الطلب ، وبالتالي تقليل وقت تحميل وتحليل الميزات غير المستخدمة ، على سبيل المثال في المتصفحات القديمة. كما أنه يعمل أيضًا على تصغير التعليمات البرمجية، وتجميع الموارد لحفظ الطلبات، ويمكنه تضمين الصور كمعرفات URI للبيانات.
اللغات
السياق والأساس المنطقي
إن الجزء الأساسي من المساهمة الفعالة ونشر المعرفة المجانية للجميع هو توفيرها بأكبر عدد ممكن من اللغات. ويكيبيديا متوفرة في أكثر من 280 لغة، ومقالات الموسوعة الإنجليزية تمثل أقل من 20٪ من جميع المقالات. ونظرًا لوجود ويكيبيديا والمواقع الشقيقة بالعديد من اللغات، فمن المهم ليس فقط توفير المحتوى باللغة الأصلية للقراء، ولكن أيضًا توفير واجهة محلية وأدوات إدخال وتحويل فعالة، حتى يتمكن المشاركون من المساهمة بالمحتوى.
لهذا السبب ، فإن "Special:MyLanguage/localisation" (اللوكلايزة والدولية) هي مكون مركزي من "ميديا ويكي". نظام i18n منتشر ويؤثر على أجزاء كثيرة من البرنامج؛ إنها أيضًا واحدة من أكثر الميزات مرونة وغنية بالميزات. يفضل المرونة المترجمة عادةً على مرونة المطور، ولكن يعتقد أن هذا تكلفة مقبولة.
يتم تحويل ميديا ويكي إلى أكثر من 350 لغة حاليًا ، بما في ذلك اللغات غير اللاتينية واللغة اليمنى إلى اليسار (RTL) ، مع مستويات مختلفة من الإكمال. يمكن أن تكون الواجهة والمحتوى بلغات مختلفة، ويمكن أن يكون لها اتجاهات مختلطة.
لغة المحتوى
في الأصل استخدمت ميديا ويكي رمزية لكل لغة، مما أدى إلى الكثير من المشاكل؛ على سبيل المثال، لم يتم استخدام النصوص الأجنبية في عناوين الصفحات. تم اعتماد UTF-8 بدلاً من ذلك. تم إسقاط دعم مجموعات الأحرف بخلاف UTF-8 في عام 2005، جنبًا إلى جنب مع التغيير الرئيسي في مخطط قاعدة البيانات في MediaWiki 1.5؛ يجب الآن ترميز المحتوى بتنسيق UTF-8.
Characters not available on the editor's keyboard can be customised and inserted via MediaWiki's Edittools, an interface message that appears below the edit window; its JavaScript version automatically inserts the character clicked into the edit window.
تمديد WikiEditor لميدياويكي، الذي تم تطويره كجزء من جهد الاستخدام، يدمج الأحرف الخاصة مع شريط أدوات التحرير.
ملحق آخر، يسمى UniversalLanguageSelector، يوفر طرق إدخال إضافية وميزات تعيين رئيسية للأحرف غير ASCII.
تشمل التحسينات الأخيرة والمستقبلية أفضل Special:MyLanguage/Directionality support نسبة دعم النص من اليمين إلى اليسار ، النص المتوجه ثنائي الاتجاه (النص LTR و RTL على نفس الصفحة) وUniversalLanguageSelector.
لغة الواجهة
تم تخزين رسائل الواجهة في مصفوفات PHP لأزواج القيم الرئيسية منذ إنشاء البرنامج Phase III.
يتم تعريف كل رسالة بواسطة مفتاح فريد، والذي يتم تعيين قيم مختلفة له عبر اللغات.
يتم تحديد المفاتيح من قبل المطورين، الذين يتم تشجيعهم على استخدام المضيفات للتوسيعات؛ على سبيل المثال، ستبدأ مفاتيح الرسالة لتوسيع UploadWizard بـ mwe-upwiz-, حيث تمثل mwe لـ "متوسع MediaWiki".
يمكن لرسائل ميدياويكي تضمين المعلمات التي يوفرها البرنامج، والتي غالبًا ما تؤثر على قواعد الرسالة. من أجل دعم أي لغة ممكنة تقريبًا ، تم تحسين ونسخة تحديد المواقع في ميديا ويكي مع مرور الوقت لتلبية سماتها الخاصة والاستثناءات ، والتي غالباً ما تعتبر غريبة من قبل الناطقين بالإنجليزية.
على سبيل المثال، الصفات هي كلمات لا تتغير في اللغة الإنجليزية، ولكن اللغات مثل الفرنسية تتطلب الاتفاق الصفوي مع الأسماء.
إذا كان لملف ملف المستخدم تعيين تفضيلات الجنس، يمكن استخدام مفتاح {{GENDER:}} في رسائل الواجهة لمعالجةها بشكل مناسب (translatewiki:Gender إضافة معلومات).
وتشمل المفتاحات الأخرى 1$، للكلمات متعددة "البسيطة" واللغات مثل العربية ذات الأرقام الثنائية أو المحاكمة أو القليلة، و 2$، توفير وظائف التحويل اللغوي للغات كاللغة الفنلندية التي تسبب الحالات اللغوية تغييرات أو انحناءات.
يمكن استخدام التمييز بين الجنسين أيضًا في أسماء مساحة أسماء المستخدمين المعتمدة على الجنس ، بحيث يشير عنوان الصفحة و URL إلى المستخدم بشكل صحيح.
يتم تحديد متغيرات الجنس الخاصة بمساحات أسماء ميدياويكي القياسية عبر $namespaceGenderAliases في MessagesXx.php لكل لغة، بينما يمكن استخدام $wgExtraGenderNamespaces لمساحات الأسماء الخاصة بالويكي.
اعتبارا من r107559, 13 لغة تستخدم هذه الميزة افتراضيًا:
- Arabic
- Czech
- German
- Lower Sorbian
- Spanish
- Galician
- Hebrew
- Upper Sorbian
- Polish
- Brazilian Portuguese
- Portuguese
- Russian
- Saterland Frisian
توطين الرسائل
تتمكن رسائل الواجهة المحلية لـ MediaWiki من الإقامة في ملفات MessagesXx.php، حيث أن Xx هو رمز ISO-639 للغة (على سبيل المثال، MessagesFr.php للفرنسية) ؛ والرسائل الافتراضية باللغة الإنجليزية وتخزن في MessagesEn.php.
تستخدم امتدادات ميدياويكي نظامًا مشابهًا، أو تستضيف جميع الرسائل المترجمة في ملف [اسم الامتداد].i18n.php.
بالإضافة إلى الترجمات، تشتمل ملفات الرسائل أيضًا على معلومات تعتمد على اللغة مثل تنسيقات التاريخ.
المساهمة في الترجمات التي كانت تستخدم من خلال إرسال إصلاحات PHP للملفات MessagesXx.php .
في ديسمبر 2003، قدم ميدياويكي 1.1 "رسائل قاعدة البيانات"، وهي مجموعة فرعية من صفحات الويكي في مساحة اسم ميدياويكي التي تحتوي على رسائل الواجهة.
محتوى صفحة الويكي MediaWiki:[Message-key] هو نص الرسالة، ويتجاوز قيمته في ملف PHP.
Localised versions of the message are at MediaWiki:[Message-key]/[language-code], e.g. MediaWiki:Rollbacklink/de.
أتاحت هذه الميزة للمستخدمين المتميزين ترجمة (وتخصيص) رسائل الواجهة محليًا على موقع wiki الخاص بهم، لكن العملية لا تقوم بتحديث ملفات i18n التي يتم شحنها باستخدام ميدياويكي.
في عام 2006، أنشأ Niklas Laxström موقعًا خاصًا لـميدياويكي (الذي يتم استضافةه الآن في translatewiki.net) ، حيث يمكن للمترجمين تحديد مواقع رسائل الواجهة بسهولة في جميع اللغات، ببساطة عن طريق تحرير صفحة ويكي.
يتم تحديث ملفات MessagesXx.php بعد ذلك في مخزن رموز MediaWiki ، حيث يمكن الحصول عليها تلقائيًا من قبل أي ويكي ، وتحديثها باستخدام امتداد $2
في مواقع ويكيميديا، يتم استخدام رسائل قاعدة البيانات الآن فقط للتخصيص، وليس للتحديد الموقع بعد الآن.
تم تحديد مدى مديا ويكي وبعض البرامج ذات الصلة، مثل الآليات، أيضاً في translatewiki.net.
لمساعدة المترجمين على فهم سياق ومعنى رسالة الواجهة، يعتبر توفير وثائق لكل رسالة ممارسة جيدة في ميدياويكي.
يتم تخزين هذه الوثائق في ملف رسالة خاص، مع رمز اللغة qqq، والذي لا يتوافق مع لغة حقيقية.
يتم بعد ذلك عرض الوثائق الخاصة بكل رسالة في واجهة الترجمة على translatewiki.net.
أداة أخرى مفيدة هي رمز اللغة qqx: عند استخدامه مع المعلمة &uselang لعرض صفحة ويكي (على سبيل المثال en.wikipedia.org/wiki/Special:RecentChanges?uselang=qqx)، سيعرض ميدياويكي مفاتيح الرسائل بدلاً من قيمها في واجهة المستخدم؛ وهذا مفيد جدًا لتحديد الرسالة التي يجب ترجمتها أو تغييرها.
يمكن للمستخدمين المسجلين تعيين لغة الواجهة الخاصة بهم في تفضيلاتهم، وفي هذه الحالة تتجاوز لغة الواجهة الافتراضية للموقع. يدعم ميدياويكي أيضًا اللغات الاحتياطية: إذا لم تكن الرسالة متاحة باللغة المختارة، فسيتم عرضها بأقرب لغة ممكنة، وليس بالضرورة باللغة الإنجليزية. على سبيل المثال، اللغة الاحتياطية لبريتون هي الفرنسية.
المستخدمون
يتم تمثيل المستخدمين في الكود باستخدام مثيلات من فئة User، والتي تتضمن جميع الإعدادات الخاصة بالمستخدم (معرف المستخدم، الاسم، الحقوق، كلمة المرور، عنوان البريد الإلكتروني، وما إلى ذلك).
تستخدم فئات العملاء أدوات الوصول للوصول إلى هذه الحقول؛ يقومون بكل العمل لتحديد ما إذا كان المستخدم قد قام بتسجيل الدخول، وما إذا كان يمكن تلبية الخيار المطلوب من ملفات تعريف الارتباط أو ما إذا كانت هناك حاجة إلى استعلام قاعدة البيانات.
يتم تعيين معظم الإعدادات اللازمة لعرض الصفحات العادية في ملف تعريف الارتباط لتقليل استخدام قاعدة البيانات.
يوفر ميدياويكي نظام أذونات دقيق للغاية، مع إذن المستخدم بشكل أساسي لكل إجراء ممكن. على سبيل المثال، لتنفيذ إجراء "التراجع" (أي "التراجع السريع عن تعديلات آخر مستخدم قام بتحرير صفحة معينة")، يحتاج المستخدم إلى إذن rollback، المضمن افتراضيًا في مجموعة مستخدمي MediaWiki sysop.
ولكن من الممكن أيضًا إضافتها إلى مجموعات مستخدمين أخرى، أو إنشاء مجموعة مستخدمين مخصصة توفر هذا الإذن فقط (وهذا هو الحال في ويكيبيديا الإنجليزية، مع المجموعة Rollbackers). يتم تخصيص حقوق المستخدم عن طريق تحرير المصفوفة $wgGroupPermissions في LocalSettings.php؛ على سبيل المثال، يسمح $wgGroupPermissions['user']['movefile'] = true; لجميع المستخدمين المسجلين بإعادة تسمية الملفات.
يمكن للمستخدم أن ينتمي إلى عدة مجموعات، ويرث أعلى الحقوق المرتبطة بكل منها.
ومع ذلك، فإن نظام أذونات المستخدم الخاص بـ MediaWiki تم تصميمه بالفعل مع وضع ويكيبيديا في الاعتبار، أي موقع يمكن الوصول إلى محتواه للجميع، وتقتصر إجراءات معينة فقط على بعض المستخدمين. يفتقر ميدياويكي إلى مفهوم أذونات موحد ومنتشر؛ ولا يوفر ميزات CMS التقليدية مثل تقييد الوصول للقراءة أو الكتابة حسب مساحة الاسم والفئة وما إلى ذلك. توفر بعض امتدادات ميدياويكي مثل هذه الميزات إلى حد ما.
المحتوى
بنية المحتوى
تم استخدام مفهوم مساحات الأسماء في عصر UseModWiki في ويكيبيديا، حيث كانت صفحات النقاش تحت عنوان "[اسم المقالة]/Talk".
تم تقديم مساحات الأسماء رسميًا في أول "برنامج PHP النصي" الخاص بـ Magnus Manske.
وقد أعيد تنفيذها عدة مرات على مر السنين، ولكنها احتفظت بنفس الوظيفة: فصل الأنواع المختلفة من المحتوى.
وهي تتكون من بادئة، مفصولة عن عنوان الصفحة بنقطتين (على سبيل المثال Talk: أو File: وTemplate:)؛ مساحة اسم المحتوى الرئيسي ليس لها بادئة.
وسرعان ما اعتمدها مستخدمو ويكيبيديا، وقدموا للمجتمع مساحات مختلفة للتطور.
لقد أثبتت مساحات الأسماء أنها سمة مهمة في ميدياويكي، لأنها تنشئ الشروط المسبقة اللازمة لمجتمع الويكي وتقوم بإعداد مناقشات على المستوى التعريفي، وعمليات المجتمع، والبوابات، وملفات تعريف المستخدمين، وما إلى ذلك.
التكوين الافتراضي لمساحة اسم المحتوى الرئيسية لميدياويكي هو أن تكون مسطحة (بدون صفحات فرعية)، لأن هذه هي الطريقة التي تعمل بها ويكيبيديا، لكن تمكينها أمر تافه.
يتم تمكينها في مساحات أسماء أخرى (على سبيل المثال User:، حيث يمكن للأشخاص على سبيل المثال العمل على مسودة المقالات) وعرض مسارات التنقل.
تقوم مساحات الأسماء بفصل المحتوى حسب النوع؛ ضمن نفس مساحة الاسم، يمكن تنظيم الصفحات حسب الموضوع باستخدام الفئات، وهو مخطط تنظيم هرمي زائف تم تقديمه في ميدياويكي 1.3.
معالجة المحتوى: لغة ترميز MediaWiki والمحلل
المحتوى الذي أنشأه المستخدم والذي تم تخزينه بواسطة MediaWiki ليس بتنسيق HTML، ولكن في لغة ترميزية خاصة بـ MediaWiki، والتي تسمى أحيانًا "نص wiki". فهو يسمح للمستخدمين بإجراء تغييرات على التنسيق (على سبيل المثال، غامق ومائل باستخدام علامات الاقتباس)، وإضافة روابط (باستخدام الأقواس المربعة)، وتضمين القوالب، وإدراج محتوى يعتمد على السياق (مثل التاريخ أو التوقيع)، وإجراء عدد لا يصدق من الأشياء السحرية الأخرى.
لعرض صفحة، يجب تحليل هذا المحتوى، وتجميعه من جميع الأجزاء الخارجية أو الديناميكية التي يستدعيها، وتحويله إلى HTML مناسب. المصفح هو أحد أهم أجزاء مديا ويكي، مما يجعل من الصعب أيضا تغيير أو تحسين. لأن مئات الملايين من صفحات ويكي في جميع أنحاء العالم تعتمد على المصفح لمواصلة إصدار HTML بالطريقة التي كانت دائما، يجب أن تظل مستقرة للغاية.
لم يتم تحديد لغة الترميز بشكل رسمي منذ البداية؛ لقد بدأ بناءً على ترميز UseModWiki، ثم تحول وتطور حسب الحاجة. For example, the usage of a ThreadMode format for discussions made Magnus Manske implement the 3 or 4 tildes (~~~~) as a shortcut to sign one's posts in unstructured text. Tildes were chosen as it resembled his father's hand-written signature.[2]
في غياب المواصفات الرسمية، أصبحت لغة ترميز MediaWiki لغة معقدة وذات خصوصية، متوافقة بشكل أساسي فقط مع محلل MediaWiki؛ لا يمكن تمثيله كقواعد نحوية رسمية باستخدام تركيبات BNF أو EBNF أو ANTLR. يُشار إلى مواصفات المحلل اللغوي الحالي مازحًا على أنها "كل ما يخرجه المحلل اللغوي من نص الويكي، بالإضافة إلى بضع مئات من حالات الاختبار".
كانت هناك العديد من المحاولات لمحللي بديل، ولكن لم ينجح أي منها حتى الآن. In 2004, an experimental tokeniser was written by Jens Frank to parse wikitext, and enabled on Wikipedia; it had to be disabled three days later, because of the poor performance of PHP array memory allocations. منذ ذلك الحين، تم إجراء معظم عمليات التحليل باستخدام كومة ضخمة من التعبيرات النمطية، والعديد من الوظائف المساعدة. أصبحت علامات wiki وجميع الحالات الخاصة التي يحتاج المحلل اللغوي إلى دعمها أكثر تعقيدًا، مما يجعل المحاولات المستقبلية أكثر صعوبة.
كان تحسينًا ملحوظًا هو إعادة كتابة المعالج السابق لـ Tim Starling في MediaWiki 1.12, والذي كان الدافع الرئيسي له هو تحسين أداء التحليل على الصفحات التي تحتوي على نماذج معقدة.
يقوم المعالج المسبق بتحويل نص الويكي إلى شجرة XML DOM تمثل أجزاء من المستند (استدعاءات القالب، ووظائف المحلل اللغوي، وخطافات العلامات، وعناوين الأقسام، وبعض الهياكل الأخرى)، ولكن يمكنه تخطي "الفروع الميتة" في توسيع القالب، مثل حالات #switch غير المتابعة والافتراضيات غير المستخدمة لوسائط القالب.
ثم يقوم المصفح بتكرارها عبر هيكل DOM ويحول محتوياته إلى HTML.
العمل الأخير على محرر مرئي لـ MediaWiki جعل من الضروري تحسين عملية التحليل (وجعلها أسرع)، لذلك تم استئناف العمل على المحلل اللغوي والطبقات الوسيطة بين ترميز MediaWiki وHTML النهائي (انظر المستقبل، أدناه).
الصور والقوالب
يقدم ميدياويكي "كلمات سحرية" تعمل على تعديل السلوك العام للصفحة أو تضمين محتوى ديناميكي فيها.
وهي تتكون من: تبديل السلوك مثل __NOTOC__ (لإخفاء جدول المحتوى التلقائي) أو __NOINDEX__ (لإخبار محركات البحث بعدم فهرسة الصفحة)؛ متغيرات مثل {{CURRENTTIME}} أو {{SITENAME}}؛ ووظائف المحلل اللغوي، أي الكلمات السحرية التي يمكن أن تأخذ معلمات، مثل {{lc:[string]}} (لإخراج [string] بالأحرف الصغيرة).
المكونات مثل {{GENDER:}}, {{PLURAL:}} و {{GRAMMAR:}}, تستخدم لتحديد موقع واجهة المستخدم، هي وظائف المصفح.
الطريقة الأكثر شيوعا لإدراج محتوى من صفحات أخرى في صفحة ميديا ويكي هي استخدام نماذج. كانت القوالب مخصصة لاستخدام المحتوى نفسه على صفحات مختلفة، مثل لوحة الملاحة أو لافتات الصيانة على مقالات ويكيبيديا؛ وقدمت القدرة على إنشاء ترتيبات صفحة جزئية وإعادة استخدامها في آلاف المقالات مع الصيانة المركزية أثرت بشكل كبير على مواقع مثل ويكيبيديا.
ومع ذلك، تم استخدام الشكلات (وإساءة استخدامها) من قبل المستخدمين لغرض مختلف تمامًا. أتاح ميدياويكي 1.3 للقوالب أن تأخذ معلمات تغير مخرجاتها؛ القدرة على إضافة معلمة افتراضية (تم تقديمها في ميدياويكي 1.6) مكنت من بناء لغة برمجة وظيفية تم تنفيذها فوق لغة PHP، والتي كانت في النهاية واحدة من أكثر الميزات تكلفة من حيث الأداء.
ثم قام تيم ستارلينغ بتطوير وظائف مزيدة من أدوات البحث (موسع ParserFunctions) ، كقياس توقف ضد المباني المجنونة التي أنشأها مستخدمو ويكيبيديا مع القوالب.
تضمنت هذه المجموعة من الوظائف هياكل منطقية مثل #if و#switch، ووظائف أخرى مثل #expr (لتقييم التعبيرات الرياضية) و#time (لتنسيق الوقت).
وبعد فترة وجيزة، بدأ مستخدمو ويكيبيديا في إنشاء قوالب أكثر تعقيدًا باستخدام الوظائف الجديدة، مما أدى إلى انخفاض كبير في أداء التحليل على الصفحات ذات القوالب الثقيلة. تم تنفيذ m:Special:MyLanguage/Migration to the new preprocessor_معالج جديد المقدم في MediaWiki 1.12 (تغيير معماري كبير) لتحسين هذه المشكلة جزئيا. لاحقًا، ناقش مطورو ميدياويكي إمكانية استخدام لغة برمجة نصية فعلية لتحسين الأداء. تم إضافة Extension:Scribunto في فبراير 2013.
ملفات الوسائط
يقوم المستخدمون بتحميل الملفات من خلال صفحة Special:Upload؛ يمكن للمدراء تكوين أنواع الملفات المسموح بها من خلال قائمة بيضاء للتوسيع.
بمجرد تحميلها، يتم تخزين الملفات في مجلد على نظام الملفات، ويتم تخزين الصور المصغرة في دليل thumb مخصص.
نظرًا لمهمة ويكيميديا التعليمية، يدعم MediaWiki أنواع الملفات التي قد تكون غير شائعة في تطبيقات الويب أو أنظمة إدارة المحتوى الأخرى، مثل صور SVG المتجهة وملفات PDF متعددة الصفحات وDjVus. يتم تقديمها كملفات PNG، ويمكن تصغيرها وعرضها مضمّنة، كما هو الحال مع ملفات الصور الأكثر شيوعًا مثل GIF وJPG وPNGs.
عندما يتم تحميل ملف، يتم تخصيص صفحة بقيمة File: تحتوي على المعلومات التي أدخلها القائم بالتحميل؛ هذا نص حر، يتضمن عادةً معلومات حقوق الطبع والنشر (المؤلف والترخيص) وعناصر تصف أو تصنف محتوى الملف (الوصف والموقع والتاريخ والفئات وما إلى ذلك).
في حين أن مواقع الويكي الخاصة قد لا تهتم كثيرًا بهذه المعلومات، إلا أنها في مكتبات الوسائط مثل ويكيميديا كومنز تعتبر بالغة الأهمية لتنظيم المجموعة وضمان شرعية مشاركة هذه الملفات.
لقد قيل أن معظم هذه البيانات الوصفية يجب في الواقع تخزينها في بنية قابلة للاستعلام مثل جدول قاعدة البيانات.
وهذا من شأنه أن يسهل البحث بشكل كبير، ولكن أيضاً إصدار وإعادة استخدامها من قبل أطراف ثالثة - على سبيل المثال، من خلال API.
تسمح معظم مواقع ويكيميديا أيضًا بتحميلات "محلية" إلى كل ويكي، لكن المجتمع يحاول تخزين ملفات الوسائط المرخصة بحرية في مكتبة الوسائط المجانية الخاصة بويكيميديا، ويكيميديا كومنز. يمكن لأي موقع ويكيميديا عرض ملف مستضاف على كومنز كما لو كان مستضافًا محليًا. يتجنب هذا التخصيص الاضطرار إلى تحميل ملف إلى كل موقع ويكي لاستخدامه هناك.
ونتيجة لذلك، يدعم ميدياويكي أصلا مستودعات الوسائط الأجنبية، أي القدرة على الوصول إلى ملفات الوسائط المستضافة على ويكي آخر من خلال واجهة برمجة التطبيقات الخاصة به ونظام ForeignAPIRepo.
منذ الإصدار 1.16، يمكن لأي موقع ويب MediaWiki استخدام الملفات من Wikimedia Commons بسهولة من خلال ميزة InstantCommons.
عند استخدام مخزن أجنبي، يتم تخزين الصور الصغيرة محلياً لتوفير عرض النطاق.
ومع ذلك، ليس من الممكن (حتى الآن) الرفع إلى مستودع وسائط أجنبية من ويكي أخرى.
تخصيص و توسيع مديا ويكي
مستويات
توفر بنية ميديا ويكي طرق مختلفة لتخصيص وتوسيع البرنامج. ويمكن القيام بذلك على مستويات مختلفة من الوصول:
- يمكن لمسؤولي النظام تثبيت الامتدادات والأسطح، وتكوين برامج المساعدة المنفصلة الخاصة بالويكي (على سبيل المثال، لتصغير الصور وعرض TeX) والإعدادات العامة (راجع التكوين أعلاه).
- يمكن لأنظمة Wiki (التي يطلق عليها أحيانًا "المسؤولين" أيضًا) تحرير الأدوات الذكية على مستوى الموقع وإعدادات JavaScript وCSS.
- يمكن لأي مستخدم مسجل تخصيص تجربته وواجهته الخاصة باستخدام تفضيلاته (للإعدادات والمظاهر والأدوات الموجودة) أو إجراء تعديلات خاصة به (باستخدام صفحات JS وCSS الشخصية الخاصة به). يمكن للبرامج الخارجية أيضًا التواصل مع MediaWiki من خلال واجهة برمجة تطبيقات الجهاز الخاصة بها، إذا تم تمكينها، مما يجعل أي ميزة وبيانات في متناول المستخدم.
جافا سكريبت وCSS
يستطيع MediaWiki قراءة وتطبيق JavaScript وCSS على مستوى الموقع أو على مستوى الجلد باستخدام صفحات wiki المخصصة؛ هذه الصفحات موجودة في مساحة الاسم MediaWiki:، وبالتالي لا يمكن تحريرها إلا بواسطة sysops؛ على سبيل المثال، تنطبق تعديلات JavaScript بدءًا من MediaWiki:Common.js على جميع الأسطح، وتنطبق تعديلات CSS بدءًا من MediaWiki:Common.css على جميع الأسطح، ولكن MediaWiki:Vector.css تنطبق فقط على المستخدمين ذوي المظهر المتجه.
يمكن للمستخدمين إجراء نفس أنواع التغييرات، والتي سيتم تطبيقها فقط على الواجهة الخاصة بهم، عن طريق تحرير الصفحات الفرعية لصفحة المستخدم الخاصة بهم (على سبيل المثال User:[Username]/common.js لـ JavaScript على جميع الأسطح، أو User:[Username]/common.css لـ CSS على جميع الأسطح، أو User:[Username]/vector.css لتعديلات CSS التي تنطبق فقط على الجلد المتجه).
إذا تم تثبيت ملحق Gadgets، فيمكن أن يقوم sysops أيضًا بتحرير الأدوات، أي مقتطفات من تعليمات JavaScript البرمجية التي توفر ميزات يمكن تشغيلها وإيقاف تشغيلها بواسطة المستخدمين في تفضيلاتهم. التطورات القادمة على الأدوات الذكية ستجعل من الممكن مشاركة الأدوات عبر مواقع الويكي، وبالتالي تجنب الازدواجية.
كان لهذه المجموعة من الأدوات تأثير كبير وزادت بشكل كبير من إضفاء الطابع الديمقراطي على تطوير برمجيات ميدياويكي. يتم تمكين المستخدمين الفرديين من إضافة ميزات لأنفسهم؛ يمكن للمستخدمين المتميزين مشاركتها مع الآخرين، سواء بشكل غير رسمي أو من خلال أنظمة يتم التحكم فيها بواسطة sysop وقابلة للتكوين عالميًا. يعد هذا الإطار مثاليًا للتعديلات الصغيرة المستقلة، ويقدم حاجز دخول أقل من تعديلات التعليمات البرمجية الأثقل التي يتم إجراؤها من خلال الخطافات والامتدادات.
الامتدادات والجلود
عندما لا تكون تعديلات JavaScript وCSS كافية، يوفر MediaWiki نظامًا من خطافات يسمح لمطوري الطرف الثالث بتشغيل كود PHP مخصص قبل أو بعد أو بدلاً من كود MediaWiki لأحداث معينة. تستخدم امتدادات ميديا ويكي الكوكس لتوصيل الشفرة.
قبل وجود الخطافات في ميدياويكي، كانت إضافة كود PHP مخصص يعني تعديل الكود الأساسي، وهو الأمر الذي لم يكن سهلاً ولا يوصى به. تم اقتراح الخطافات الأولى وإضافتها في عام 2004 بواسطة إيفان برودرومو؛ تمت إضافة المزيد على مر السنين عند الحاجة. باستخدام الركاب، من الممكن حتى توسيع علامة ويكي مديا ويكي مع قدرات إضافية، باستخدام تمديدات التج.
نظام التوسيع ليس مثالياً: تسجيل التوسيع يستند إلى تنفيذ الرمز عند البدء، بدلاً من البيانات القابلة للتخزين، مما يحد من الاستخراج والتحسين ويضر بأداء مديا ويكي. ولكن بشكل عام، تعد بنية التوسيع الآن بنية تحتية مرنة إلى حد ما ساعدت في جعل الشفرة المتخصصة أكثر نماذجية، مما منع البرنامج الأساسي من التوسع (بالكثر من اللازم) ، مما يسهل على مستخدمي الطرف الثالث بناء وظائف مخصصة على رأس مديا ويكي.
وعلى العكس من الصعب جداً كتابة جلد جديد لـ "ميديا ويكي" دون إعادة اختراع العجلة.
في MediaWiki، الأسطح عبارة عن فئات PHP تمتد كل منها إلى الفئة الأصلية Skin؛ أنها تحتوي على وظائف تقوم بجمع المعلومات اللازمة لإنشاء HTML.
كان من الصعب تخصيص غلاف "MonoBook" طويل الأمد لأنه يحتوي على الكثير من CSS الخاص بالمتصفح لدعم المتصفحات القديمة؛ يتطلب تحرير القالب أو CSS العديد من التغييرات اللاحقة لتعكس التغيير لجميع المتصفحات والأنظمة الأساسية.
نقطة الوصول الرئيسية الأخرى لميدياويكي، إلى جانب index.php، هي api.php، وتستخدم للوصول إلى واجهة برمجة التطبيقات (API) للاستعلام المقروء آليًا.
أوجد مستخدمو ويكيبيديا في الأصل "روبوتات" التي عملت من خلال شاشة "Special:MyLanguage/screen scraping" من خلال إزالة محتوى HTML الذي تقدمه ميديا ويكي؛ كانت هذه الطريقة غير موثوقة للغاية وتحطمت مرات عديدة.
To improve this situation, developers introduced a read-only interface (located at query.php), which then evolved into a full-fledged read and write machine API providing direct, high-level access to the data contained in the MediaWiki database.
يمكن للبرامج العميل استخدام API للانتقال والحصول على البيانات ونشر التغييرات. تدعم واجهة برمجة التطبيقات عملاء JavaScript رفيعي المستوى المستندين إلى الويب وتطبيقات المستخدم النهائي. تقريبا كل ما يمكن القيام به عبر واجهة الويب يمكن القيام به في الأساس من خلال API. تتوفر مكتبات العملاء التي تنفذ واجهة برمجة تطبيقات MediaWiki بالعديد من اللغات، بما في ذلك Python و.NET.
Layers, domains, and patterns
MediaWiki can be divided into around 12 technical layers, with each layer calling classes and code in the layer beneath it but not above it. Examples include the installer layer, entry point layer, wiring layer, and API layer. Code spanning all the layers can be grouped into around 21 domain modules, with examples including the navigation domain (skins), user management domain (create, rename, login), and internationalisation domain. Many software design patterns are used in MediaWiki, including the factory pattern, handler pattern, and command pattern.
المستقبل
ما بدأ كمشروع صيفي قام به مطور PHP متطوع واحد تطور ليصبح MediaWiki، وهو محرك ويكي ناضج ومستقر يعمل على تشغيل أفضل عشرة مواقع ويب ببنية تحتية تشغيلية صغيرة بشكل يبعث على السخرية. لقد أصبح هذا ممكنًا من خلال التحسين المستمر للأداء والتغييرات المعمارية التكرارية وفريق من المطورين الرائعين.
يتطلب تطور تقنيات الويب ونمو ويكيبيديا تحسينات مستمرة وميزات جديدة، والتي يتطلب بعضها تغييرات كبيرة في بنية ميدياويكي. هذا هو الحال، على سبيل المثال، بالنسبة لمشروع المحرر المرئي الجاري، والذي أدى إلى تجديد العمل على المحلل اللغوي وعلى لغة ترميز الويكي، وDOM، والتحويل النهائي لـ HTML.
ميدياويكي هي أداة تستخدم لأغراض متنوعة. ضمن مشاريع ويكيميديا، على سبيل المثال، يتم استخدامه لإنشاء وتنظيم موسوعة (ويكيبيديا)، لتشغيل مكتبة وسائط ضخمة (ويكيميديا كومنز) أو لنسخ النصوص المرجعية الممسوحة ضوئيًا (ويكي مصدر)؛ وما إلى ذلك وهلم جرا. في سياقات أخرى، يتم استخدام ميدياويكي كنظام إدارة محتوى خاص بالشركة، أو كمستودع للبيانات، ويتم دمجه أحيانًا مع إطار عمل دلالي. من المحتمل أن تستمر هذه الاستخدامات المتخصصة التي لم يتم التخطيط لها في إجراء تعديلات مستمرة على البنية الداخلية للبرنامج. وعلى هذا النحو، فإن بنية MediaWiki حية للغاية، تمامًا مثل المجتمع الهائل من المستخدمين الذين تدعمهم.
الملاحظات والمراجع
- ↑ عادةً ما يتم تجميل طلبات العرض من خلال إعادة كتابة عنوان URL، في هذا المثال إلى
w:Apple. - ↑ https://twitter.com/MagnusManske/status/1083507467802365952
مزيد من القراءة
- وثائق و دعم ميدياويكي: https://www.mediawiki.org
- وثائق ميديا ويكي التي يتم إنشاؤها تلقائيًا: https://doc.wikimedia.org
- دوماس ميتوزاس، "ويكيبيديا: داخلية الموقع، التكوين، أمثلة رمز ومسائل الإدارة"، مؤتمر مستخدمي MySQL، 2007. النص الكامل متاح من http://dom.as/talks/
- فايدون ليمبوتيس، "بنية تحتية ويكيميديا"، dotScale 2014. (فيديو يوتيوب)