Project:Support desk

Welcome to MediaWiki.org's Support desk, where you can ask MediaWiki questions!

Read in your language

There are also other places where to ask :

• IRC
• mailing lists
• Stackoverflow Q&A (third party)
• mwusers (unofficial forum)

Before you post

• Make sure you have read our fundamental introduction.
• Please carefully check our FAQ and Errors and Symptoms pages.
• Project:Current issues is where you should discuss issues about the mediawiki.org website itself.
• If your question is about a specific function, please read the relevant technical manual , end-user help or extension page and consider asking on its talk page .
• Test wiki editing at the Project:Sandbox.

Post a new question

1. To help us answer your questions, please always indicate which versions you are using (reported by your wiki's Special:Version page):
   • MediaWiki
   • PHP
   • Database
2. Please include the URL of your wiki unless you absolutely can't. It's often a lot easier for us to identify the source of the problem if we can look for ourselves.
3. To start a new thread, click "Start a new topic".

Previous page history was archived for backup purposes at Project:Support_desk/old on 2015-07-30.

Hello! I tried to install the Wikibase plugin today. I didn’t succeed even though I installed Composer and did everything I had to. When I went to the wiki, I got a message that the page is not working. What did I do wrong? And I added wfLoadExtension ('Wikibase'); to LocalSettings.php but i took it away because my page didn't work.

Nobody can tell without an exact error message and basic information (see the sidebar on this page). Please provide sufficient information.

So, I didn't get any error message. When I installed Composer, I did everything I read in their instructions. Eventually, I added the extension to the wiki and the LocalSettings.php file, saved and navigated to the wiki: the page cannot process the request at this time. It's Google's own message, there was no error message.

Hey! I added this to the LocalSettings.php file:

$wgEnableWikibaseRepo = true; $wgEnableWikibaseClient = false; require_once "$IP/extensions/Wikibase/repo/Wikibase.php"; require_once "$IP/extensions/Wikibase/repo/ExampleSettings.php"; $wgWBRepoSettings['siteLinkGroups'] = [ 'mywikigroup' ]; $wgLocalDatabases = [ 'enwiki', 'fawiki' ]; $wgWBRepoSettings['localClientDatabases'] = array(

   'en' => 'enwiki',
   'fa' => 'fawiki'

);

And I got a wiki notification like this:

[e13e8d549475939e333e81d7] /index.php Error from line 35 of /home/antsamed/fi.antsawiki.antsamedia.eu/extensions/Wikibase/lib/WikibaseLib.entitytypes.php: Class 'Wikibase\DataModel\Entity\ItemId' not found Backtrace:

1. 0 /home/antsamed/fi.antsawiki.antsamedia.eu/extensions/Wikibase/repo/includes/WikibaseRepo.php(789): require()
2. 1 /home/antsamed/fi.antsawiki.antsamedia.eu/extensions/Wikibase/repo/includes/WikibaseRepo.php(404): Wikibase\Repo\WikibaseRepo::getDefaultEntityTypes()
3. 2 /home/antsamed/fi.antsawiki.antsamedia.eu/extensions/Wikibase/repo/includes/WikibaseRepo.php(561): Wikibase\Repo\WikibaseRepo::newInstance()
4. 3 /home/antsamed/fi.antsawiki.antsamedia.eu/extensions/Wikibase/repo/RepoHooks.php(104): Wikibase\Repo\WikibaseRepo::getDefaultInstance()
5. 4 /home/antsamed/fi.antsawiki.antsamedia.eu/includes/Hooks.php(174): Wikibase\RepoHooks::onSetupAfterCache()
6. 5 /home/antsamed/fi.antsawiki.antsamedia.eu/includes/Hooks.php(202): Hooks::callHook(string, array, array, NULL)
7. 6 /home/antsamed/fi.antsawiki.antsamedia.eu/includes/Setup.php(794): Hooks::run(string)
8. 7 /home/antsamed/fi.antsawiki.antsamedia.eu/includes/WebStart.php(81): require_once(string)
9. 8 /home/antsamed/fi.antsawiki.antsamedia.eu/index.php(41): require(string)
10. 9 {main}

Can you help? Thank you. :)

Hi all,

I'm building a new wiki, and I'm wondering if it makes more sense to build the Wiki using the rc and then launching it when 1.35 is released for prodution? What would you all do? How much of a headache would it be to migrate from 1.34.1 to 1.35 as compared to migrating from a rc to production level install?

Upgrading is really easy. The official Wikimedia wikis like Wikipedia go through all of the changes and get upgraded every week.

the differences between an RC and a prod release are usually super minor

Hello! Once again, I have a problem with MediaWiki. This time, the problems are apparently about some Languages ​​extension.

I am currently making a bit of a wiki similar to Wikimedia Commons. I took the Autotranslate module from Commons. When I create a template related to translations or the Languages ​​plug-in, I get the following text in red:

Lua error in Module:Autotranslate on line 71: No fallback page found for autotranslate (base = Template:Documentation, lang = ⧼lang⧽).

I have a Template: Documentation and the Parser function has languages, so it probably works like this: {{#languages}}.

My wiki includes the following extensions related to the language:

LanguageTag, LanguageSelector, UniversalLanguageSelector.

Thanks for the answers in advance.

you need to copy the page commons:mediawiki:lang and all its subpages into your wiki.

Thank you! This working.

When installing, I made the site 'account login only' but this is proving too tedious to manage. Is there any way to make it registration only without reinstalling?

If you just want to let users register their own accounts, then remove the line $wgGroupPermissions['*']['createaccount'] = false; from your LocalSettings.php file. If you want to let users without accounts edit too, then also remove $wgGroupPermissions['*']['edit'] = false;. You should also consider adding $wgNoFollowLinks = false; to avoid spam, after you make either of those changes.

In my first MediaWiki (test) installation attempt, I had used Namecheap's inbuilt software installer called Softaculous. During install, there was barely any privacy questions asked. And assuming from how public the content was by default, it seems like installing that way always ends up in "public wiki" settings. Hence my struggle to make things private, one configuration at a time.

I then uninstalled the wiki completely (including database), and attempted to install again - this time following MediaWiki's manual installation instruction. Lo and behold, a lot of other useful configuration options appeared - including the option to set this as a private wiki. This not only solved the direct-linking problem, but somehow also made then entire directory private, solving all my problems. Biggest tip here: Always install manually, and don't depend on automated nonsense.

Hi. I have created a test wiki at wiki.rehman.website to demo how companies can use private wikis. But I'm sort of clueless on how to block public access to the files/folders (including mediawiki-uploaded images) on the server. For example, https://wiki.rehman.website/docs/ and https://wiki.rehman.website/images/ (and all other folders) are currently publicly accessible. After much looking up, the furthest I've got is adding a .htaccess file with "Deny from All". But that just blocks the whole site altogether.

I've read Manual:Image authorization but I find that lacking clear steps on how to go about with this from scratch. Can anyone assist please? Or point me to a page with clearer steps?

I want to block all direct public access to files and folders. Many thanks in advance.

This seems to be about restricting access to some folders on your webserver.

This needs to be fixed by changing the settings in your webserver software, not in the MediaWiki software.

The usual approach (with apache) is to not have mediawiki in the web directory, have alias directives for any php entry points, use img_auth.php for images, and have a php script that only serves static files out of extension directory (that isnt needed as much for modern mediawiki, more for compat with lld extensions).

Wikipedia essentially does this (in order to be a bit extra paranoid)

Thank you for the replies, Malyacko and Bawolff. After looking a bit deeper, I've noticed the "Indexes" and "Hotlink protection" settings in cpanel (I use namecheap for this test site).

In the "Indexes" settings I had to select the main folder and choose the "no index" option (as opposed to the already selected default option). This immediately blocked all direct access to the site's folders, solving 50% of my problem (50% because the folders are now invisible, but already-obtained direct links to files still works).

The "Hotlink protection" setting allowed me to block all direct access to files. Based on my requirements, I had blocked png,gif,jpg,jpeg,webp,pdf,ppt,pptx,doc,docx,xls,xlsx,oft. It is interesting to note that for files such as JPG, the direct link (https://wiki.rehman.website/index.php/File:Testfile.jpg) does not work when accessing directly from the address bar, but works when you click the file link via an internal MediaWiki link. Obviously this is just one level of protection, and img_auth.php and others should also be followed.

Hope these helps for other readers.

One thing I still need help with though, is how to block direct links such as https://wiki.rehman.website/load.php. Or, should they be blocked? If I add php to the hotlink protection settings, the site would not work.

hotlink protection generally works by looking at referer headers. Which is why it blocks direct address bar access but not internal links.

In terms of blocking load.php - i guess i would ask what you are trying to accomllish by blocking hotlinks. Normally there wouldnt be much benefit to blocking hot links to it.

If you are using apache as your webserver, creating a file named .htaccess containing Deny From All will usually block access to files in that directory.

Thanks for the reply. Load.php is just an example php file in that main directory. I guess my question should have been a bit clearer - the wiki will be a private wiki with sensitive information. Should I worry if files like these are publicly accessible via direct link?

you shouldn't rely on hotlink protection for any real security. It is very easy to bypass. Its designed to stop your bandwidth from being wasted (from linking at popular website), not to prevent access.

I would just ensure that img_auth.php is setup, make your image directory somewhere that isnt web accessible (so peolle cant direct view images), and ensure mediawiki groups are setup correctly to restrict reading.

(This is the basic advice that works for an average person, and balances ease of setup with reasonable amount of security. If the data is super sensitive, where lives/millions of dollars/etc is on the line, hire an information security consultant)

Thanks. I've setup img_auth.php (and added the .htaccess in the /images) folder, and also disabled index browsing on the main folder. Just one more question though (and pardon me if it's a silly one). Since all other folders don't have htaccess setup (like /images), they are publicly accessible if a direct link is available. Do any of the other MediaWiki files/folders have anything sensitive/unprotected, or can they be left as it is? Adding the same .htaccess setting like /images block MediaWiki from working.

Excusez-moi, je ne parle pas l'anglais, quand j'essaie au début , j'obtiens le message d'erreur suivant : ubuntu@ubuntu-Lenovo-ideapad-330-17IKB:~$    gksudo gedit filename

La commande « gksudo » n'a pas été trouvée, voulez-vous dire :

  commande « gfsudo » du deb gfarm-client

Essayez : sudo apt install <nom du deb>

J'obtiens le résultat suivant : ubuntu@ubuntu-Lenovo-ideapad-330-17IKB:~$  gksudo gedit filename

La commande « gksudo » n'a pas été trouvée, voulez-vous dire :

  commande « gfsudo » du deb gfarm-client

Essayez : sudo apt install <nom du deb>

ubuntu@ubuntu-Lenovo-ideapad-330-17IKB:~$  gfsudo gedit filename

La commande « gfsudo » n'a pas été trouvée, mais peut être installée avec :

sudo apt install gfarm-client

ubuntu@ubuntu-Lenovo-ideapad-330-17IKB:~$ sudo apt-get install apache2 mysql-server php5 php5-mysql libapache2-mod-php5

Lecture des listes de paquets... Fait

Construction de l'arbre des dépendances       

Lecture des informations d'état... Fait

Aucune version du paquet php5 n'est disponible, mais il existe dans la base

de données. Cela signifie en général que le paquet est manquant, qu'il est devenu obsolète

ou qu'il n'est disponible que sur une autre source

Aucune version du paquet libapache2-mod-php5 n'est disponible, mais il existe dans la base

de données. Cela signifie en général que le paquet est manquant, qu'il est devenu obsolète

ou qu'il n'est disponible que sur une autre source

Aucune version du paquet php5-mysql n'est disponible, mais il existe dans la base

de données. Cela signifie en général que le paquet est manquant, qu'il est devenu obsolète

ou qu'il n'est disponible que sur une autre source

E: Le paquet « php5 » n'a pas de version susceptible d'être installée

E: Le paquet « php5-mysql » n'a pas de version susceptible d'être installée

E: Le paquet « libapache2-mod-php5 » n'a pas de version susceptible d'être installée

ubuntu@ubuntu-Lenovo-ideapad-330-17IKB:~$ sudo apt-get install apache2 mariadb-server-10.0 php php-mysql libapache2-mod-php php-xml php-mbstring

Lecture des listes de paquets... Fait

Construction de l'arbre des dépendances       

Lecture des informations d'état... Fait

Aucune version du paquet mariadb-server-10.0 n'est disponible, mais il existe dans la base

de données. Cela signifie en général que le paquet est manquant, qu'il est devenu obsolète

ou qu'il n'est disponible que sur une autre source

Cependant les paquets suivants le remplacent :

  percona-xtradb-cluster-server-5.7:i386 mariadb-server-10.1:i386

  mariadb-plugin-spider:i386 mariadb-plugin-oqgraph:i386

  mariadb-plugin-mroonga:i386 mariadb-plugin-connect:i386

  mariadb-client-10.1:i386 percona-xtradb-cluster-server-5.7

  mariadb-server-10.1 mariadb-plugin-tokudb mariadb-plugin-spider

  mariadb-plugin-oqgraph mariadb-plugin-mroonga mariadb-plugin-connect

  mariadb-client-10.1

E: Le paquet « mariadb-server-10.0 » n'a pas de version susceptible d'être installée

tar -xvzf /tmp/mediawiki-*.tar.gz sudo mkdir /var/lib/mediawiki sudo mv mediawiki-*/* /var/lib/mediawiki

tar -xvzf /tmp/mediawiki-*.tar.gz sudo mkdir /var/lib/mediawiki sudo mv mediawiki-*/* /var/lib/mediawiki

ubuntu@ubuntu-Lenovo-ideapad-330-17IKB:/tmp$ sudo mv mediawiki-*/* /var/lib/mediawiki

mv: impossible de déplacer 'mediawiki-1.34.2/cache' vers '/var/lib/mediawiki/cache': Le dossier n'est pas vide

mv: impossible de déplacer 'mediawiki-1.34.2/docs' vers '/var/lib/mediawiki/docs': Le dossier n'est pas vide

mv: impossible de déplacer 'mediawiki-1.34.2/extensions' vers '/var/lib/mediawiki/extensions': Le dossier n'est pas vide

mv: impossible de déplacer 'mediawiki-1.34.2/images' vers '/var/lib/mediawiki/images': Le dossier n'est pas vide

mv: impossible d'écraser le non répertoire '/var/lib/mediawiki/includes' par le répertoire 'mediawiki-1.34.2/includes'

mv: impossible d'écraser le non répertoire '/var/lib/mediawiki/languages' par le répertoire 'mediawiki-1.34.2/languages'

mv: impossible d'écraser le non répertoire '/var/lib/mediawiki/maintenance' par le répertoire 'mediawiki-1.34.2/maintenance'

mv: impossible d'écraser le non répertoire '/var/lib/mediawiki/mw-config' par le répertoire 'mediawiki-1.34.2/mw-config'

mv: impossible d'écraser le non répertoire '/var/lib/mediawiki/resources' par le répertoire 'mediawiki-1.34.2/resources'

mv: impossible d'écraser le non répertoire '/var/lib/mediawiki/skins' par le répertoire 'mediawiki-1.34.2/skins'

mv: impossible de déplacer 'mediawiki-1.34.2/tests' vers '/var/lib/mediawiki/tests': Le dossier n'est pas vide

mv: impossible d'écraser le non répertoire '/var/lib/mediawiki/vendor' par le répertoire 'mediawiki-1.34.2/vendor'

ubuntu@ubuntu-Lenovo-ideapad-330-17IKB:~$ sudo mkdir /var/lib/mediawiki

[sudo] Mot de passe de ubuntu :

Désolé, essayez de nouveau.

[sudo] Mot de passe de ubuntu :

mkdir: impossible de créer le répertoire «/var/lib/mediawiki»: Le fichier existe

ubuntu@ubuntu-Lenovo-ideapad-330-17IKB:~$ sudo mv mediawiki-*/* /var/lib/mediawiki

mv: impossible de déplacer 'mediawiki-1.34.2/cache' vers '/var/lib/mediawiki/cache': Le dossier n'est pas vide

mv: impossible de déplacer 'mediawiki-1.34.2/docs' vers '/var/lib/mediawiki/docs': Le dossier n'est pas vide

mv: impossible de déplacer 'mediawiki-1.34.2/extensions' vers '/var/lib/mediawiki/extensions': Le dossier n'est pas vide

mv: impossible de déplacer 'mediawiki-1.34.2/images' vers '/var/lib/mediawiki/images': Le dossier n'est pas vide

mv: impossible d'écraser le non répertoire '/var/lib/mediawiki/includes' par le répertoire 'mediawiki-1.34.2/includes'

mv: impossible d'écraser le non répertoire '/var/lib/mediawiki/languages' par le répertoire 'mediawiki-1.34.2/languages'

mv: impossible d'écraser le non répertoire '/var/lib/mediawiki/maintenance' par le répertoire 'mediawiki-1.34.2/maintenance'

mv: impossible d'écraser le non répertoire '/var/lib/mediawiki/mw-config' par le répertoire 'mediawiki-1.34.2/mw-config'

mv: impossible d'écraser le non répertoire '/var/lib/mediawiki/resources' par le répertoire 'mediawiki-1.34.2/resources'

mv: impossible d'écraser le non répertoire '/var/lib/mediawiki/skins' par le répertoire 'mediawiki-1.34.2/skins'

mv: impossible de déplacer 'mediawiki-1.34.2/tests' vers '/var/lib/mediawiki/tests': Le dossier n'est pas vide

mv: impossible d'écraser le non répertoire '/var/lib/mediawiki/vendor' par le répertoire 'mediawiki-1.34.2/vendor

Hi everyone,

I'm a long-term user of Wikimedia projects and recently I've engaged in setting up a wiki of my own. For reference, the URL to my wiki is https://wiki.hn-ams.org.

However, I'm running into issues when configuring Short URL on this wiki. The web server software is nginx; and as I followed the instructions on the page Manual:Short URL/Nginx, I managed to change the URL to a 'pretty' version for all pages EXCEPT for file pages. Whenever I go to a page in the file namespace, the site shows a '404 Not Found' message, as can be seen here:https://wiki.hn-ams.org/w/index.php/T%E1%BA%ADp_tin:Danh_s%C3%A1ch_1.jpg.

I've tried multiple solutions that were suggested on previous posts of the Support desk, but none of them worked in my case.

I would appreciate all of your help on this matter, as it is a bit urgent for me to finish this site and bring it into operation.

Thank you.

can you include your full nginx config file.

You might have some other rule targeting images that messes up pages ending in .jpg.

@Bawolff: Thank you very much for taking your time to help me. Here is the full nginx config file for my wiki site:

# Location for the wiki's root

# location /w/ {

## Do this inside of a location so it can be negated

# location ~ \.php$ {

# try_files $uri $uri/ =404; # Don't let php execute non-existent php files

# include /usr/local/src/centminmod/config/nginx/fastcgi_params;

# fastcgi_pass 127.0.0.1:9000;

# }

# }

location /w/images/uploads/amswiki/ {

# Separate location for images/ so .php execution won't apply

location ~ ^/w/images/uploads/amswiki/thumb/(archive/)?[0-9a-f]/[0-9a-f][0-9a-f]/([^/]+)/([0-9]+)px-.*$ {

# Thumbnail handler for MediaWiki

# This location only matches on a thumbnail's url

# If the file does not exist we use @thumb to run the thumb.php script

try_files $uri $uri/ @thumb;

}

}

location /w/images/uploads/amswiki/deleted {

# Deny access to deleted images folder

deny all;

}

# Deny access to folders MediaWiki has a .htaccess deny in

location /w/cache       { deny all; }

location /w/languages   { deny all; }

location /w/maintenance { deny all; }

location /w/serialized  { deny all; }

# Just in case, hide .svn and .git too

location ~ /.(svn|git)(/|$) { deny all; }

# Hide any .htaccess files

location ~ /.ht { deny all; }

# Uncomment the following code if you wish to hide the installer/updater

## Deny access to the installer

#location /w/mw-config { deny all; }

# Handling for the article path

location /ams {

include /usr/local/src/centminmod/config/nginx/fastcgi_params;

# article path should always be passed to index.php

fastcgi_param SCRIPT_FILENAME $document_root/w/index.php;

fastcgi_pass  127.0.0.1:9000;

}

# Thumbnail 404 handler, only called by try_files when a thumbnail does not exist

location @thumb {

# Do a rewrite here so that thumb.php gets the correct arguments

rewrite ^/w/images/uploads/amswiki/thumb/[0-9a-f]/[0-9a-f][0-9a-f]/([^/]+)/([0-9]+)px-.*$ /w/thumb.php?f=$1&width=$2;

rewrite ^/w/images/uploads/amswiki/thumb/archive/[0-9a-f]/[0-9a-f][0-9a-f]/([^/]+)/([0-9]+)px-.*$ /w/thumb.php?f=$1&width=$2&archived=1;

# Run the thumb.php script

include /usr/local/src/centminmod/config/nginx/fastcgi_params;

fastcgi_param SCRIPT_FILENAME $document_root/w/thumb.php;

fastcgi_pass  127.0.0.1:9000;

}

Thank you again in advance!

There must be some other configuration there, because the 404 error happens on every URL that ends in .jpg, .png or .gif, but if you manually add anything else at the end (like https://wiki.hn-ams.org/w/index.php/T%E1%BA%ADp_tin:Danh_s%C3%A1ch_1.jpg.aaa the page displays properly.

Check any other nginx configuration it may have loaded that's causing any special treatment to URLs with image extensions. Log files may give you more information

I have a wordpress site with more than 40000 posts and I want to export them to a fresh new mediawiki site.So is it possible to achieve that?

Google has lots of listings for people that need to do this in the past, have you googled it to look at what's already been tried? Seems you first need to get your data out of wordpress, I'd start there.

Then you can look at:

Manual:Importing external content

Hello,

I have just installed MediaWiki version 1.34.2 on our website, and now i need to make myself and some other users a member of the "interface-admin" group, but the "User rights" page does not show this group ... so how should i do that?

Thank you!

Do you mean that you don't see the group at all, or that you see it but it's under "Groups you cannot change"?

Thanks for your reaction.

I do not see the group at all. I only see "Groups you can change", and they are Editor, emailconfirmed, bot, administrator and bureaucrat (which i checked in my case).

But in the mean time i found out that when i repeat the permissions in LocalSettings.php, i do see it (as "interface administrator") and i can check it:

$wgGroupPermissions['interface-admin']['editinterface'] = true;

$wgGroupPermissions['interface-admin']['editsitejs'] = true;

$wgGroupPermissions['interface-admin']['editsitecss'] = true;

$wgGroupPermissions['interface-admin']['editsitejson'] = true;

$wgGroupPermissions['interface-admin']['edituserjs'] = true;

$wgGroupPermissions['interface-admin']['editusercss'] = true;

$wgGroupPermissions['interface-admin']['edituserjson'] = true;

I feel that this should not be necessary though, since according to the documentation interface-admin is an existing group, already containing these permissions.

Are you sure you're on MediaWiki version 1.34.2?

I have a site called bookofrealms.com

I keep getting a slew of header errors and my hosting provider keeps telling me I was attacked by malware bots. They want to charge me $300 to fix it. I don't want to pay that so I'm trying to fix this myself.

These are the errors:

Warning: Cannot modify header information - headers already sent by (output started at /home3/sully/public_html/bookofrealms.com/index.php:4) in /home3/sully/public_html/bookofrealms.com/includes/WebStart.php on line 35

Warning: Cannot modify header information - headers already sent by (output started at /home3/sully/public_html/bookofrealms.com/index.php:4) in /home3/sully/public_html/bookofrealms.com/includes/libs/HttpStatus.php on line 112

Warning: Cannot modify header information - headers already sent by (output started at /home3/sully/public_html/bookofrealms.com/index.php:4) in /home3/sully/public_html/bookofrealms.com/includes/WebResponse.php on line 46

Warning: Cannot modify header information - headers already sent by (output started at /home3/sully/public_html/bookofrealms.com/index.php:4) in /home3/sully/public_html/bookofrealms.com/includes/WebResponse.php on line 46

Warning: Cannot modify header information - headers already sent by (output started at /home3/sully/public_html/bookofrealms.com/index.php:4) in /home3/sully/public_html/bookofrealms.com/includes/WebResponse.php on line 46

Warning: Cannot modify header information - headers already sent by (output started at /home3/sully/public_html/bookofrealms.com/index.php:4) in /home3/sully/public_html/bookofrealms.com/includes/WebResponse.php on line 46

Warning: Cannot modify header information - headers already sent by (output started at /home3/sully/public_html/bookofrealms.com/index.php:4) in /home3/sully/public_html/bookofrealms.com/includes/WebResponse.php on line 46

Warning: Cannot modify header information - headers already sent by (output started at /home3/sully/public_html/bookofrealms.com/index.php:4) in /home3/sully/public_html/bookofrealms.com/includes/WebResponse.php on line 46

I cannot figure out for the life of me what is going on wrong here. I made sure the <?> was correct on the local settings file and I just can't figure out what else to do here. Please help me as this private wiki is very important to me. thanks.

the error probably means that index.php was modified. If your server was compromised, index.php was possibly modified to serve malware.

If you were attacked by malware, generally you should do the following:

Take a backup of everything for reference. include both db and filesystem

Try and figure out how it happened (apache access logs can be helpful). Otherwise you will just get compromised again.

Delete the server. This is to get rid of any backdoors the attacker may have installed.

Make a new server. Reinstall mediawiki and extensions (from official sources not from your backup. Use your backup only for the database, uploaded images and LocslSettings.php. verify that LocalSettings.php hss nothing suspicious in it)

Check that it all works.

Thank you!

Im on a shared hosting account though. I cant delete the server.

in that case i would consider terminating your account and starting a new one (that way you know for sure any backdoors are gone. Be sure to backup all data including dbs before doing this).

Failing that, deleting all files is probably good enough. Or at least all files (including dotfiles) in your public_html directory (if your host allows crontabs, ensure nothing evil in there)

thank you. You've been extraordinarily helpful.