מדריך:שגיאות ותסמינים שכיחים

התקנת מדיה-ויקי

• דרישות
• הורדה
• חילוץ
• העלאה
• הגדרת מסד נתונים
• התקנה
• הגדרה
• שדרוג

---

• שאלות נפוצות
• בעיות נפוצות
• קבלת עזרה ותמיכה

---

• התחלה מהירה לפיתוח מקומי

דף לבן ריק מציין שגיאת PHP שאינה מודפסת למסך. כדי לכפות זאת, הוסיפו את השורות הבאות לקובץ LocalSettings.php, מתחת ל־<?php:

error_reporting( E_ALL );
ini_set( 'display_errors', 1 );

ניתן גם להגדיר ערך עבור error_log בתוך PHP.ini ולקרוא את יומן השגיאות של PHP כדי לברר מה קורה. במקרים מסוימים, שגיאות PHP עשויות להירשם גם ביומן השגיאות של שרת האינטרנט.

דוחות שגיאה עשויים לכלול:

• "אזהרה [...] לא בטוח להסתמך על הגדרות אזור הזמן של המערכת. עליך *להשתמש* בהגדרה date.timezone או בפונקציה date_default_timezone_set()." בדוק אם date.timezone = מוגדר נכון (או מוגדר בכלל) ב־php.ini.
• ייתכן שקבצים מסוימים ידווחו כחסרים (למשל, כאשר התיקייה media בתיקיית ה־/includes שלך אינה קיימת עוד, ייתכן שתקבל את ההודעה שתהליך הדמיה נדרש "נכשל בפתיחת הזרם"). בדוק את חבילת ההתקנה המקורית במדיה־ויקי (הקפד לעיין בגרסה המתאימה) כדי לראות אם זה המצב. אם כן, פשוט העתיקו את הקבצים החסרים מהחבילה לתיקיית המדיה־ויקי שלכם. ייתכן שיהיה צורך לרענן את המטמון ולהפעיל מחדש את שרת האינטרנט לאחר מכן.
• לא ניתן למצוא את השקע של MySQL. אם LocalSettings.php מוגדר לשקע MySQL הנכון אך php.ini לא, הדבר עלול לגרום למסך ריק ללא פלט שגיאה משרת האינטרנט או מ־PHP. התיקון הוא לעדכן את הערך mysql.default_socket בקובץ php.ini.

אנשים רבים מדווחים על דפים ריקים בגרסאות האחרונות לאחר שליחת ערכים לדף הויקי החדש שלהם. סיבה סבירה היא מגבלת הזיכרון בהתקנות ברירת מחדל של php (בדרך כלל 8 מגה-בית). אנא בדוק את יומני השגיאות של PHP ו/או Apache. כדי לשנות הגדרה זו, ערוך את /etc/php.ini והגדל את ההגדרה "memory_limit". לדוגמה, כדי להגדיל אותו ל-32 מגה-בית, החלף את הטקסט הקיים ב־memory_limit = 32M. ודא להפעיל מחדש את שרת האינטרנט שלך לאחר שתשנה ערך זה.

ייתכן שמגבלת הזיכרון הוגדרה גם בקובץ LocalSettings.php שלך. סרוק את השורה המכילה את ההגדרה memory_limit והגדל לפי הצורך. ייתכן ש־20M לא יספיקו אם אתה מפעיל את גרסה 1.15.1. שנה את זה, למשל, ל־"memory_limit = 32M". שינוי זה אינו מחייב אותך להפעיל מחדש את Apache.

אם הדף פשוט נתקע בטעינה במשך זמן מה (כ־30 שניות) בעת ביצוע פעולה מסוימת, ולאחר מכן זה גורם לדף ריק או שגיאת HTTP 500, הבעיה היא פסק זמן של התחברות לשרת כלשהו. זה יכול להיות שרת מסד הנתונים, או אם זה קורה בזמן פעולה ספציפית, שרת הדואר (אם קבעתם את הגדרות הדוא"ל). אם זה שרת הדוא"ל, בדוק אם אתה יכול להתחבר אליו מהשרת שמפעיל את מדיה־ויקי, לדוגמה, הפעל את לקוח Telnet לשרת ולפורט שתצורתו נקבעה ב־$wgSMTP ובדוק אם הוא יכול להתחבר.

אם אתם רואים את תוכן הדף לרגע קצר, ולפתע כל הדף מתרוקן, סביר להניח שהבעיה נגרמת עקב נוכחות של פקודת JavaScript בגודל document.write, document.writeln או document.open באחד מהתסריטים

של דף הויקי.

אתה יכול לבדוק אם זה המצב על ידי פתיחת קונסולת הדפדפן שלך (לחץ על F12) וטען מחדש את הדף. אם כרטיסיית הרשת מחזירה סטטוס HTTP 200, וההעברה היא של כמה קילו-בית, סביר מאוד שזו הבעיה. אלו הן שיטות מדור קודם של ממשק Document ��גורמות לכל הדף להתרוקן אם הוא משמש מחוץ ל־HTML של הדף, וייתכן שהן קיימות בדפי ה־JavaScript של הויקי. השימוש בהם אינו מומלץ בתוקף, כפי שמצוין במפרט HTML עצמו. ניתן להשבית את JavaScript בדפדפן, או להגדיר את $wgUseSiteJs ו־$wgAllowUserJs ל־false כדי להשבית את התסריטים הללו עד שתתקן את התסריטים הפגומים.

סעיף זה מפרט בעיות ופתרונות הקשורים לתמונות ממוזערות שאינן מעובדות או מוצגות.

זה יכול לקרות עקב ערכים שגויים של משתנים גלובליים כפי שמוסבר ב:

• Manual:$wgUploadDirectory
• Manual:$wgUploadPath
• Manual:$wgScriptPath

אם תמונות ממוזערות פשוט לא מופיעות, ואין שגיאה גלויה בדפים אלה, עיין בקוד מקור ה־HTML של הדף וחפש "srcset". אם מצאת משהו כמו <img ... srcset="/images/thumb/File.png/600px-File.png 1,5x, /images/thumb/File.png/800px-File.png 2x">, שבו הוא מופיע כ־1,5x במקום כ־1.5x, הבעיה נגרמת על ידי T181987, ועליך להוסיף זאת ל־LocalSettings.php:

setlocale(LC_NUMERIC, "C");

See also: Manual:Image administration#SVG

ראשית, קבע את הגדרת ה־$wgSVGConverter שלך. כברירת מחדל, הוא מוגדר להשתמש ב־ ImageMagick לצורך המרה.

תצטרך לפחות את הגרסה של ImageMagick 6.x.x. ודא שהמשתנה $wgImageMagickConvertCommand שלך תקין. הגדרות נפוצות הן:

$wgImageMagickConvertCommand = "/usr/bin/convert";
$wgImageMagickConvertCommand = "/usr/local/bin/convert";

אם זה לא עובד, נסה להגדיר את $wgSVGConverterPath .

$wgSVGConverterPath = "/usr/bin";
$wgSVGConverterPath = "/usr/local/bin";

מארחי שרתים משותפים עשויים לספק גרסאות שונות של ImageMagick כדי לענות על צרכי משתמשים שונים. אנא השתמש בגרסה 6.x.x.

• כדי לקבוע את גרסת ImageMagick, חפשו בקבצי העזרה של ספק האירוח שלכם, או השתמשו ב־/usr/bin/convert --version או /usr/local/bin/convert --version כדי לזהות.
• ב־GoDaddy לינוקס, "/usr/bin/convert" עבור הגרסה 5.5.6 ו־"/usr/local/bin/convert" עבור הגרסה 6.2.8.

אם יצירת תמונות ממוזערות באמצעות ImageMagick נכשלת עם הודעת יומן שגיאה של שרת אינטרנט כמו "הקצאת זיכרון נכשלה" או "/bin/ulimit4.sh: תקלת סגמנטציה /usr/bin/convert ...", ייתכן שיהיה צורך להגדיל את הערך $wgMaxShellMemory .

כאשר חסרים תווים שאינם של ASCII בנתיב

• בדוק אם הגדרות UTF-8 מקומיות זמינות בשרת שלך על ידי הפעלת locale -a
• כאשר זה לא זמין, הפעל את locale-gen en_US.utf8 או הזן את ההגדרות האזוריות עם UTF-8 עבור המדינה שלך ושנה את הערך עבור $wgShellLocale בהתאם לכך.

בעת שימוש ב-IIS/FastCGI במערכת ווינדוס, חשבון האורח בו נעשה שימוש זקוק גם להרשאת ביצוע ב־C:\Windows\System32\cmd.exe, אחרת תקבלו שגיאת "לא ניתן למזג".

מדיה-ויקי מציבה מגבלות זמן וזיכרון על פקודות מעטפת תחת לינוקס. אם אתה מקבל את השגיאה "אירעה שגיאה במהלך אתחול המכונה הוירטואלית, לא ניתן היה לשמור מספיק מקום עבור ערימת האובייקטים, לא ניתן היה ליצור את המכונה הוירטואלית של Java.", נסה להגדיל את הערך של $wgMaxShellMemory .

בחלק מהתקנות לינוקס ו-BSD, שם rsvg משתנה כך:

במקום ההגדרה (ברירת מחדל)

$wgSVGConverters = array( 'rsvg' => '$path/rsvg -w$width -h$height $input $output' );

תרצה להגדיר

$wgSVGConverters = array( 'rsvg' => '$path/rsvg-convert -w $width -h $height -o $output $input' );

תסמין: הודעת השגיאה הזו בתוך תיבה אפורה:

שגיאה ביצירת תמונה ממוזערת: פרמטרים לא חוקיים של תמונה ממוזערת

סיבה אחת: מספר הפיקסלים בתמונה המקורית חורג מ-$wgMaxImageArea . ערך ברירת המחדל 1.25e7 קטן מדי עבור מצלמות מודרניות רבות. חבל שהאבחון לא באמת מצביע על הבעיה.

ניתן להגדיל את הערך של $wgMaxImageArea או לעבור לשימוש ב-ImageMagick אשר עוקף את המגבלה הזו (הגדר $wgUseImageMagick ו-$wgImageMagickConvertCommand ).

תמונות גדולות יכולות לקחת זמן עיבוד משמעותי. ייתכן שזו מדיניות טובה להגביל את גודל התמונות.

תסמין: הודעת השגיאה הזו בתוך תיבה אפורה:

שגיאה ביצירת תמונה ממוזערת: הגדרות ספריית GD לא הושלמו: חסרה הפונקציה imagecreatefromjpeg

בחלק מגרסאות של PHP 4.x ו-5.x של PHP יש באג שבו libjpeg מזוהה אך לא מופעל במהלך שלב ./configure; זה די נפוץ במערכות Red Hat/RHEL/CentOS. אם אינך רוצה להשתמש ב-ImageMagick, הפתרון לבעיה הוא להדר מחדש את PHP. ראשית, גלה (מ-phpinfo()) מהם המתגים הקיימים ב-./configure, והוסף --with-jpeg-dir לפני --with-gd.

make clean
./configure --with-various-switches --with-jpeg-dir --with-gd --with-more-switches
make
make test
# לעבור ל-root
make install

לאחר מכן, הפעל מחדש את שרת האינטרנט (עבור Apache ב-Red Hat: service apache stop ואז service apache start). כדי לבדוק, פשוט צפה שוב בדף "קובץ:..." (אין צורך להעלות שוב). למידע נוסף עיין בתגובות על PHP: imagecreatefromjpeg (תקציר הפונקציה)

אם אתה מקבל את השגיאה "שגיאה בתהליך יצירת תמונה ממוזערת / שגיאה ביצירת תמונה ממוזערת: לא ��יתן לשמור את התמונה הממוזערת ביעד" ולתיקייה $wgUploadDirectory יש את ההרשאות הנכונות (בכל הרמות), ודא ש-$wgTmpDirectory אכן קיים. (בניגוד למשתני נתיב מסוימים כמו $wgCacheDirectory , $wgTmpDirectory לא נוצר בזמן ריצה.) הודעת שגיאה מפורטת יותר עשויה להיות זמינה אם תפעיל רישום באמצעות $wgDebugLogFile .

שגיאה זו יכולה להתרחש גם כאשר מצב קריאה בלבד ($wgReadOnly ) הוגדר ב-LocalSettings.php. אתה יכול לנסות להסיר את $wgReadOnly כדי לראות אם זה פותר את הבעיה עבורך.

אם אתה מקבל "שגיאה ביצירת תמונה ממוזערת קוד שגיאה: 25" עם ImageMagick, נסה להגדיל את הערך ב-$wgMaxShellFileSize .

במצבים בהם לא ניתן ליצור את התמונות הממוזערות באופן דינמי לפי בקשה (למשל, עבור תמונות גדולות מאוד, "שגיאה ביצירת תמונה ממוזערת: לא ניתן להרחיב את המטמון", "שגיאה ביצירת תמונה ממוזערת: המרה: לא מוגדרות תמונות", וכדומה), ניתן להוסיף את קבצי התמונות הממוזערות באופן ידני. זה כרוך ביצירת תמונות קטנות יותר בגדלים הרצויים והעלאתן לתיקייה thumb/ ב- $wgUploadDirectory .

לדוגמה, קובץ שהועלה אל:

images/f/f8/Foo.png

התמונות הממוזערות שלו צריכות להיות ב:

images/thumb/f/f8/Foo.png/100px-Foo.png
images/thumb/f/f8/Foo.png/600px-Foo.png

גודל הפיקסל הוא הממד האופקי. דוגמה לתסריט Bash ליצירת תמונות ממוזערות זמינה ב-Phabricator:P7049.

מסיבה לא ידועה, יצירת תמונות ממוזערות באירוח OVH הדדי נכשלת עם שגיאה זו, גם אם הפעלת הפקודה במעטפת SSH פועלת.

הפתרון הוא למנוע באופן ספציפי את השימוש ב־ImageMagick על ידי הגדרת $wgUseImageMagick ל־false ב־LocalSettings.php:

$wgUseImageMagick = false;

אם לשרת ה-Apache שלך יש את התיקון המוקשח של PHP, ייתכן שתצטרך לערוך מספר משתנים בקובץ /etc/php.ini שלך אם ברצונך שיהיו לך דפי ויקי עם כמויות גדולות של תוכן. בפרט, יש לקחת בחשבון את ההגדרות עבור varfilter.max_value_length, hphp.post.max_value_length, hphp.request.max_value_length. ייתכן שהגדרות ברירת המחדל מגבילות את הדפים שלך לגודל של פחות מ-10,000 או 64,000.

אפשרות נוספת היא אם שרת האפאצ'י שלך משתמש ב-mod_security שיכול להפריע למדיה-ויקי. תצטרך לכבות אותו כדי שמדיה-ויקי יפעל כראוי.

זה נגרם על ידי משהו שחותך או משמיט נתוני POST מהדפדפן לשרת האינטרנט.

לפחות במקרה אחד, זה נגרם עקב הגדרת סכום גבוה מדי של post_max_size ו-upload_max_filesize ב-php.ini (2048M). החזרתם לערכים שפויים יותר (8M) תיקנה את זה. ככל הנראה, שום נתוני POST לא הגיעו למדיה-ויקי.

במקרה אחר, mod_auth_sspi הפריע לפוסטים ב-http אל מדיה-ויקי. שימוש ב-FireFox והזנת פרטי דומיין יעבדו מצוין, אבל MSIE ייכשל. זהו פגם ידוע ב-mod_auth_sspi 1.0.4.

יש לך כמה אפשרויות כדי לגרום לזה לעבוד:

• כבה את SSPIOfferSSPI ← המשתמשים יקבלו בקשה ויצטרכו להזין פרטי דומיין, בדומה למצב BASIC
• הגדר את SSPIPerRequestAuth כפעילות ← אני לא רואה איך זו תצורה בריאה אבל זה עבד (למעט בחיבור בעל השהייה הגבוהה שאני נאלץ להתמודד איתו)
• שדרג לאחור לגרסה 1.0.3 אבל זה בעצם אותו דבר כמו #2 למעלה.

אם דף הויקי נראה בסדר אם גולשים בו מאותו שרת בו הוא מתאחסן, אך הוא נראה ללא סגנונות CSS (ללא צבעים, ללא רקעים, ללא תמונות, עיצוב מינימלי מאוד וכו'), אם ניגשים אליו ממחשבים אחרים (או מחלקם), הסיבה הסבירה ביותר היא שהשרת נתקל בבעיות בקביעת כתובת ה-IP או שם המארח המשמשים לגישה אליו, או שהוא מוגדר בצורה שגויה. פעולה זו גורמת ליצירת כתובות URL לסגנונות ותמונות באמצעות כתובת ה-IP של הלולאה החוזרת 127.0.0.1, localhost או שם מארח שאינו ידוע מחוץ לשרת. ניתן לראות את קוד המקור של כל דף ולבדוק כיצד נראות כתובות URL ומה קורה אם מנסים לגשת אליהן ישירות דרך הדפדפן.

הפתרון הוא לציין ידנית את המשתנה $wgServer לשם המארח שכולם ישתמשו בו כדי לגשת לדף הויקי.

אם הגישה לדף הויקי שלך מתבצעת מרשת פנימית ומרשת חיצונית, ייתכן שתצטרך להשתמש בכתובת החיצונית עבור $wgServer. אל תשכח את מספר הפורט אם אתה משתמש בפורט לא סטנדרטי, כפי שיקרה אם ספק האינטרנט שלך חסם את פורט 80 (לדוגמה: $wgServer = "http://example.domain.com:8080";)

אם סגנונות לא מוחלים גם בעת גלישה בדף הויקי מהשרת בו הוא מאוחסן, הבעיה עשויה להיות שגיאת PHP בתסריט ResourceLoader load.php. נסה לעיין בקובץ load.php של התקנת מדיה-ויקי שלך באמצעות דפדפן האינטרנט שלך ולראות אם הוא מציג שגיאות כלשהן או רק דף ריק (ראה #אתה רואה דף ריק). אתה אמור לראות תגובה דומה ל-/* No modules requested. Max made me put this here */. אם כן, ייתכן שמדובר בבעיה בקובץ .htaccess של שרת האינטרנט.

אם במקום זאת אתה רואה שגיאת 404 "לא נמצא", ייתכן שמדובר בבעיה בכללי הכתיבה מחדש של שרת האינטרנט אם ניסית להגדיר כתובות URL קצרות.

אם אתה מקבל 500 תגובות שגיאה מכתובות URL של load.php, בדוק את קבצי יומן השגיאות של שרת האינטרנט כדי לקבל מידע נוסף על השגיאות. נראה שיש בעיה עם כמה גרסאות PHP ו-Gentoo שגורמת ל-Apache לבצע segfault.^[1] זה יכול לקרות גם אם APC מופעל אצלך, הגדרת apc.serializer=php ב-php.ini עשויה לעזור.^[2]

מאז מדיה-ויקי 1.23, ייתכן שתסיימו עם דף הויקי עם רוב סגנונות העיצוב הספציפיים לוקטור, כמו סרגל צד הממוקם בסוף הדף. ייתכן שזה נגרם עקב הגדרה נמוכה של pcre.backtrack_limit בהפצות מסוימות כמו FreeBSD. ידוע שיש בעיות עם ערכים של 10,000. הגדל את הערך הזה ל-100,000, או לערך ברירת המחדל הנוכחי של 1,000,000.

מאז מדיה-ויקי 1.26, ייתכן שחלק מהעיצובים, ובמיוחד וקטור, סובלים מבעיה זו. אם אתם רואים את השגיאה Internal error Problematic modules: {"startup":"error"} בקונסולת השגיאות של הדפדפן שלכם, הסיבה הסבירה ביותר היא חוסר בהרשאות של מדיה-ויקי לכתוב לתיקייה הזמנית המוגדרת כברירת מחדל, בין אם משום של-PHP אין הרשאות כתיבה לתיקיית /tmp (C:\WINDOWS\TEMP ב-Windows), או משום שיש הגבלה של open_basedir והנתיב הזה לא כלול בו. ראה T119934. ניתן גם להגדיר $wgTmpDirectory אם אינך יכול לשנות הרשאות בתיקייה הזמנית המוגדרת כברירת מחדל של המערכת.

אם תקבל הודעת שגיאה זו לאחר השדרוג, עליך להפעיל את תסריט התחזוקה rebuildLocalisationCache.php עם האפשרות --force:

php rebuildLocalisationCache.php --force

אם אתה רואה זאת, נסה להריץ את תסריט התחזוקה rebuildLocalisationCache.php עם האפשרות --force:

php rebuildLocalisationCache.php --force

פעולה זו תאלץ את מדיה-ויקי לבנות מחדש את מטמון הלוקליזציה.

אם JavaScript אינו פועל (אחד התסמינים הוא שסרגל הכלים לעריכה אינו מופיע בעת עריכת דף), ייתכן שהסיבה לכך היא שגיאת JavaScript. פתח את קונסולת השגיאות של דפדפן האינטרנט שלך (בדרך כלל על ידי לחיצה על F12), טען מחדש את הדף ובדוק אם מופיעה שם הודעת שגיאה כלשהי. אם מוצגת שגיאה, בדרך כלל, הגדרת $wgShowExceptionDetails תיתן לך מידע נוסף. לפעמים הבעיה היא שתיקיית העבודה הזמנית של המערכת אינה ניתנת לכתיבה. במקרה כזה, ניתן גם להגדיר $wgTmpDirectory אם אינך יכול לשנות הרשאות בתיקיית העבודה הזמנית המוגדרת כברירת מחדל של המערכת.

אם אתה מקבל שגיאות כמו Uncaught SyntaxError: Unexpected token < או Error: SyntaxError: syntax error (...) Source Code: <script (...), הסיבה היא בדרך כלל שספק האחסון מזריק אוטומטית קוד HTML לצורך מעקב או פרסום בתוך התסריט Load.php , המשמש את ResourceLoader לטעינת התסריטים וה-CSS המשמשים את מדיה-ויקי. פתח פנייה לתמיכה עם ספק האחסון שלך בבקשה להשבית את הזרקה הזו. אם זה לא אפשרי, עליך להעביר את האתר שלך לספק אחסון אחר. זה קורה בדרך כלל אצל ספקי אחסון חינמיים.

נסה לבנות מחדש את מטמון הלוקליזציה:

php maintenance/rebuildLocalisationCache.php

מתוך שרשור זה.

It may be caused by wrong rewrite rules when configuring Short URLs. Try disabling them (and the related configuration variables of MediaWiki) to see if that solves the problem.

Another problem may be a limit imposed by the web server about how many data the server can receive on a single request. See Manual:Configuring file uploads#Set maximum size for file uploads for some configuration variables. If you have mod_security or suhosin installed, they may also be limiting the size of uploaded files, discarding the upload entirely without PHP noticing it.

Check also the upload_tmp_dir configuration directive from php.ini, and be sure that the folder has proper write permissions for the user account running PHP. On Windows, this directive often points to C:\Windows\TEMP, which may not be accessible in some circumstances. In that case, you can set up a different temp folder like C:\TEMP\ with proper permissions. To discard other problems, give temporarily all permissions to that folder (on Windows, add the local user group "Everyone" with full permissions), and then restrict the permissions as needed once you verify uploads are working.

Notice: Undefined index: tmp_name in /srv/www/htdocs/mediawiki/includes/WebRequest.php on line 1153
Notice: Undefined index: size in /srv/www/htdocs/mediawiki/includes/WebRequest.php on line 1140
Notice: Undefined index: error in /srv/www/htdocs/mediawiki/includes/WebRequest.php on line 1167

This is a problem with the PHP version your server is using. There have been several reports of this problem with PHP 5.3.8 on SLES11 sp2. You may need to upgrade PHP or recompile it yourself.

[core:error] The given path is misformatted or contained invalid characters: [client 127.0.0.1] AH00127: Cannot map GET /wiki/Special:SpecialPages HTTP/1.1 to file

This can be caused by various PHP bugs. One of them is when the wiki is installed in a NTFS junction. If that's not the problem, upgrading PHP to a newer version can help (see this forum thread)

This is a common issue for shared host which have mod_security enabled. To know if it's a problem with mod_security or not, create a simple test page and save it with a small text (something as simple as writing just a dot in the content). If the edit is saved, but other edits aren't, that's caused by mod_security. Ask your hosting customer support to disable it completely or the rules affecting your edits.

Parts of this page (those related to this section) are outdated. It was written for an older version of MediaWiki and may not apply to the most recent version. If you have checked or updated this page and found the content to be suitable, please remove this notice. (2020-04-02)

You may get a message like MediaWiki עושה שימוש בעוגיות כדי להכניס משתמשים למערכת. בדפדפן שלך העוגיות מבוטלות. יש להפעיל אותן ולאחר מכן לנסות שוב..

• You have $wgSessionsInMemcached set to true but MediaWiki can't connect to Memcached. Turn off this setting or check the Memcached configuration.
• A wrong cookie configuration. Configuration variables about cookies should work with their default values. Try to not override any of them.
• session_save_path() is not set correctly on the server, or the server doesn't have permissions to write to that path.
• If you use some sort of caching proxy in front of MediaWiki, check that it doesn't filter any cookie.
• session.referer_check() is wrongly set. You should normally leave it empty.

If images are not displayed on the pages, and manually opening the URL of any image results in an Internal Server Error page, the problem is most likely caused by the .htaccess file from the images directory. This configuration file contains some rewrite rules to prevent old Internet Explorer versions from being affected by a cross site scripting vulnerability. However, some hosts like strato.de prevents disallow the RewriteOptions directive in .htaccess, causing any request for a file in the images folder to fail with an error. If you can't enable rewrite rules on .htaccess file, you may need to comment-out or remove those lines from .htaccess, or the entire .htaccess altogether. See this thread.

If enabling the display of edits made by bots doesn't make them appear in Recent Changes, the problem is usually in one of the installed extensions, causing an error when Recent Changes are updated. The update of Recent Changes when performing an edit or other action is deferred until the page has been sent to the browser. However, an error can abort such updates, and the error not get displayed to the user. To detect such errors, Set up a debug log file (remember to disable it once you've completed the diagnosis), and save a new edit to a page. If an error happens, it should be logged there — but note it will also log a lot of other things, try to search for "error" or "exception". An error may give a stack trace of the execution, and it may point to an extension likely causing the error.

Information about pages contained in a category, links to other wiki pages and images embedded in pages are tracked in special tables. The update of such tables is not done immediately after the edit is saved, but deferred to the job queue for performance reasons. If it takes too long to update, you may need to adjust $wgJobRunRate , or try setting $wgRunJobsAsync to false in LocalSettings.php. This can happen in some installations, especially since MediaWiki 1.27 (see T142751).

Check that the "images" directory has permissions which allow writing. For example: chown -R www-data:www-data images and chmod -R 777 images.

You need to create an alias file. So, put something like this in your extension.json file:

	"ExtensionMessagesFiles": {
		"SpecialMyExt": "MyExt.alias.php"
	},
	"MessagesDirs": {
		"MyExt": [
			"i18n"
		]
	},

MyExt.alias.php

<?php
/**
 * Aliases for Special:Foo
 *
 * @file
 * @ingroup Extensions
 */

$specialPageAliases = [];

/** English (English) */
$specialPageAliases['en'] = [
   'MyExt' => [ 'MyExt' ],
];

Make sure you don't have a $wgMessagesDirs item with the same key. Keys of $wgExtensionMessagesFiles which are also in $wgMessagesDirs will be skipped.

To fix the warning, uncomment this line in LocalSettings.php:

#$wgCacheDirectory = "$IP/cache";

The function has been disabled in php.ini. This prevents using ImageMagick to resize images to create thumbnails. Either contact your hosting provider, or try to use gd instead of ImageMagick by setting $wgUseImageMagick to false.

There are several reasons for this error. One simple one is if the content of user.user_touched is empty or is set to a time in the future.

You might want to check if the server's time is set correctly and synchronized. Also check the contents of that column and fill the column with valid content e.g. with this SQL statement:

UPDATE `user` SET user_touched='20251006042935'
WHERE HEX(
	user_touched
)='0000000000000000000000000000';
-- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-- 28 zeroes

Where the date is in YYYYMMDDHHMMSS format for the current date/time. See phab:T247751.

If you recently upgraded MediaWiki, or recently installed or upgraded extensions, try running the update.php maintenance script. (See also מדריך:שדרוג .)

If that doesn't help, then you really may have ran into a bug in the software. Try to obtain more details about the query that fails (Manual:How to debug ) and file a bug .

Your system does not support /dev/urandom so the key was generated with mt_rand(). See $wgSecretKey .

Create a file called info.php with the single-line content <?php phpinfo(); and place this file in the web directory. Access it with your web browser. It will display the PHP version that is used by your web server.

memory_limit = 64M      ; Maximum amount of memory a script may consume (32MB)

• Install the right php-xml package for your distro. Example: sudo yum install php-xml
• Alternatively, change the MediaWiki 'preprocessor' class in LocalSettings.php (see $wgParserConf )

That issue seems to indicate it's a problem with a PHP code accelerator that doesn't match the installed version of PHP or it's outdated. Try upgrading the accelerator. report

Most likely, your text editor added a byte order mark (BOM) while you edited MediaWiki's PHP files, but any other content before the opening <?php causes the same problem. This usually happens with LocalSettings.php - but see error message for exact file. Note that BOMs are invisible in most text editors. To remove the BOM, edit the file with something better than Windows Notepad, but if you don't really have time - open the file with it and choose Save as..., then choose "Unicode (UTF-8 Without signature) - Codepage 65001" as file type.

If you get Strict Standards: errors in the HTML output, that's because your error_reporting configuration variable of PHP is set to E_ALL, but since PHP 5.4.0, E_STRICT became part of E_ALL. E_STRICT are not errors, but warnings about code interoperability and forward compatibility of PHP code, and they shouldn't be visible in production environments.

Just add your time zone to LocalSetting.php, e.g.

$wgLocaltimezone = 'Europe/Berlin';

The following does not work in all cases. It may be better to put this in the php.ini which must be present in all affected directories.

You may turn off E_STRICT errors putting the following line of code inside your LocalSettings.php , or in case a line with the error_reporting function exists, replace it with:

error_reporting( E_ALL & ~( E_STRICT | E_NOTICE ) );

error_reporting( 0 );

See also: Setting error reporting in PHP.

If nothing works, please check at the start of your LocalSettings.php file: If that error happened on the setup process, the LocalSettings.php that it generated could have included the error message at the top of it (example). If that was what happened, edit the file removing everything before "<?php" and verify there's nothing (even whitespace) before "<?php".

This could happen if you upgraded and you have a StartProfiler.php file in the root MediaWiki installation directory, probably because you enabled profiling in an old installation. To solve the issue simply remove that file.

• On a Linux machine, use chown or chgrp to correct the file permissions of LocalSettings.php.
• On some Linux machines, temporarily disable SELinux by running the command sudo setenforce 0.

Make sure that the webserver user, who by default is named IUSR, is allowed to access the C:\Windows\TEMP directory. At least read and write permissions are necessary.

You need to Grant permissions on wikidb.*.

GRANT ALL ON wikidb.* TO 'username'@'localhost' IDENTIFIED BY 'password';

or if your Web Server is on a different box than your DB server - you have to configure remote access to MySQL and grant differently

GRANT ALL ON wikidb.* TO 'username'@'192.168.0.x' IDENTIFIED BY 'password';

NOTE: Replace 192.168.0.x with your Webserver's IP. Also note that the apostrophes (') need to stay.

PHP MySQL support is not installed/enabled - See https://php.net/book.mysqli. Depending on your operating system, you may need to install an additional package. For example, on debian/ubuntu run sudo apt install php-mysql.

If you are using a different FTP client than FileZilla to upload files to your server, be sure to configure the client to not force uppercase or lowercase filenames. MediaWiki filenames are case-sensitive.

The MediaWiki package includes a lot of files, spread over dozens of directories. Be careful when uploading. If the transfer is interrupted, you might have missing or incomplete files. You may have to retry your upload several times, especially if you have an unreliable connection.

If your webserver produces a "500 Internal Error" at the beginning of the install process, you may need to change the permissions on the mw-config directory to 755. If you have changed the permissions for the config directory and still get an unwritable error try changing the owner to Apache.

chown -R apache:apache /var/www/html/mediawiki/*

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;

Linux distributions which support SELinux ('Security Extensions') are becoming more widespread. On such systems, PHP scripts will still be unable to write to the config directory, after you have set the normal file permissions. You will also need to use the 'chcon' command to change the SELinux file type.

If you are running the MediaWiki software on a free site that requires banners or prefix advertising, this may cause MediaWiki not to work, and appear to only generate empty pages beyond the banner advertising. You will have to contact your host to make them make their advertising compatible with MediaWiki, or choose a different host.

dpkg --list | grep php-mysql

If you need to install the php5-mysql module enter:

apt-get install php-mysql

/etc/init.d/apache2 restart

If you are using a hosting service, the database name and database username may have an extra prefix (normally the userid given by your hosting provider). For example, if you have created a database named db01 with username u01 and your userid is ocom (given by your hosting provider), you should enter the database name and database username as ocom_db01 and ocom_u01 respectively.

The MySQL manual has a good set of pages on dealing with common errors (such as these). Visit the page for links to documentation for other versions of MySQL.

• GNU diff3 not found
• Git version control software not found
• ImageMagick not found

PHP must have access to /usr/bin. In php.ini (probably /etc/php/php.ini), add :/usr/bin/ to open_basedir config variable as below:

open_basedir = /srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/:/var/www/:/usr/bin/

To disable GIT set $wgGitBin to a path that's allowed but doesn't exist.

$wgGitBin = "";

This is usually an issue with the configuration of your web server software and unrelated to MediaWiki itself. See for example this Stackoverflow thread or other web server forums.

This can also happen when $wgForceHTTPS is set to true, and somehow MediaWiki isn't properly detecting the protocol used by the client, and keeps sending a redirect to https:. This may happen when MediaWiki is set behind a reverse proxy that isn't setting the X-Forwarded-Proto HTTP header to https.

Might e.g. happen on upgrading from MW 1.27 to another version. If there is no database content at all you might see this message. See phab:T236671.

This may happen if you didn't specify the same $wgDBprefix as your original installation, causing MediaWiki to not find its tables. Check the existing tables on the database and see if they all share a common prefix, and update that setting accordingly.

Another cause may be that you set an empty database. Reinstall the database content from a backup and proceed with migrating.

Some upgrades cannot be performed without an intermediary upgrade. For instance, to upgrade from a wiki older than 1.33 to MW 1.39.1, you will need to upgrade to 1.35 first. See task phab:T326071.

This error message can also be a red herring. It may appear when you are trying to update an empty database, without tables. Create the database first by installing the wiki .

• Manual:Config script#Installation errors
• Manual:How to debug