Lost Media Wiki Forbidden You May Try Again

You see a blank page

A blank white page indicates a PHP error which isn't existence printed to the screen. To force this, add the following lines to the LocalSettings.php file, underneath the <?php:

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

You tin also set up a value for error_log in PHP.ini and read the PHP mistake log to detect out what's going on. In some cases, PHP errors might too be recorded in the web server error log.

Error reports may include:

• "Warning [...] Information technology is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function." Check if engagement.timezone = is set correctly (or set at all) in PHP.ini.
• Certain files may be reported equally missing (e.k. when the media folder in your /includes folder is no longer present, yous may receive the message that a required imaging process "failed to open up stream"). Check the original installation package at MediaWiki (make certain to consult the appropriate version) to come across if this is the instance. If then, but copy the missing files from the package into your MediaWiki directory. It may exist necessary to refresh the cache and restart the webserver afterwards.
• MySQL socket cannot exist institute. If LocalSettings.php is set to the correct MySQL socket just php.ini is not, it may result in a blank screen with no fault output from the webserver or php. The fix is to update the mysql.default_socket entry in the php.ini file.

Many people report blank pages in recent versions after submitting articles to their new wiki. A likely cause is the retentivity limit in default php installations (usually eight MB). Please check your PHP and/or Apache error logs. To change this setting edit /etc/php.ini and increase the "memory_limit" setting. For example to raise it to 32 MB replace the existing text with "memory_limit = 32M". Make sure to restart your webserver later on you have changed this value.

The memory limit may too have been set in your LocalSettings.php file. Scan for the line containing the memory_limit setting and increase as needed. 20M may not be plenty if yous are running version 1.xv.1. Alter it to e.one thousand. "memory_limit = 32M". This change does not require you to restart apache.

If the page merely hangs loading during some fourth dimension (similar 30 seconds) doing a specific activity, and and then it results in a blank page or HTTP 500 error, the problem is a timeout connecting to some server. This may be the database server, or if information technology happens doing a specific action, the mail server (if you have configured email settings). If information technology's the email server, check if you can connect to information technology from the server running MediaWiki, for example, running the Telnet client to the server and port configured on $wgSMTP and seeing if it tin connect.

If you tin can see the page contents briefly, and suddenly the entire page goes blank, about likely the problem is caused by the presence of a certificate.write JavaScript teaching in one of the scripts of the wiki. Y'all tin can bank check if that's the instance if you open your browser console (hit F12) and reload the folio. If the network tab returns a HTTP 200 status, and the transfer is of several kilobytes, it's very probable this is the problem. document.write is legacy code that causes the entire page to become bare if it'south used outside of the page HTML, and it may be present on the wiki's JavaScript pages. You can disable JavaScript on your browser, or fix $wgUseSiteJs and $wgAllowUserJs to simulated to disable those scripts until you fix the broken scripts.

MediaWiki Errors

All pages have no content, but when editing a page the wiki text is there

Optionally with those error messages:

PHP Warning: preg_replace(): Compilation failed: grouping proper noun must starting time with a   non-digit at showtime iv in /var/world wide web/wiki/htdocs/includes/MagicWord.php        

This is acquired by a change in PCRE 8.34. You need to update MediaWiki to a supported version. Run into Updating to PCRE 8.33 or College. The problem is solved in all currently supported versions of MediaWiki (encounter chore T60640).

See written report: Topic:Rz2zo0m88rrxqrfn and Thread:Project:Support_desk/MediaWiki_don't_work_with_PCRE_8.34_(ii)

Epitome Thumbnails non working and/or actualization

This department lists bug and solutions relating to thumbnails non rendering or displaying.

Fault creating thumbnail: File missing:

This might happen due to wrong values of global variables as explained in:

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

Decimal-betoken in srcset locale bug

If prototype thumbnails but don't appear, and there's no mistake visible on those pages, look at the HTML source of the page and search for "srcset". If you find something like <img ... srcset="/images/thumb/File.png/600px-File.png ane,5x, /images/pollex/File.png/800px-File.png 2x">, where it appears 1,5x instead of ane.5x, the problem is acquired by task T181987, and you lot should add together this to LocalSettings.php:

                        setlocale            (            LC_NUMERIC            ,            "C"            );          

Exist certain there'southward no $wgShellLocale defined in your LocalSettings.php, or add also this:

                        $wgShellLocale            =            "C.UTF-8"            ;          

SVG

See as well: Manual:Prototype administration

Beginning, decide your $wgSVGConverter setting. Past default, it is set to use ImageMagick for conversion.

Using ImageMagick

You need at least ImageMagick 6.x.x. Ensure that your $wgImageMagickConvertCommand variable is valid. Mutual settings are:

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

If information technology does not work, try setting $wgSVGConverterPath .

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

Shared hosts may provide different ImageMagick versions to run into the needs of different users. Delight use version 6.10.x.

• To decide the version of ImageMagick, search the assistance files of your host provider, or apply /usr/bin/convert --version or /usr/local/bin/catechumen --version to detect.
• On GoDaddy Linux shared hosts, "/usr/bin/convert" for Version 5.5.half dozen and "/usr/local/bin/convert" for Version 6.ii.8.

If generating thumbnails with ImageMagick fails with a web server mistake log message like "Memory allocation failed" or "/bin/ulimit4.sh: Sectionalization fault /usr/bin/convert ...", the $wgMaxShellMemory value may demand to be increased.

When the path is missing non-ASCII characters

• Check if UTF-viii locals are available on your server past running locale -a
• When it'southward not bachelor run locale-gen en_US.utf8 or put in the locales with UTF-eight for your country and change the value for $wgShellLocale accoring to this

When using IIS/FastCGI on Windows, the invitee account that is used likewise needs execute permission on %SYSTEMROOT%\System32\cmd.exe otherwise yous'll receive an "Unable to Fork" error.

Using Batik

MediaWiki places time and retention limits on trounce commands nether Linux. If you receive the mistake "Mistake occurred during initialization of VM, Could not reserve plenty space for object heap, Could non create the Java virtual machine.", endeavor increasing the value of $wgMaxShellMemory .

Using rsvg

On some Linux and BSD installations rsvg is renamed:

Instead of setting (default)

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

you would like to set

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

JPEG

Symptom: This mistake message inside a grey box:

Mistake creating thumbnail: Invalid thumbnail parameters

One crusade: the number of pixels in the original prototype exceeding $wgMaxImageArea . The default value 1.25e7 is likewise small-scale for many modern cameras. Likewise bad the diagnostic actually doesn't hint at the problem.

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

Large images can take meaning processing fourth dimension. Information technology may be proficient policy to cap the size of images.

JPEG (using GD)

Symptom: This error bulletin within a grey box:

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

Some PHP 4.ten and 5.x versions of PHP have a problems where the libjpeg is detected but not enabled during the ./configure step; this is fairly prevalent on Ruddy Hat/RHEL/CentOS systems. The ready for this (if y'all don't want to use ImageMagick) is to recompile PHP. Starting time, find out (from phpinfo()) what the existing ./configure switches were, and add together --with-jpeg-dir before --with-gd.

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

Subsequently, restart the webserver (for Apache on Cerise Chapeau: service apache stop so service apache start ). To test, simply view the File:... page again (no need to upload again). For more than data see the comments on PHP: imagecreatefromjpeg (function synopsis)

Unable to relieve thumbnail to destination

If yous get the error "Mistake generating thumbnail / Error creating thumbnail: Unable to salve thumbnail to destination" and the $wgUploadDirectory directory has the correct permissions (at all levels), bank check that $wgTmpDirectory really exists. (Unlike some path variables such every bit $wgCacheDirectory, $wgTmpDirectory is non created at runtime.) A more detailed error bulletin may be available if you plow on logging with $wgDebugLogFile.

Error creating thumbnail Error code: 25

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

Manually adding thumbnail files

In situations in which information technology's not feasible to create the thumbnails dynamically on request (eastward.g. for very large images, "Error creating thumbnail: unable to extend enshroud", "Mistake creating thumbnail: convert: no images defined", and like), information technology is possible to manually add the thumbnail files. This involves creating the smaller images in the desired sizes and uploading them to the pollex/ 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 instance Bash script for creating thumbnails is available at Phabricator:P7049.

Error creating thumbnail: Error code: -ane on OVH mutualized hosting

For unidentified reason, creation of thumbnails on some mutualized OVH hosting are failing with this error, fifty-fifty if running the control in SSH crush works.

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

$wgUseImageMagick = false;        

Pitiful! Nosotros could non process your edit due to a loss of session data. Delight endeavour over again. If it all the same doesn't work, endeavour logging out and logging back in.

See Transmission:How to debug/Login problems.

Content Limits

If your Apache server has the Hardened PHP patch, you may need to edit several variables in your /etc/php.ini file if y'all wish to take wiki pages with big amounts of content. In item, consider the settings for varfilter.max_value_length, hphp.post.max_value_length, and 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 exist interfering with mediawiki. You lot will demand to plow information technology off for mediawiki to work properly

You have not specified a valid user name / Completely blank page edits and previews / Unable to upload

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

In at least one example, this was caused past 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 Postal service 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 piece of work fine, but MSIE would fail. This is a known defect in mod_auth_sspi one.0.iv

Yous have a few options to make this piece of work:

• Set up SSPIOfferSSPI off ← users will get prompted and take to enter domain credentials, aforementioned as Bones mode
• Set SSPIPerRequestAuth on ← I don't run into how this is a healthy configuration simply it worked (except over the high latency connection I'g forced to fence with)
• Downgrade to i.0.iii just information technology's basically the aforementioned as #ii higher up.

The wiki appears without styles applied and images are missing

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

The solution is to manually specify the $wgServer variable to the host proper noun that everyone will use to admission the wiki.

If your wiki is beingness accessed from an internal network and an external i, you may need to use the external accost for $wgServer. Don't forget the port number if you are using a non-standard port as may by the case if your Internet service provider has blocked port lxxx (Instance: $wgServer = "http://example.domain.com:8080" ; )

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

If y'all instead see a 404 Non found error, information technology may be a problem with the web server'due south rewrite rules if you lot attempted to configure Brusk URLs.

If you're getting 500 mistake responses from load.php urls, check the webserver's error log files to get more information of the errors. In that location seems to be a problem with some PHP versions and Gentoo that causes apache to segfault^[i]. This can likewise happen if you have APC enabled, setting apc.serializer=php in php.ini might assist^[2].

Since MediaWiki ane.23, you may end with a wiki with near of the Vector-specific skin styles, like sidebar placed at the end of the folio. That may be caused by a low limit of pcre.backtrack_limit set upwards on some distributions like FreeBSD. It'south known to have problems with values of 10000. Increase that value to 100000, or the current default of 1000000.

Since MediaWiki 1.26, some skins, and specially Vector, may have this problem. If y'all see the error Internal mistake Problematic modules: {"startup":"error"} in the error console of your browser, near 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 in that location'southward an open_basedir restriction and that path isn't included on it. See chore T119934. Yous tin can also set $wgTmpDirectory if you lot're unable to alter permissions on the organisation's default temp directory.

Error: invalid magic give-and-take 'speciale'

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

php rebuildLocalisationCache.php --force        

This can happen at to the lowest degree upgrading to 1.20.

Missing edit toolbar, JavaScript not working

Since MediaWiki 1.32, MediaWiki no longer has a "JavaScript-powered" wikitext toolbar congenital in. The former "bulletin board manner 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 demand the functionality. The MediaWiki "tarball" releases accept 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 folio) it may exist caused by a JavaScript mistake. Open the error console of your web browser (usually by striking F12), reload the page and run across if any mistake message appears there. If it displays an error, usually, setting $wgShowExceptionDetails would give you more information. Sometimes the problem is that the organization'due south temp directory is not writable. In that case, you can likewise gear up $wgTmpDirectory if y'all're unable to alter permissions on the system's default temp directory.

If you get errors like Uncaught SyntaxError: Unexpected token < or Error: SyntaxError: syntax error (...) Source Lawmaking: <script (...), the crusade is usually a hosting provider that is automatically injecting HTML code for tracking or advertizement inside the load.php script, which is used by ResourceLoader to load the scripts and CSS used by MediaWiki. Open a support ticket with your hosting provider request them to disable that injection. If that's not possible, you should migrate your site to some other hosting provider. That usually happens on complimentary hosting providers.

Every folio displays a fatal fault, Log shows "MagicWordArray::parseMatch: parameter not constitute"

Try rebuilding the Localisation Cache:

          php maintenance/rebuildLocalisationCache.php        

From this thread.

All uploads neglect with the message "The file yous uploaded seems to be empty..."

It may be acquired past wrong rewrite rules when configuring Short URLs. Try disabling them (and the related configuration variables of MediaWiki) to meet 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 asking. Run into 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.

Cheque also the upload_tmp_dir configuration directive from php.ini, and be certain 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 exist accessible in some circumstances. In that case, you can set up a dissimilar temp binder similar C:\TEMP\ with proper permissions. To discard other problems, give temporarily all permissions to that folder (on Windows, add the local user grouping "Everyone" with full permissions), and and then restrict the permissions as needed one time you verify uploads are working.

If all uploads fail with the message "The file you uploaded seems to be empty. This might be due to a typo in the filename. Please cheque whether you really want to upload this file.", and in the apache error logs you take entries like this:

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

This is a problem with the PHP version your server is using. At that place take been several reports of this problem with PHP 5.iii.eight on SLES11 sp2. You may need to upgrade PHP or recompile it yourself.

WAMP/Apache on Windows: Some Special: pages are inaccessible

Information technology may happen, on windows installations under Apache, that some Special pages are inaccessible, giving a error, and in the logs you lot tin can see something like this:

[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 exist caused by various PHP bugs. One of them is when the wiki is installed in a NTFS junction. If that'due south non the trouble, upgrading PHP to a newer version can help (encounter this forum thread)

Attempting to save an edit gives you a 403 Forbidden error, or yous get redirected to the main page

This is a common issue for shared host which have mod_security enabled. To know if it'southward a problem with mod_security or not, create a simple exam page and save it with a pocket-size text (something as simple equally writing but a dot in the content). If the edit is saved, but other edits aren't, that'south caused past mod_security. Ask your hosting client support to disable it completely or the rules affecting your edits.

If even saving a very uncomplicated edit gets y'all redirected to the main page, or to the aforementioned page without the edit appearing, it may be a problem with how you've gear up up $wgServer or some other configuration variable that controls the path of the index.php script, or conflicts with rewrite rules in your webserver's configuration.

Login page warns most cookies disabled

This page is outdated. It was written for an older version of MediaWiki and may not use to the most contempo version. If you accept checked or updated this page and constitute the content to be suitable, please remove this notice. See the talk folio for a possible discussion on this.

You may get a bulletin like MediaWiki uses cookies to log in users. Y'all have cookies disabled. Delight enable them and try over again..

If cookies aren't disabled on your browser, it could be one of those issues:

• Y'all have $wgSessionsInMemcached fix to truthful but MediaWiki can't connect to memcached. Plow off this setting or check the memcached configuration.
• A incorrect cookie configuration. Configuration variables nearly cookies should work with their default values. Attempt to not override whatsoever of them.
• session_save_path() is not set correctly on the server, or the server doesn't take permissions to write to that path.
• If you lot use some sort of caching proxy in front of MediaWiki, check that it doesn't filter any cookie.
• session.referer_check() is wrongly fix. Yous should normally leave it empty.

Setting a debug log should display any cookie received by MediaWiki, so information technology may be a first stride to detect if cookies are actually received by MediaWiki or not.

MediaWiki does non function when magic quotes are enabled

MediaWiki version:

≤ 1.23

MediaWiki version:

≥ i.24

Magic quotes is a characteristic in PHP that is scheduled to be deprecated in PHP v.three and removed in PHP 5.four. If you go this fault, yous demand to disable the magic quotes in your server setting. See how to practise it. Since MW 1.24.

Discussions: Thread:Project:Support_desk/Problems_with_installing_mediawiki, Topic:S79xdn9u15xw55vj, Topic:Sdpbmy9q9e0ttp6k, Topic:S7g4rybniat2i36e, Topic:S6vqwk0tysl6m8lc

Error creating thumbnail: File with dimensions greater than 12.v MP

It may help to increase $wgMaxImageArea to become rid of the problem (tried with MediaWiki 1.26.ii).

Internal Server Error when opening any image

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 former Internet Explorer versions from beingness afflicted by a cross site scripting vulnerability. Still, 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 mistake. If you lot can't enable rewrite rules on .htaccess file, you may demand to comment-out or remove those lines from .htaccess, or the entire .htaccess altogether. See Topic:Uye1450mvn00f4y1.

Category pages, Special:Whatlinkshere and file usage aren't being updated

Information nearly pages independent in a category, links to other wiki pages and images embedded in pages are tracked in special tables. The update of such tables is non washed immediately after the edit is saved, simply deferred to the chore queue for performance reasons. If it takes besides long to update, you may need to accommodate $wgJobRunRate , or attempt setting $wgRunJobsAsync to fake in LocalSettings.php. This can happen specially in some installations since MediaWiki 1.27 (see task T142751).

Error: Could not open up lock file for "mwstore://local-backend/local-public/./../image.png

Check that the "images" directory has permissions which permit writing. If yous accept SELinux enabled, this could also exist problematic.

Notice: Did non find alias for special page 'Foo'. Perhaps no aliases are defined for it? [Chosen from SpecialPageFactory::getLocalNameFor in ...

You need to create an alias file. So, put something similar this in your extension file (eastward.g. /extensions/Foo/Foo.php):

                        $wgExtensionMessagesFiles            [            'FooAlias'            ]            =            __DIR__            .            '/Foo.alias.php'            ;          

Then create an alias file like this:

                        <?php            /**                          * Aliases for Special:Foo                          *                          * @file                          * @ingroup Extensions                          */            // @codingStandardsIgnoreFile            $specialPageAliases            =            assortment            ();            /** English (English) */            $specialPageAliases            [            'en'            ]            =            array            (            'Foo'            =>            assortment            (            'Foo'            ),            );          

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

Warning: Invalid argument supplied for foreach() in ./includes/objectcache/SqlBagOStuff.php

Probably y'all just moved your wiki, and didn't import your database, so it's empty.

In that location seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Delight resubmit the form.

Please follow Manual:How to debug/Login problems.

Call to undefined method

If a MediaWiki extension shows this error afterwards installing that MediaWiki extension, double-check that yous downloaded the version or co-operative of that MediaWiki extension which matches the version or co-operative of your MediaWiki installation.

Unable to run external programs, proc_open() is disabled

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

CAS update failed on user_touched for user ID '*' (read from slave); the version of the user to be saved is older than the current version

There are several reasons for this error. One unproblematic one is if the content of the user_touched column of the user_table is empty or is set to a time in the time to come.

Yous might want to check if the server'south fourth dimension is set correctly and synchronized. Also check the contents of that cavalcade and fill the column with valid content e.one thousand. with this SQL statement:

                        update            user            prepare            user_touched            =            '20200316120000'            where            hex            (            user_touched            )            =            '0000000000000000000000000000'            ;          

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

Lua error: Internal mistake

Meet Extension:Scribunto#Troubleshooting

PHP Errors

Fatal error: Allowed retention size of X bytes exhausted (tried to classify Y bytes)

Raise PHP'southward memory limit in php.ini:

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

MediaWiki version:

≥ one.16

You tin can add together a higher value for $wgMemoryLimit in LocalSettings.php.

MediaWiki version:

≤ one.15

In versions 1.15 and earlier, the memory limit in php.ini may be overridden by default in LocalSettings.php with the line:

ini_set('memory_limit', '20M');

You may increase the retention limit here, or comment this line out in LocalSettings.php to use the limit specified in php.ini.

This error can often happen for other reasons. Look for unicode usage on systems that do not back up it properly. Look for the filename and line and if y'all notice that you are in a language translation section that uses non-ascii characters, strip out that section. If you take increased the RAM allocated to PHP to 512MB and *still* have the problem with the memory error, it is not probable a memory effect per-se.

Read here for more information on configuring resources limits in PHP.

Fatal error: Class 'DOMDocument' not found in xxxxxxxx/Preprocessor_DOM.php on line nnn

This mistake happens when PHP hasn't been compiled with DOM support, or the DOM/xml extension is missing.

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

                        $wgParserConf            [            'preprocessorClass'            ]            =            'Preprocessor_Hash'            ;          

Fatal mistake: Invalid opcode 153/1/8. in 30/includes/cache/MessageCache.php on line nnn

That issue seems to bespeak information technology'due south a trouble with a PHP code accelerator that doesn't friction match the installed version of PHP or information technology'south outdated. Effort upgrading the accelerator. written report

Most likely, your text editor added a byte order mark (BOM) while you edited MediaWiki'southward PHP files, just any other content before the opening <?php causes the aforementioned trouble. This usually happens with LocalSettings.php - but see error message for exact file. Annotation that BOMs are invisible in well-nigh text editors. To remove the BOM, edit the file with something better than Windows Notepad, merely if y'all don't really have fourth dimension - open up the file with it and choose Relieve every bit..., and so cull "Unicode (UTF-8 Without signature) - Codepage 65001" as file blazon.

Strict Standards: date_default_timezone_get(): It is non safe to rely on the system'due south timezone settings.

If yous get Strict Standards: errors in the HTML output, that's because your error_reporting configuration variable of PHP is set to E_ALL, only since PHP >= v.iv.0, E_STRICT became part of E_ALL. E_STRICT are not errors, merely warnings most 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 post-obit does not work in all cases. It may be ameliorate to put this in the php.ini which must be present in all affected directories.

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

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

You can turn off PHP errors entirely using this instead:

See also: Setting error reporting in PHP.

If aught works, please bank 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 fault message at the top of it (example). If that was what happened, edit the file removing everything before "<?php" and verify in that location'southward cypher (even whitespace) earlier "<?php".

Fatal Mistake: Cannot redeclare wfprofilein()

This could happen if you upgraded and you lot have a StartProfiler.php file in the root MediaWiki installation directory, probably considering y'all enabled profiling in an sometime installation. To solve the issue simply remove that file.

Alarm: Inaccessible files

After your move, you might run across PHP warnings that certain files could non exist accessed. This is well-nigh probable caused past job T37472: The column md_deps in the module_deps tabular array contains accented file paths, which are used to locate the images and LESS files that CSS depends on. These paths pause when the wiki is, eastward.g., moved to another folder or some other server. Until this bug is solved, you lot can utilize this workaround to manually prepare incorrect entries in the module_deps table:

                        -- Update entries in module_deps table            SET            @            old            =            'wiki.former-domain.org'            ;            SET            @            new            =            'wiki.new-domain.org'            ;            UPDATE            `            module_deps            `            Gear up            `            md_deps            `            =            Supersede            (            `            md_deps            `            ,            @            old            ,            @            new            );          

This can be used to update wrong path segments and to fix the error.

MediaWiki versions:

ane.17 – i.26

A similar issue can happen when MediaWiki tries to read resource loader letters. In this case the solution is to truncate the according tables:

                        -- Truncate message related caches            TRUNCATE            Tabular array            `            msg_resource            `            ;            TRUNCATE            TABLE            `            msg_resource_links            `            ;          

Fatal error: Uncaught Exception: extension.json does not exist

MediaWiki version:

≥ 1.25

If this mistake happens when you try to install an extension, it usually ways that the extension still requires to use the older require_once method instead of the newer wfLoadExtension() method. Come across Manual:Extension registration

Installation Errors

The installer is unstyled when installing under IIS

The installer is unstyled and instead of the stylesheet, /mw-config/index.php?css=1 shows this error bulletin: "Less_Exception_Parser from line 447 of ...\vendor\oyejorge\less.php\lib\Less\Parser.php: Less.php cache directory isn't writable: C:\Windows\TEMP"

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

Error selecting database wikidb: 1044 Admission denied for user 'username'@'localhost' to database 'wikidb'

You need to Grant permissions on wikidb.* - See Manual:Installation#MySQL

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

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.10'            IDENTIFIED            Past            'password'            ;          

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

Database returned error "1142: CREATE command denied to user 'username'@'localhost' for table 'user_properties' (localhost)"

Equally above, or temporarily use the mysql root user.

Could non find a suitable database driver!

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

Filename Example Errors

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

Incomplete Upload Errors

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

403 Forbidden with Symbolic Links

If your webserver produces a "403 Forbidden fault" folio and you are using symbolic links, then brand certain your Apache httpd.conf file has Options FollowSymLinks to allow symbolic links and that each directory leading upward to your linked directory has +x permission for user running httpd.

Internal Fault during installation

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

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

SELinux

Linux distributions which support SELinux ('Security Extensions') are becoming more than widespread. On such systems, PHP scripts will still be unable to write to the config directory, after y'all take set the normal file permissions. You will too need to apply the 'chcon' command to modify the SELinux file type. See SELinux.

Required Advertisements on Hosted Sites

If you are running the MediaWiki software on a free site that requires banners or prefix advert, this may cause MediaWiki not to work, and appear to but generate empty pages beyond the banner advertizement. Y'all will accept to contact your host to make them brand their advertising compatible with MediaWiki, or chose a dissimilar host.

Debian, Apache2, and PHP

If y'all're running the MediaWiki on Debian with Apache2 and PHP5, and take problems connecting to MySQL, e.k you go the post-obit error message in your browser: (Can't contact the database server: MySQL functions missing, take you compiled PHP with the --with-mysqli option?) effort uncommenting: ';extension=mysqli.so' in the '/etc/php5/apache2/php.ini' file.

If that does not piece of work, try the following...

Check that MySQL module for php is installed:

            dpkg --list            |            grep php-mysql          

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

            apt-get install php-mysql          

Then restart Apache2:

            /etc/init.d/apache2 restart          

'user_password' can't accept a default value

Ensure that MySQL is not running in strict mode.

Specified fundamental was too long

If you selected "experimental UTF-viii", there may exist a MySQL error of the type "specified key was too long". Ane style of solving that is to edit the file maintenance/tables.sql so that the tabular array causing the problem uses shorter keys. (Depending on MediaWiki version, in that location might be other tables.sql files y'all also need to change; for example, maintenance\mysql5\tables.sql in 1.6.ten if you use MySQL 5.)

For example, if y'all detect the error message: PRIMARY Fundamental job_id (job_id), Key (job_cmd, job_namespace, job_title) ) Blazon=InnoDB " failed with error code "Specified key was too long; max key length is 1024 bytes (localhost)".

And then you lot should discover table "task" in tables.sql and replace Central (job_cmd, job_namespace, job_title) with something like KEY (job_cmd(160), job_namespace, job_title(160)).

The point is that the total length of all the fields in every Cardinal declaration should exist less so the max key size mentioned in the mistake bulletin, even when you multiply the varchar fields with 3 (considering a UTF-8 grapheme takes upwardly iii bytes). In the instance, job_cmd is varchar(255), job_namespace is int, job_title is varchar(255), thus the total key length in KEY (job_cmd, job_namespace, job_title) is three*255 + 4 + iii*255 = 1534, which is greater than 1024. After replacing, 3*160 + four + three*160 = 964, which should be okay.

After fixing tables.sql, yous should drop all the tables you take fabricated before, and and then run the install script again (merely reload the page with the fault message, that way yous don't take to enter everything again). You might get this error for several tables - job and page_restrictions are some that can be affected.

See also task T6445.

Missing tabular array prefix

If y'all are using a hosting service, the database name and database username may accept an actress prefix (commonly the userid given by your hosting provider). For example, if yous accept created a database named db01 with username u01 and your userid is ocom (given past your hosting provider), y'all should enter the database name and database username as ocom_db01 and ocom_u01 respectively.

MySQL connexion fails with fault [2013] or [2002]

If you are getting the error: failed with error [2013] Lost connection to MySQL server during query. or failed with error [2002] Tin can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (13)., this may exist caused by using the wrong database host name or by a permissions upshot with the mysql.soc file or directory.

If you are using a hosting provider, ensure that you are using the right host name for the database.

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

If you are unsure if MySQL is fifty-fifty installed, try the command mysql from the command line; if information technology is not installed, see Manual:Running_MediaWiki#Organisation-specific_instructions.

UNIX utility binaries not found

Errors include:

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

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/:/abode/:/tmp/:/usr/share/pear/:/usr/share/webapps/:/var/www/:/usr/bin/        

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

"Forbidden: You lot don't have permission to admission /mediawiki/ on this server."

This is usually an issue with the configuration of your web server software and unrelated to MediaWiki itself. See for example https://stackoverflow.com/questions/10873295/error-bulletin-forbidden-you-dont-have-permission-to-access-on-this-server or other web server forums.

Update/Upgrade Errors

Missing rc_timestamp field of recentchanges table. Should not happen.

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

This may happen if y'all didn't specify the aforementioned $wgDBprefix than your original installation, causing MediaWiki to not find its tables. Cheque the existing tables on the database and run across if they all share a common prefix, and update that setting appropriately.

Some other cause may be that you prepare an empty database. Reinstall the database content from a backup and proceed with migrating.

Parsoid / VisualEditor

Meet Parsoid/Troubleshooting and Extension:VisualEditor#Troubleshooting.

References

1. ↑ Gentoo problems.
2. ↑ Array keys corruption with APC.

Come across also

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

flanaganpoid2001.blogspot.com

Source: https://www.mediawiki.org/wiki/Manual:Common_errors_and_symptoms

Share this post