Manual:Errores y síntomas comunes
Ves una página en blanco
Una página en blanco indica un error de PHP que no se muestra en la pantalla.
Para forzar esto, añada las siguientes líneas al archivo LocalSettings.php, debajo de <?php
error_reporting( E_ALL );
ini_set( 'display_errors', 1 );
También puede establecer un valor para error_log en PHP.ini y leer el registro de errores de PHP para averiguar qué está pasando.
En algunos casos, los errores de PHP también podrían constar en el registro de errores del servidor web.
Los informes de errores pueden incluir:
- "Advertencia [...] No es seguro confiar en la configuración de la zona horaria del sistema. Está *obligado* a usar la configuración date.timezone o la función date_default_timezone_set()." Compruebe si
date.timezone =está establecido correctamente (o si está configurado) enphp.ini. - Ciertos archivos pueden ser reportados como faltantes (por ejemplo, cuando la carpeta
mediaen su carpeta/includesya no está presente, puede recibir el mensaje de que un proceso de imagen requerido "falló al abrir el flujo"). Verifique el paquete de instalación original en MediaWiki (asegúrese de consultar la versión apropiada) para ver si éste es el caso. Si es así, simplemente copie los archivos que faltan de dicho paquete dentro de su directorio de MediaWiki. Puede ser necesario actualizar la caché y reiniciar el servidor web después de esto. - No se puede encontrar el socket de MySQL. Si
LocalSettings.phpestá establecido con el socket de MySQL correcto perophp.inino lo está, puede resultar en una pantalla en blanco sin ningún mensaje de error del servidor web o PHP. La solución es actualizar la entradamysql.default_socketen el archivophp.ini.
Muchas personas informan que aparecen páginas en blanco en versiones recientes después de enviar artículos a su nueva wiki.
Una causa probable es el límite de memoria en las instalaciones de php predeterminadas (normalmente 8 MB).
Por favor, revise sus registros de errores de PHP y/o Apache.
Para modificar esta configuración edite /etc/php.ini y aumente el valor de "memory_limit".
Por ejemplo, para aumentarlo a 32 MB sustituya el texto existente por memory_limit = 32M.
Asegúrese de reiniciar su servidor web después de haber cambiado este valor.
El límite de memoria puede que también haya sido establecido en su archivo LocalSettings.php.
Busque la línea que contiene la configuración de memory_limit y auméntela según sea necesario.
Quizá 20M no sean suficientes si está ejecutando la versión 1.15.1.
Cámbielo a, por ejemplo, "memory_limit = 32M".
Este cambio no requiere que reinicie Apache.
Si la página sólo se cuelga durante la carga por algún tiempo (como 30 segundos) haciendo una acción específica, y luego deriva en una página en blanco o un error HTTP 500, el problema es que se ha agotado el tiempo de espera para conectarse a algún servidor.
Esto podría ser el servidor de base de datos o, si sucede al realizar una acción específica, el servidor de correo (si ha configurado los ajustes de correo electrónico).
Si es el servidor de correo electrónico, compruebe si puede conectarse a él desde el servidor que ejecuta MediaWiki, por ejemplo, ejecutando el cliente Telnet con el servidor y puerto configurados en $wgSMTP y viendo si puede conectarse.
Si puede ver brevemente el contenido de la página y, de repente, toda la página se queda en blanco, lo más probable es que el problema sea causado por la presencia de una instrucción de JavaScript document.write, document.writeln, o document.open en uno de los scripts de la wiki.
Puede comprobar si ese es el caso si abre la consola de su navegador (pulse F12) y vuelva a cargar la página.
Si la pestaña de red devuelve un estado HTTP 200, y la transferencia es de varios kilobytes, es muy probable que este sea el problema.
Estos son métodos heredados de la interfaz Document que provocan que toda la página se quede en blanco si se utilizan fuera de la página HTML, y pueden estar presentes en las páginas de JavaScript de la wiki.
Su uso está totalmente desaconsejado, como lo indica la propia especificación de HTML.
Puede desactivar JavaScript en su navegador o configurar $wgUseSiteJs y $wgAllowUserJs como false para desactivar esos scripts hasta que arregle los que no funcionan.
Errores de MediaWiki
Miniaturas de imagen que no funcionan o no aparecen
En esta sección se enumeran los problemas y soluciones relacionados con las miniaturas que no se procesan o no se muestran.
Error al crear la miniatura: Archivo faltante:
Esto podría ocurrir debido a valores incorrectos de las variables globales como se explica en:
Error con el punto decimal en la configuración regional de srcset
Si las miniaturas de las imágenes simplemente no aparecen, y no hay ningún error visible en esas páginas, mire el código fuente HTML de la página y busque "srcset".
Si encuentra algo como <img ... srcset="/images/thumb/File.png/600px-File.png 1,5x, /images/thumb/File.png/800px-File.png 2x">, donde aparece 1,5x en lugar de 1.5x, el problema es causado por task T181987, y debería añadir esto a LocalSettings.php:
setlocale(LC_NUMERIC, "C");
SVG
Primero, determine la configuración de su $wgSVGConverter.
Por defecto, está configurado para usar ImageMagick para la conversión.
Usando ImageMagick
Necesita al menos ImageMagick 6.x.x.
Asegúrese de que su variable $wgImageMagickConvertCommand es válida.
Las configuraciones comunes son:
$wgImageMagickConvertCommand = "/usr/bin/convert";
$wgImageMagickConvertCommand = "/usr/local/bin/convert";
Si no funciona, intente configurar $wgSVGConverterPath.
$wgSVGConverterPath = "/usr/bin";
$wgSVGConverterPath = "/usr/local/bin";
Los alojamientos compartidos pueden proporcionar diferentes versiones de ImageMagick para satisfacer las necesidades de diferentes usuarios. Por favor, use la versión 6.x.x.
- Para determinar la versión de ImageMagick, busque en los archivos de ayuda de su proveedor de alojamiento, o utilice
/usr/bin/convert --versiono/usr/local/bin/convert --versionpara detectarlo. - En los alojamientos Linux compartidos de GoDaddy, "/usr/bin/convert" para la versión 5.5.6 y "/usr/local/bin/convert" para la versión 6.2.8.
Si la generación de miniaturas con ImageMagick falla con un mensaje de registro de errores del servidor web similar a "Asignación de memoria fallida" o "/bin/ulimit4.sh: Fallo de segmentación /usr/bin/convert ...", el valor de $wgMaxShellMemory puede que necesite ser incrementado.
Cuando en la ruta faltan caracteres no ASCII
- Compruebe si las configuraciones regionales UTF-8 están disponibles en su servidor ejecutando
locale -a - Cuando no esté disponible ejecute
locale-gen en_US.utf8o coloque la configuración regional con UTF-8 para su país y cambie el valor de$wgShellLocalede acuerdo a esto.
Cuando se utiliza IIS/FastCGI en Windows, la cuenta de invitado que es usada también necesita permisos de ejecución en "C:\Windows\System32\cmd.exe" de lo contrario recibirá un error "Imposible de bifurcar".
Usando Batik
MediaWiki establece límites de tiempo y memoria para los comandos del intérprete de comandos (shell) bajo Linux.
Si recibe el error "Error ocurrido durante la inicialización de la VM, no se pudo reservar suficiente espacio para el montículo de objetos, no se pudo crear la máquina virtual de Java.", intente aumentar el valor de $wgMaxShellMemory.
Usando rsvg
En algunas instalaciones de Linux y BSD, rsvg se renombra:
En lugar de establecer (por defecto)
$wgSVGConverters = array( 'rsvg' => '$path/rsvg -w$width -h$height $input $output' );
le gustaría establecer
$wgSVGConverters = array( 'rsvg' => '$path/rsvg-convert -w $width -h $height -o $output $input' );
JPEG
Síntoma: Este mensaje de error dentro de un recuadro gris:
- Error en la creación de miniatura: Parámetros de miniatura inválidos
Una causa: la cantidad de píxeles en la imagen original excede el valor de $wgMaxImageArea.
El valor predeterminado 1.25e7 es demasiado pequeño para muchas cámaras modernas.
Lástima que el diagnóstico no insinúe realmente cuál es el problema.
Puede incrementar el valor de $wgMaxImageArea o bien cambiarse y utilizar ImageMagick, que elude esta restricción (configure $wgMaxImageArea y $wgUseImageMagick).
Las imágenes de gran tamaño pueden requerir un tiempo de procesamiento considerable. Puede ser una buena política limitar el tamaño de las imágenes.
JPEG (usando GD)
Síntoma: Este mensaje de error dentro de un recuadro gris:
- Error en la creación de la miniatura: configuración de la biblioteca GD incompleta: falta la función imagecreatefromjpeg
Algunas versiones de PHP 4.x y 5.x, tienen un error en el que libjpeg es detectada pero no habilitada durante el paso ./configure; esto es bastante frecuente en sistemas Red Hat/RHEL/CentOS.
Si no quiere usar ImageMagick, la solución para esto es recompilar PHP.
Primero, averigüe (desde phpinfo()) cuales eran los parámetros existentes en ./configure, y agregue --with-jpeg-dir antes de --with-gd.
make clean
./configure --with-various-switches --with-jpeg-dir --with-gd --with-more-switches
make
make test
# cambiar a usuario root
make install
Posteriormente, reinicie el servidor web (para Apache en Red Hat: service apache stop y luego service apache start ).
Para probar, simplemente vuelva a ver la página Archivo:... (no necesita volver a cargarla).
Para más información, vea los comentarios en PHP: imagecreatefromjpeg (sinopsis de la función).
No es posible guardar la miniatura en el destino
Si obtiene el error "Error al generar la miniatura / Error al crear la miniatura: No se puede guardar la miniatura en el destino" y el directorio $wgUploadDirectory tiene los permisos correctos (en todos los niveles), verifique que $wgTmpDirectory realmente exista.
(A diferencia de algunas variables de ruta como $wgCacheDirectory, $wgTmpDirectory no se crean en tiempo de ejecución).
Un mensaje de error más detallado puede estar disponible si activa el registro de errores con $wgDebugLogFile.
Este error también puede ocurrir cuando el modo de sólo lectura ($wgReadOnly) se ha establecido en LocalSettings.php.
Puede intentar quitar $wgReadOnly
Error al crear la miniatura: Código de error: 25
Si obtiene "Error al crear miniatura. Código de error: 25" con ImageMagick, intente aumentar el tamaño de $wgMaxShellFileSize.
Añadir archivos de miniatura manualmente
En situaciones en las que no es factible crear las miniaturas dinámicamente cuando se solicitan (por ejemplo, para imágenes muy grandes, "Error en la creación de miniatura: no se puede extender la memoria caché", "Error en la creación de miniatura: convertir: no hay imágenes definidas", y similares), es posible agregar manualmente los archivos en miniatura.
Esto implica crear las imágenes más pequeñas en los tamaños deseados y cargarlas al directorio thumb/ en $wgUploadDirectory.
Por ejemplo, un archivo que se ha cargado en:
images/f/f8/Foo.png
debería tener sus miniaturas en:
images/thumb/f/f8/Foo.png/100px-Foo.png images/thumb/f/f8/Foo.png/600px-Foo.png
El tamaño del píxel es la dimensión horizontal. Un ejemplo de script Bash para crear miniaturas está disponible en Phabricator:P7049.
Error al crear la miniatura: Código de error: -1 en alojamiento mutualizado de OVH
Por una razón no identificada, la creación de miniaturas en algunos alojamientos OVH mutualizados está fallando con este error, incluso si la ejecución del comando en el intérprete de comandos SSH funciona.
La solución es evitar específicamente el uso de ImageMagick estableciendo $wgUseImageMagick a false en LocalSettings.php:
$wgUseImageMagick = false;
¡Lo sentimos! No hemos podido procesar tu edición debido a una pérdida de los datos de sesión. Por favor inténtalo de nuevo. Si el problema persiste, prueba a cerrar sesión y volver a iniciarla.
Límites de contenido
Si su servidor Apache tiene el parche de PHP reforzado (Hardened PHP), es posible que deba editar distintas variables en su archivo /etc/php.ini si desea tener páginas wiki con grandes cantidades de contenido.
En particular, considere las configuraciones para varfilter.max_value_length, hphp.post.max_value_length, hphp.request.max_value_length.
Las configuraciones predeterminadas pueden limitar sus páginas a menos de 10k o 64k en tamaño.
Otra posibilidad es si su servidor Apache está utilizando el módulo mod_security, el cual podría estar interfiriendo con MediaWiki. Tendrá que desactivarlo para que MediaWiki funcione correctamente.
No ha especificado un nombre de usuario válido / Ediciones y vistas previas de página completamente en blanco / No se puede cargar
Esto es causado por algo que trunca o descarta los datos POST desde el navegador hasta el servidor web.
En al menos una ocasión, esto se debió a que post_max_size y upload_max_filesize en php.ini estaban definidos con un valor demasiado alto (2048M).
Ajustándolos de nuevo a valores más sensatos (8M), se solucionó el problema.
Aparentemente, ningún dato POST llegaba a MediaWiki.
En otro caso, mod_auth_sspi interfería con los HTTP enviados a MW. Usar FireFox e introducir las credenciales del dominio funcionaría bien, pero MSIE fallaría. Este es un defecto conocido en mod_auth_sspi 1.0.4.
Tiene algunas opciones para hacer que esto funcione:
- Defina
SSPIOfferSSPIenoff← se pedirá a los usuarios que introduzcan las credenciales del dominio, igual que en el modo BÁSICO. - Defina
SSPIPerRequestAuthenon← No veo cómo esta es una configuración saludable, pero funcionó (excepto en la conexión de alta latencia con la que estoy obligado a lidiar). - Baje a la versión 1.0.3, pero es básicamente lo mismo que el punto #2 anterior.
La wiki aparece sin los estilos aplicados y las imágenes están ausentes
Si la wiki se ve bien cuando navega por ella desde el mismo servidor en el que está alojada, pero aparece sin estilos CSS aplicados (sin colores, sin fondos, sin imágenes, con un formato muy mínimo, etc.) cuando accede a ésta desde otras máquinas (o algunas de ellas), la causa más probable es que el servidor esté teniendo problemas para determinar la IP o el nombre del equipo que se está utilizando para acceder a él, o está mal configurado. Esto provoca que las URL de los estilos e imágenes se generen utilizando la dirección IP de bucle de retorno 127.0.0.1, localhost o un nombre de equipo desconocido fuera del servidor. Puede ver el código fuente de cualquier página y comprobar cómo se ven las URLs y qué ocurre si intenta acceder a ellas directamente a través de su navegador.
La solución es especificar manualmente en la variable $wgServer el nombre de equipo que todos usarán para acceder a la wiki.
Si se accede a su wiki desde una red interna y una red externa, es posible que deba utilizar la dirección externa para la variable $wgServer.
No olvide el número de puerto si está utilizando un puerto que no es estándar, como puede ser el caso si su ISP ha bloqueado el puerto 80 (ejemplo: $wgServer = "http://example.domain.com:8080";)
Si los estilos no se aplican incluso al navegar por la wiki desde el servidor donde está alojada, el problema puede ser un error de PHP en el script load.php de ResourceLoader.
Intente explorar el archivo load.php de su instalación de MediaWiki con su navegador web y vea si muestra algún error o sólo una página en blanco (consulte #Ves una página en blanco).
Debería ver un comentario similar a /* No modules requested. Max made me put this here */.
Si es así, tal vez sea un problema con el archivo .htaccess del servidor web.
Si en cambio ve un error 404 No encontrado, puede ser un problema con las reglas de reescritura del servidor web si intentó configurar las URLs acortadas.
Si está recibiendo respuestas de error 500 de las URLs load.php, revise los archivos de registro de errores del servidor web para obtener más información sobre los errores.
Parece haber un problema con algunas versiones de PHP y Gentoo que provoca que Apache presente un error de violación de acceso.[1]
Esto también puede suceder si tiene APC habilitado, establecer apc.serializer=php en php.ini podría ayudar.[2]
Desde MediaWiki 1.23, puedes terminar con una wiki con la mayoría de los estilos de apariencia específicos de Vector, como la barra lateral colocada al final de la página. Eso puede ser causado por un valor bajo en pcre.backtrack_limit configurado en algunas distribuciones como FreeBSD. Se sabe que tiene problemas con valores de 10 000. Aumente ese valor a 100 000, o el valor predeterminado actual de 1 000 000.
Desde MediaWiki 1.26, algunas apariencias, y especialmente Vector, pueden tener este problema.
Si ve el error Internal error Problematic modules: {"startup":"error"} en la consola de errores de su navegador, la causa más probable es la falta de permisos de MediaWiki para escribir en la carpeta temporal predeterminada, ya sea porque PHP no tiene permisos para escribir en /tmp (C:\WINDOWS\TEMP en Windows), o porque hay una restricción open_basedir y esa ruta no está incluida en ella.
Véase task T119934.
También puede establecer $wgTmpDirectory si no puede cambiar los permisos en el directorio temporal predeterminado del sistema.
Error: palabra mágica 'speciale' inválida
| Versión de MediaWiki: | ≥ 1.20 |
Si recibe ese mensaje de error después de actualizar, debe ejecutar el script de mantenimiento rebuildLocalisationCache.php con la opción --force:
php rebuildLocalisationCache.php --force
Las cadenas localizadas muestran su ID de mensaje en lugar de un resultado localizado
Si está viendo esto, intente ejecutar el script de mantenimiento rebuildLocalisationCache.php con la opción --force:
php rebuildLocalisationCache.php --force
Esto obligará a MediaWiki a reconstruir la caché de localización.
Falta la barra de herramientas de edición, JavaScript no funciona
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: <script (...), the cause is usually a hosting provider that is automatically injecting HTML code for tracking or advertising 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 asking them to disable that injection.
If that's not possible, you should migrate your site to another hosting provider.
That usually happens on free hosting providers.
Cada página muestra un error fatal, el registro muestra "MagicWordArray::parseMatch: parámetro no encontrado"
Try rebuilding the Localisation Cache:
php maintenance/rebuildLocalisationCache.php
From this thread.
Todas las subidas fallan con el mensaje "El archivo que ha subido parece estar vacío..."
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.
If all uploads fail with the message "El archivo que has intentado subir parece estar vacío; por favor, verifica que realmente se trate del archivo que intentabas subir.", and in the Apache error logs you have entries like this:
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.
WAMP/Apache en Windows: Algunas páginas especiales son inaccesibles
It may happen, on Windows installations under Apache, that some Special pages are inaccessible, giving a error, and in the logs you 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 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)
Al intentar guardar una edición se produce un error "403 Prohibido", o redirige a la página principal
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.
If even saving a very simple edit gets you redirected to the main page, or to the same page without the edit appearing, it may be a problem with how you've set 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.
La página de inicio de sesión advierte sobre las cookies desactivadas
 | Partes de esta página (aquellas relacionadas con esta sección) están desactualizadas. |
You may get a message like MediaWiki utiliza cookies para la autenticación de usuarios. Las cookies están desactivadas en tu navegador. Por favor, actívalas e inténtalo de nuevo.
.
If cookies aren't disabled on your browser, it could be one of those problems:
- You have
$wgSessionsInMemcachedset totruebut 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.
Setting a debug log should display any cookie received by MediaWiki, so it may be a first step to detect if cookies are actually received by MediaWiki or not.
Error al crear la miniatura: Archivo con dimensiones superiores a 12.5 MP
It may help to increase $wgMaxImageArea to get rid of the problem (tried with MediaWiki 1.26.2).
Error interno del servidor al abrir cualquier imagen
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.
Las ediciones no aparecen en "Cambios recientes", los "Cambios recientes" no se actualizan
By default there's a filter in Recent Changes to hide edits made by bots. Clear this filter and see if the edits appear.
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.
Ensure your extensions are compatible with your MediaWiki version.
Las páginas de categoría, Especial:LoQueEnlazaAquí y el uso de archivos no se están actualizando
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 task T142751).
Error: No se pudo abrir el archivo de bloqueo para "mwstore://local-backend/local-public/./../image.png
Check that the "images" directory has permissions which allow writing.
For example: chown -R www-data:www-data images and chmod -R 777 images.
If you have SELinux enabled, this could also be problematic.
Aviso: No se ha encontrado un alias para la página especial 'Foo'. ¿Quizás no hay un alias definido para ésta? [Llamada desde SpecialPageFactory::getLocalNameFor en...
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"
]
},
Then create an alias file like this:
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.
Advertencia: Argumento inválido suministrado para foreach() en ./includes/objectcache/SqlBagOStuff.php
Probably you just moved your wiki, and didn't import your database, so it's empty.
Warning: Invalid argument supplied for foreach() in ./includes/cache/localisation/LocalisationCache.php on line 459
To fix the warning uncomment in LocalSettings.php line
#$wgCacheDirectory = "$IP/cache";
Parece que hay un problema con su inicio de sesión; esta acción ha sido cancelada como medida de precaución contra el secuestro de sesión. Por favor, vuelva a enviar el formulario.
Please follow Manual:Cómo depurar/Problemas de inicio de sesión.
Llamada a un método no definido
If a MediaWiki extension shows this error after installing that MediaWiki extension, double-check that you downloaded the version or branch of that MediaWiki extension which matches the version or branch of your MediaWiki installation.
No se pueden ejecutar programas externos, proc_open() está desactivado
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.
<span id="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">
La actualización del CAS falló en user_touched para el ID de usuario '*' (leído desde el esclavo); la versión del usuario que se va a guardar es más antigua que la versión actual
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='20241221162226'
WHERE HEX(
user_touched
)='0000000000000000000000000000';
-- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-- 28 zeroes
Where the date is in YYYYMMDDHHMMSS format for the current date/time. See phab:T247751.
Error de Lua: Error interno
Ocurrió un error de consulta en la base de datos. Esto puede indicar un fallo en el sistema.
If you recently upgraded MediaWiki, or recently installed or upgraded extensions, try running the update.php maintenance script. (See also Manual: Actualización.)
Si aquello no ayuda, entonces realmente puedes tener corrió a un bicho en el software. Try to obtain more details about the query that fails (Manual:Cómo depurar) and file a bug.
La clave $wgSecretKey es insegura, generada con mt_rand()
Your system does not support /dev/urandom so the key was generated with mt_rand().
See $wgSecretKey.
MediaWiki requiere PHP 7.4.3 o superior; está usando PHP 7.3.17
If the PHP version on your web server should be recent enough, check if you have several PHP versions installed in parallel.
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.
Errores de PHP
Fatal error: Allowed memory size of X bytes exhausted (tried to allocate Y bytes)
Raise PHP's memory limit in php.ini:
memory_limit = 64M ; Maximum amount of memory a script may consume (32MB)
| Versión de MediaWiki: | ≥ 1.16 |
You can add a higher value for $wgMemoryLimit in LocalSettings.php.
| Versión de MediaWiki: | ≤ 1.15 |
ini_set('memory_limit', '20M');
Fatal error: Class 'DOMDocument' not found in xxxxxxxx/Preprocessor_DOM.php on line nnn
This error happens when PHP hasn't been compiled with DOM support, or the DOM/xml extension is missing.
- Install the right
php-xmlpackage for your distro. Example:sudo yum install php-xml - Alternatively, change the MediaWiki 'preprocessor' class in LocalSettings.php (see
$wgParserConf)
Fatal error: Invalid opcode 153/1/8. in xxx/includes/cache/MessageCache.php on line nnn
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
Warning: Cannot modify header information - headers already sent by (...)
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.
Strict Standards: date_default_timezone_get(): It is not safe to rely on the system's timezone settings.
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 ) );
You can turn off PHP error reporting entirely using this instead:
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<?php
Fatal Error: Cannot redeclare wfprofilein()
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.
Warning: Inaccessible files
After your move, you might see PHP warnings that certain files could not be accessed.
This is most likely caused by task T37472:
The column md_deps in the module_deps table contains absolute file paths, which are used to locate the images and LESS files that CSS depends on.
These paths break when the wiki is, e.g., moved to another folder or another server.
Until this bug is solved, you can use this workaround to manually fix wrong entries in the module_deps table:
-- Update entries in <code>module_deps</code> table
SET @old='wiki.old-domain.org';
SET @new='wiki.new-domain.org';
UPDATE `module_deps` SET `md_deps` = REPLACE( `md_deps`, @old, @new );
This can be used to update wrong path segments and to fix the error.
| Versiones de MediaWiki: | 1.17 – 1.26 |
A similar issue can happen when MediaWiki tries to read ResourceLoader messages. In this case the solution is to truncate the according tables:
-- Truncate message related caches
TRUNCATE TABLE `msg_resource`;
TRUNCATE TABLE `msg_resource_links`;
Errores de instalación
LocalSettings.php not readable
- On a Linux machine, use
chownorchgrpto correct the file permissions ofLocalSettings.php. - On some Linux machines, temporarily disable SELinux by running the command
sudo setenforce 0.
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 message: "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 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.
Error selecting database wikidb: 1044 Access denied for user 'username'@'localhost' to database 'wikidb'
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.
Database returned error "1142: CREATE command denied to user 'username'@'localhost' for table 'user_properties' (localhost)"
As above, or temporarily use the mysql root user.
Could not find a suitable database driver!
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.
Filename Case Errors
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.
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, you might have missing or incomplete files. You may have to retry your upload several times, especially if you have an unreliable connection.
403 Forbidden with Symbolic Links
If your webserver produces a "403 Forbidden error" page and you are using symbolic links, then make sure your Apache httpd.conf file has Options FollowSymLinks to allow symbolic links and that each directory leading up to your linked directory has +x permission for user running httpd.
HTTP 500 Internal Error during installation
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/*
HTTP 500 Internal Error after installation
If you downloaded the MediaWiki code from Git, and after finishing the installation process, accessing your MediaWiki installation in the web browser produces a "500 Internal Error", go to the MediaWiki installation folder and running the following commands:
find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;
SELinux
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.
Required Advertisements on Hosted Sites
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.
Debian, Apache2, and PHP
If you are running the MediaWiki on Debian with Apache2 and PHP5, and have problems connecting to MySQL, e.g you get the following error message in your browser: (Can't contact the database server: MySQL functions missing, have you compiled PHP with the --with-mysqli option?) try uncommenting: extension=mysqli.so
If that does not 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 have a default value
Ensure that MySQL is not running in strict mode.
Missing table prefix
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.
MySQL connection fails with error [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] Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (13)., this may be caused by using the wrong database host name or by a permissions issue with the mysql.soc file or directory.
If you are using a hosting provider, ensure that you are using the correct host name for the database.
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.
If you are unsure if MySQL is even installed, try the command mysql from the command line; if it is not installed, see Manual:Running MediaWiki#System-specific instructions.
UNIX utility binaries not found
Errors include:
- 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 = "";
"Forbidden: You don't have permission to access /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 this Stackoverflow thread or other web server forums.
Too many redirects (ERR_TOO_MANY_REDIRECTS)
When this happens on every page, this is usually caused by a wrong Manual:URL corto configuration, usually because of an error in a redirect rule.
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.
Errores de actualización/mejora
Falta el campo rc_timestamp de la tabla recentchanges. No debería ocurrir.
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.
"Can not upgrade from versions older than 1.31, please upgrade to that version or later first" (or variants)
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.
Parsoid / VisualEditor
Véase Parsoid/Troubleshooting y Extension:VisualEditor#Troubleshooting.
Referencias