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

See also: Manual:How to debug

אתה רואה דף ריק

דף לבן ריק מציין שגיאת PHP שאינה מודפסת למסך. כדי לכפות זאת, הוסיפו את השורות הבאות לקובץ LocalSettings.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

באג בנקודה עשרונית ב־srcset locale

אם תמונות ממוזערות פשוט לא מופיעות, ואין שגיאה גלויה בדפים אלה, עיין בקוד מקור ה־HTML של הדף וחפש "srcset". אם מצאת משהו כמו , שבו הוא מופיע כ־1,5x במקום כ־1.5x, הבעיה נגרמת על ידי T181987, ועליך להוסיף זאת ל־LocalSettings.php:

setlocale(LC_NUMERIC, "C");

SVG

See also: Manual:Image administration#SVG

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

שימוש ב־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, אחרת תקבלו שגיאת "לא ניתן למזג".

שימוש ב־Batik

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

שימוש ב־rsvg

בחלק מהתקנות לינוקס ו-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' );

JPEG

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

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

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

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

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

JPEG (שימוש ב-GD)

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

שגיאה ביצירת תמונה ממוזערת: הגדרות ספריית 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

אם אתה מקבל "שגיאה ביצירת תמונה ממוזערת קוד שגיאה: 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.

שגיאה ביצירת תמונה ממוזערת: קוד שגיאה: -1 באירוח הדדי של OVH

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

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

$wgUseImageMagick = false;

סליחה! לא הצלחנו לעבד את העריכה שלך עקב אובדן נתוני סשן. אנא נסה שוב. אם זה עדיין לא עובד, נסה להתנתק ולהיכנס שוב.

עמוד ראשי: Manual:How to debug/Login problems

מגבלות תוכן

אם לשרת ה-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. זה יכול לקרות גם אם APC מופעל אצלך, הגדרת apc.serializer=php ב-php.ini עשויה לעזור.

מאז מדיה-ויקי 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 אם אינך יכול לשנות הרשאות בתיקייה הזמנית המוגדרת כברירת מחדל של המערכת.

שגיאה: מילת קסם לא חוקית 'speciale'

MediaWiki version:

≥ 1.20

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

php rebuildLocalisationCache.php --force

מחרוזות מקומיות מציגות את מזהה ההודעה שלהן במקום תוצאה מקומית

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

php rebuildLocalisationCache.php --force

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

סרגל כלים לעריכה חסר, JavaScript לא עובד

מאז MediaWiki 1.32 , למדיה-ויקי יש לאחרונה סרגל כלים מובנה של תחביר ויקי "המופעל על ידי JavaScript". סרגל הכלים הישן של "לוח המודעות", המכונה "עורך תחביר הויקי משנת 2006", הוסר, ובמקום זאת מפעילי המערכת יידרשו לבחור אחת (או יותר) מההרחבות הזמינות למטרה זו אם הם זקוקים לפונקציונליות. מהדורות ה-"tarball" של מדיה-ויקי כללו את ההרחבה החלופית לכך, ההרחבה WikiEditor המכונה "עורך תחביר הויקי משנת 2010", כבר שנים רבות. ודא שהרחבה זו הותקנה.

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

אם אתה מקבל שגיאות כמו Uncaught SyntaxError: Unexpected token < או Error: SyntaxError: syntax error (...) Source Code: