Manual:Genel hatalar ve belirtiler

Ayrıca bakınız: Manual:How to debug

Boş bir sayfa görüyorsunuz

Ekranda boş beyaz bir sayfa görünmesi, ekrana yazdırılmayan bir PHP hatasını gösterir. Bunu zorlamak için, LocalSettings.php dosyasına, satırının altına aşağıdaki satırları ekleyin:

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

Ayrıca, PHP.ini içinde bir değere error_log değeri atayabilir ve neler olup bittiğini öğrenmek için PHP hata günlüğünü okuyabilirsiniz. Bazı durumlarda, PHP hataları web sunucusu hata günlüğüne de kaydedilebilir.

Hata raporları şunları içerebilir:

• "Uyarı [...] Sistem saat dilimi ayarlarına güvenmek güvenli değildir. date.timezone ayarını veya date_default_timezone_set() işlevini kullanmanız *gereklidir*." php.ini içinde date.timezone = ile doğru ayarlanıp ayarlanmadığını (veya hiç ayarlanıp ayarlanmadığını) kontrol edin.
• Bazı dosyalar eksik olarak bildirilebilir (örneğin, /includes klasörünüzdeki media klasörü artık mevcut değilse, gerekli bir görüntüleme işleminin "akışı açılmadı" mesajını alabilirsiniz). Bu durumun geçerli olup olmadığını görmek için MediaWiki'deki orijinal kurulum paketini (uygun sürümü kullandığınızdan emin olun) kontrol edin. Eğer öyleyse, eksik dosyaları paketten MediaWiki dizininize kopyalamanız yeterlidir. Gerektiğinde önbelleği yenilemek ve web sunucusunu yeniden başlatmak gerekebilir.
• MySQL soketi bulunamadı. Eğer LocalSettings.php doğru MySQL soketine ayarlanmış ancak php.ini ayarlanmamışsa, web sunucusundan veya PHP'den herhangi bir hata çıktısı olmadan boş bir ekranla sonuçlanabilir. Çözüm, php.ini dosyasındaki mysql.default_socket girdisini güncellemek.

Birçok kişi, yeni vikilerine madde gönderdikten sonra son sürümlerde boş sayfalarla karşılaştıklarını bildiriyor. Muhtemel nedenlerden biri, varsayılan PHP kurulumlarındaki bellek sınırıdır (genellikle 8 MB). Lütfen PHP ve/veya Apache hata günlüklerinizi kontrol edin. Bu ayarı değiştirmek için /etc/php.ini dizini düzenleyin ve "memory_limit" ayarını artırın. Örneğin, boyutu 32 MB'a çıkarmak için mevcut metni memory_limit = 32M ile değiştirin. Bu değeri değiştirdikten sonra web sunucunuzu yeniden başlatmayı unutmayın.

Bellek sınırı, LocalSettings.php dosyanızda da ayarlanmış olabilir. memory_limit ayarını içeren satırı bulun ve gerektiği kadar artırın. Eğer 1.15.1 sürümünü kullanıyorsanız 20 MB yeterli olmayabilir. Örneğin "memory_limit = 32M" olarak değiştirin. Bu değişiklik, Apache'yi yeniden başlatmanızı gerektirmez.

Eğer sayfa belirli bir işlem sırasında (örneğin 30 saniye) yüklenirken takılı kalıyorsa ve ardından boş bir sayfa veya HTTP 500 hatası veriyorsa, sorun bir sunucuya bağlanırken yaşanan zaman aşımından kaynaklanıyor olabilir. Bu, veritabanı sunucusu olabilir veya belirli bir işlem yapılırken gerçekleşirse, e-posta sunucusu olabilir (eğer e-posta ayarlarını yapılandırdıysanız). E-posta sunucusuysa, MediaWiki çalıştıran sunucudan bağlanıp bağlanamayacağınızı kontrol edin, örneğin Telnet istemcisini $wgSMTP üzerinde yapılandırılan sunucuya ve bağlantı noktasına çalıştırın ve bağlanıp bağlanamayacağını görün.

Sayfa içeriğini kısa bir süre görebiliyorsanız ve aniden tüm sayfa boş kalıyorsa, sorun büyük olasılıkla vikinin betiklerden birinde bulunan document.write, document.writeln veya document.open JavaScript komutundan kaynaklanmaktadır. Bunun böyle olup olmadığını kontrol etmek için tarayıcı konsolunu açabilir (F12 tuşuna basabilir) ve sayfayı yeniden yükleyebilirsiniz. Ağ sekmesinde HTTP 200 durumu görünüyorsa ve aktarım birkaç kilobayt boyutundaysa, sorun büyük olasılıkla budur. Bunlar, Document arayüzünün eski yöntemleridir ve sayfa HTML'sinin dışında kullanıldığında tüm sayfanın boş kalmasına neden olurlar ve vikinin JavaScript sayfalarında bulunabilirler. HTML spesifikasyonunun kendisi tarafından da belirtildiği gibi, bunların kullanımı kesinlikle önerilmemektedir. Tarayıcınızda JavaScript'i devre dışı bırakabilir veya bozuk betiklerini düzeltene kadar bu betiklerini devre dışı bırakmak için $wgUseSiteJs ve $wgAllowUserJs değişkenlerini false olarak ayarlayabilirsiniz.

MediaWiki Hataları

Küçük resimler çalışmıyor ve/veya görünmüyor

Bu bölümde, küçük resimlerin oluşturulmaması veya görüntülenmemesiyle ilgili sorunlar ve çözümler listelenmiştir.

Küçük resim oluşturulurken hata oluştu: Dosya eksik:

Bu durum, aşağıdaki bölümde açıklandığı gibi, küresel değişkenlere yanlış değerler atanmasından kaynaklanabilir:

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

srcset yerel ayarında ondalık nokta hatası

Resim küçük resimleri görünmüyorsa ve sayfalarda herhangi bir hata da görünmüyorsa, sayfanın HTML kaynak koduna bakın ve "srcset" ifadesini arayın. Eğer gibi bir 1,5x yerine 1.5x görünüyorsa, sorun T181987 görevinden kaynaklanıyordur ve bunu LocalSettings.php dosyasına eklemelisiniz:

setlocale(LC_NUMERIC, "C");

SVG

Ayrıca bakınız: Manual:Image administration#SVG

Öncelikle, $wgSVGConverter ayarınızı belirleyin. Varsayılan olarak, dönüştürme için ImageMagick kullanılacak şekilde ayarlanmıştır.

ImageMagick'i kullanmak

En az ImageMagick 6.x.x sürümüne ihtiyacınız var. $wgImageMagickConvertCommand değişkeninizin geçerli olduğundan emin olun. Genel ayarlar şunlardır:

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

Eğer işe yaramazsa, $wgSVGConverterPath değişkeni ayarlamayı deneyin.

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

Paylaşımlı sunucular, farklı kullanıcıların ihtiyaçlarını karşılamak için farklı ImageMagick sürümleri sunabilir. Lütfen 6.x.x sürümünü kullanın.

• ImageMagick sürümünü belirlemek için, barınma sağlayıcınızın yardım dosyalarında arama yapın veya /usr/bin/convert --version ya da /usr/local/bin/convert --version komutunu kullanarak tespit edin.
• GoDaddy Linux paylaşımlı sunucularında, Sürüm 5.5.6 için "/usr/bin/convert" ve Sürüm 6.2.8 için "/usr/local/bin/convert" kullanılır.

ImageMagick ile küçük resim oluşturma işlemi "Bellek tahsisi başarısız oldu" veya "/bin/ulimit4.sh: Bölümleme hatası /usr/bin/convert ..." gibi bir web sunucusu hata günlüğü mesajıyla başarısız olursa, $wgMaxShellMemory değerinin artırılması gerekebilir.

Yolda ASCII olmayan karakterler eksik olduğunda

• locale -a komutunu çalıştırarak sunucunuzda UTF-8 yerel ayarlarının kullanılabilir olup olmadığını kontrol edin.
• Eğer mevcut değilse, locale-gen en_US.utf8 girin veya ülkeniz için UTF-8 ile yerel ayarları girin ve buna göre $wgShellLocale değerini değiştirin.

Windows'ta IIS/FastCGI kullanırken, kullanılan konuk hesabının C:\Windows\System32\cmd.exe üzerinde yürütme iznine de sahip olması gerekir, aksi takdirde "Fork oluşturulamadı" hatası alırsınız.

Batik'i kullanmak

MediaWiki, Linux altında kabuk komutlarına zaman ve bellek sınırlamaları getiriyor. "VM başlatılırken hata oluştu, Nesne yığını için yeterli alan ayrılamadı, Java sanal makinesi oluşturulamadı." hatası alıyorsanız, $wgMaxShellMemory değerini artırmayı deneyin.

rsvg kullanma

Bazı Linux ve BSD kurulumlarında rsvg'nin adı değiştirilir:

Ayarı yerine (varsayılan)

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

ayarlamak istediğiniz

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

JPEG

Belirti: Gri bir kutu içinde yer alan hata mesajı:

Error creating thumbnail: Invalid thumbnail parameters

One cause: the number of pixels in the original image exceeding $wgMaxImageArea . The default value 1.25e7 is too small for many modern cameras. Too bad the diagnostic really doesn't hint at the problem.

You can increase the value of $wgMaxImageArea or switch to using ImageMagick which evades this restriction (set $wgUseImageMagick and $wgImageMagickConvertCommand ).

Large images can take significant processing time. It may be good policy to cap the size of images.

JPEG (GD kullanarak)

Symptom: This error message within a grey box:

Error creating thumbnail: Incomplete GD library configuration: missing function imagecreatefromjpeg

Some PHP 4.x and 5.x versions of PHP have a bug where libjpeg is detected but not enabled during the ./configure step; this is fairly prevalent on Red Hat/RHEL/CentOS systems. If you don't want to use ImageMagick, the fix for this is to recompile PHP. First, find out (from phpinfo()) what the existing ./configure switches were, and add --with-jpeg-dir before --with-gd.

make clean
./configure --with-various-switches --with-jpeg-dir --with-gd --with-more-switches
make
make test
# switch to root
make install

Afterwards, restart the webserver (for Apache on Red Hat: service apache stop then service apache start ). To test, simply view the File:... page again (no need to upload again). For more information see the comments on PHP: imagecreatefromjpeg (function synopsis)

Küçük resim kaydedilemiyor

If you get the error "Error generating thumbnail / Error creating thumbnail: Unable to save thumbnail to destination" and the $wgUploadDirectory directory has the correct permissions (at all levels), check that $wgTmpDirectory actually exists. (Unlike some path variables such as $wgCacheDirectory , $wgTmpDirectory is not created at runtime.) A more detailed error message may be available if you turn on logging with $wgDebugLogFile .

This error can also occur when read only mode ($wgReadOnly ) has been set in LocalSettings.php. You can try to remove $wgReadOnly to see if that solves the issue for you.

Küçük resim oluşturulurken hata oluştu. Hata kodu: 25

If you get "Error creating thumbnail Error code: 25" with ImageMagick, try increasing $wgMaxShellFileSize .

Küçük resim dosyalarını manuel olarak ekleme

In situations in which it's not feasible to create the thumbnails dynamically on request (e.g. for very large images, "Error creating thumbnail: unable to extend cache", "Error creating thumbnail: convert: no images defined", and similar), it is possible to manually add the thumbnail files. This involves creating the smaller images in the desired sizes and uploading them to the thumb/ directory in $wgUploadDirectory .

For example, a file that has uploaded to:

images/f/f8/Foo.png

should have its thumbnails at:

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

The pixel size is the horizontal dimension. An example Bash script for creating thumbnails is available at Phabricator:P7049.

Küçük resim oluşturulurken hata oluştu: Hata kodu: -1 on OVH mutualized hosting

For unidentified reason, creation of thumbnails on some mutualized OVH hosting are failing with this error, even if running the command in SSH shell works.

Solution is to specifically prevent from using ImageMagick by setting $wgUseImageMagick to false in LocalSettings.php:

$wgUseImageMagick = false;

Üzgünüm! Oturum verilerinin kaybı nedeniyle düzenlemenizi işleyemedik. Lütfen tekrar deneyin. Hala çalışmıyorsa, çıkış yapıp tekrar giriş yapmayı deneyin.

Anasayfa: Manual:How to debug/Login problems

İçerik Sınırları

If your Apache server has the Hardened PHP patch, you may need to edit several variables in your /etc/php.ini file if you wish to have wiki pages with large amounts of content. In particular, consider the settings for varfilter.max_value_length, hphp.post.max_value_length, hphp.request.max_value_length. The default settings may limit your pages to less than 10k or 64k in size.

Another possibility is if your Apache server is using mod_security that could be interfering with MediaWiki. You will need to turn it off for MediaWiki to work properly.

Geçerli bir kullanıcı adı belirtmediniz / Sayfa düzenlemeleri ve önizlemeleri tamamen boş / Yüklenemiyor

This is caused by something truncating or dropping POST data from the browser to the web server.

In at least one instance, this was caused by post_max_size and upload_max_filesize in php.ini being set too high (2048M). Setting them back to more sane values (8M) fixed it. Apparently, no POST data was actually making it through to MediaWiki.

In another instance, mod_auth_sspi was interfering with http posts to MW. Using FireFox and entering domain credentials would work fine, but MSIE would fail. This is a known defect in mod_auth_sspi 1.0.4.

You have a few options to make this work:

• Set SSPIOfferSSPI off ← users will get prompted and have to enter domain credentials, same as BASIC mode
• Set SSPIPerRequestAuth on ← I don't see how this is a healthy configuration but it worked (except over the high latency connection I'm forced to contend with)
• Downgrade to 1.0.3 but it's basically the same as #2 above.

Wiki, stiller uygulanmadan görünüyor ve resimler eksik

If the wiki looks fine if you browse it from the same server where it's being hosted but it appears without CSS styles applied (no colors, no backgrounds, no images, very minimal formatting, etc) if you access it from other machines (or some of them), the most probable cause is that the server is having problems with determining the IP or host name that is being used to access it, or it's misconfigured. This causes URLs to styles and images to be generated using the loopback IP address 127.0.0.1, localhost, or a host name not known outside of the server. You can see the source code of any page and check how URLs look like and what happens if you try to access them directly via your browser.

The solution is to manually specify the $wgServer variable to the host name that everyone will use to access the wiki.

If your wiki is being accessed from an internal network and an external one, you may need to use the external address for $wgServer. Don't forget the port number if you are using a non-standard port as may by the case if your ISP has blocked port 80 (Example: $wgServer = "http://example.domain.com:8080";)

If styles aren't applied even when browsing the wiki from the server where it's hosted, the problem may be a PHP error on the ResourceLoader load.php script. Try to browse the load.php file of your MediaWiki installation with your web browser and see if it displays any errors or just a blank page (see #You see a blank page). You should see a comment similar to /* No modules requested. Max made me put this here */. If so, it may be a problem with the web server's .htaccess file.

If you instead see a 404 Not found error, it may be a problem with the web server's rewrite rules if you attempted to configure Short URLs.

If you are getting 500 error responses from load.php urls, check the webserver's error log files to get more information of the errors. There seems to be a problem with some PHP versions and Gentoo that causes Apache to segfault. This can also happen if you have APC enabled, setting apc.serializer=php in php.ini might help.

Since MediaWiki 1.23, you may end with a wiki with most of the Vector-specific skin styles, like sidebar placed at the end of the page. That may be caused by a low pcre.backtrack_limit set up on some distributions like FreeBSD. It's known to have problems with values of 10.000. Increase that value to 100.000, or the current default of 1.000.000.

Since MediaWiki 1.26, some skins, and specially Vector, may have this problem. If you see the error Internal error Problematic modules: {"startup":"error"} in the error console of your browser, most likely cause is the lack of permissions of MediaWiki to write to the default temp folder, either because PHP has no permissions to write to /tmp (C:\WINDOWS\TEMP on Windows), or because there's an open_basedir restriction and that path isn't included on it. See T119934. You can also set $wgTmpDirectory if you are unable to change permissions on the system's default temp directory.

Hata: geçersiz sihirli sözcük "speciale"

MediaWiki sürümü:

≥ 1.20

If you get that error message after upgrading, you must run the rebuildLocalisationCache.php maintenance script with the --force option:

php rebuildLocalisationCache.php --force

Localised strings show their message ID instead of a localized result

If you are seeing this, try running the rebuildLocalisationCache.php maintenance script with the --force option:

php rebuildLocalisationCache.php --force

This will force MediaWiki to rebuild the localisation cache.

Düzenleme araç çubuğu eksik, JavaScript çalışmıyor

Since MediaWiki 1.32 , MediaWiki no longer has a "JavaScript-powered" wikitext toolbar built in. The old "bulletin board style toolbar", known as "the 2006 wikitext editor", has been removed, and instead sysadmins will be required to choose one (or more) of the several extensions available for this purpose if they need the functionality. The MediaWiki "tarball" releases have included the replacement extension for this, the WikiEditor extension aka "the 2010 wikitext editor", for many years now. Be sure this extension has been installed.

If JavaScript is not working (one of the symptoms is the edit toolbar not appearing when editing a page) it may be caused by a JavaScript error. Open the error console of your web browser (usually by hitting F12), reload the page and see if any error message appears there. If it displays an error, usually, setting $wgShowExceptionDetails would give you more information. Sometimes the problem is that the system's temp directory is not writable. In that case, you can also set $wgTmpDirectory if you are unable to change permissions on the system's default temp directory.

If you get errors like Uncaught SyntaxError: Unexpected token < or Error: SyntaxError: syntax error (...) Source Code: