Project:Support desk

About this board

Welcome to the MediaWiki Support desk, where you can ask MediaWiki questions!

(Read this message in a different language)

See also

Before you post

Post a new question

  1. To help us answer your questions, please indicate which versions you are using, as found on your wiki's Special:Version page:
    • MediaWiki version
    • PHP version
    • Database type and version
  2. Please include the web address (URL) to your wiki if possible. It's often easier for us to identify the source of the problem if we can see the error directly.
  3. To start a new thread, click "Start a new topic".
Valleyoconnor (talkcontribs)
Reply to "Delete my wikipedia"

Hello, what about SkillProperties

1
84.22.214.226 (talkcontribs)

I am newbie, and I made a small mod that gives haste after use CloakandDager if I was invisible, but haste apper anyway.

Self:IF(Self:Invisible):HASTED,100,1;

Where is mistake?

Also how to give out an action point if I am invisible and use CloakandDager?

Reply to "Hello, what about SkillProperties"

change click behaviour for image on its image description page

4
Tenbergen (talkcontribs)

I am setting up a mediawiki on a raspberry pi. We are running the browser and desktop in a very locked down state where no browser controls are visible or accessible. This works, except when users click on an image on the image's description page. This opens the image all by itself outside of the mediawiki navigation environment. The problem is that there is no way to escape from that state, since there are no links back out. Can anyone suggest a solution? It might be changing something so the image isn't a link, or is a link to the description page itself. Or it might be adding a link back to the image only page. Or maybe someone has an even better idea? Thanks in advance!Tenbergen (talk) 00:32, 10 December 2023 (UTC)

94rain (talkcontribs)
Tenbergen (talkcontribs)

Yes, that is what I meant. You are no doubt correct that it can be changed with mediawiki:commons.js, but I am not sure how. Somewhere online suggested the following but it didn't do the trick.

document.addEventListener("DOMContentLoaded", function() {
   if (mw.config.get('wgNamespaceNumber') === 6) { // Check if it's a file namespace
       var filePageImages = document.querySelectorAll('#file img'); // Select images within the file description area
        filePageImages.forEach(function(img) {
            img.addEventListener('click', function(e) {
                e.preventDefault(); // Prevent the default action
                window.location.href = mw.config.get('wgServer') + mw.config.get('wgScriptPath'); // Redirect to the main page
            });
        });
    }
});
Tenbergen (talkcontribs)

I ended up using the following to change the URL of the link to stay on the image description page instead of going to the image file itself. There are probably better ways that would disable the click function altogether, but I don't know hooks or php well enough to work those out.

#--
# Change the click behaviour on the image description pages to stay on that page
# Default behaviour to link to the image itself would leave the kiosk  in an unbrowsable state
# since it doesn't have a back button. 

$wgHooks['OutputPageBeforeHTML'][] = function( $out, &$text ) {
	if ( $out->getTitle()->getNamespace() == NS_FILE ) {
		$newUrl = ""; // Replace with the URL you want the image to link to
		$out->addScript( 
			"<script type=\"text/javascript\">
				document.addEventListener('DOMContentLoaded', function() {
					var imageLink = document.querySelector('.fullImageLink a');
					if (imageLink) {
						imageLink.href = '" . addslashes($newUrl) . "';
					}
				});
 			</script>"
		);
	}
	return true;
};
#--
Reply to "change click behaviour for image on its image description page"

Broken ASCII title characters during Wiki update

11
Wuzh (talkcontribs)

Hi, I am a member of the Internet Movie Firearms Database, a wiki about firearms in films, television, and video games powered by MediaWiki.

During an IMFDB server update last year, a strange error occurred where all the page titles with "non-standard" ASCII characters (mainly letters with diacritics) were broken; the pages became prefixed with "Broken/", and the non-standard characters were replaced with "\x(ASCII code here)".

We have been trying to fix the titles via manual moving (example), but it's a slow and inefficient process, and there are also many files (and pages in other namespaces) that have been broken by the update.

Me and most of the staff on IMFDB are not experts on MediaWiki science, so I would like to ask, what caused this error? What can be done to fix it quickly?

P.S.: I was recently promoted to administrator on IMFDB, and I am in contact with the head developer of IMFDB. I should be able to provide additional details by contacting them.

Bawolff (talkcontribs)

This is usually caused by manual:cleanupTitles.php which is not usually part of the update process.

It looks like the issue was an iso-8859-1 vs utf-8 encoding issue. Sometimes this is caused by changing db charset settings or by making a mistake when restoring a backup.

You can potentially make a bot to fix this, but i dont know any preexisting ones.

Wuzh (talkcontribs)

So, I am now an IMFDB admin, and over the last couple of months, our (i.e. IMFDB staff and the members of MediaWiki community who have been helping out on the unofficial MediaWiki Discord) investigation into the title errors has revealed many deeper and stranger problems.

All of our investigations have ended in dead ends, and I think we might need to have our Wiki be reviewed by professional MediaWiki developers to see just what went wrong with it.

Issues
  • (Functionally Resolved) Across the wiki, all the page whose titles contain "non-standard" ASCII characters, such as "é" or "ø", were spontaneously moved to "broken" titles (these pages will hereafter be referred to as "broken pages"); the pages became prefixed with "Broken/", and the non-standard characters were replaced with "\x(ASCII code here)". No page move is recorded in the page history logs.
    • Issue has been de facto resolved through manual page moving.
  • (Unresolved) Most of the wiki's redirects that redirect to "broken pages" appear as broken redirects on Special:BrokenRedirects, and no longer function; clicking on one of those redirects in a page will direct one to the redirect page itself, not its destination. Null editing did not fix the problem.
Investigation
  • The initial suspected cause of the broken page titling, CleanupTitles.php, was not actually used during the update process; according IMFDB's head dev bunni, while he did run CleanupTitles.php during the update, it had no effect. Additionally, the fact that no page move is recorded in the page histories is uncharacteristic of CleanupTitles.php.
  • According to bunni, the encoding and the collage did not change during the update, and remained "latin1" and "latin1_bin" respectively.
Bawolff (talkcontribs)

> Additionally, the fact that no page move is recorded in the page histories is uncharacteristic of CleanupTitles.php.

That would be normal for cleanupTitles.php. cleanupTitles.php does not normally log page moves.

So for broken image titles.

It does look like there is issues with latin1 vs utf-8 in the database not just for page titles, but also for the img_name field in the database. (You can see this at https://www.imfdb.org/api.php?action=query&prop=info&list=allimages&aifrom=Ges&ailimit=2&aito=Ger&aidir=descending - Note how one of them has %E4 in the url while the other is %C3%A4. %E4 is the character ä in latin1 encoding, where %C3%A4 is how you do it in UTF-8. (If you also notice \u00E4, just to be extra confusing that is how json writes the UTF-8 version of ä, where \ufffd is how json writes invalid character). cleanupImages.php may be able to fix this.

It looks like there is also still a page associated with the old name, but mediawiki does not want to view it directly giving an exception. . You can still view it in the API . So clearly if cleanupTitles.php was run, it didn't fully work as we still have invalid page titles in the database.

Similarly, broken redirects show's invalid characters in the redirect targets - https://www.imfdb.org/api.php?action=query&list=querypage&qppage=BrokenRedirects&qplimit=max . The actual text content of the redirect pages use proper utf-8, so it looks like the redirect database table just got its charsets munched up. This could possibly be fixed by running the script refreshLinks.php.

So my general advice would be:

  1. Take a backup of your wiki
  2. Run cleanupImages.php
  3. Run cleanupTitles.php
  4. run refreshLinks.php

And then see what your wiki looks like. Taking a backup in case that is not an improvement. If this was earlier in the process, i would say revert to before the upgrade, try to figure out what happened to cause the charset confusion and then reupgrade, but at this point people have been editing, so i think it makes more sense to just go from here.

p.s. If you are looking for professional consulting, there is a list at Professional_development_and_consulting

Wuzh (talkcontribs)

We ran refreshLinks.php on a backup copy of IMFDB, and it didn't work; the same erroneous results still showed up, with no changes to any of them. We're planning on reverting our backup server to the pre-upgrade version to see what's different, and we want some advice as to what we should check or if we should try something different.

Bawolff (talkcontribs)

Did you run it as the last step? It would only work after running cleanupImages.php

Wuzh (talkcontribs)

The scripts were ran in the exact order as described.

Wuzh (talkcontribs)

We tried running all the scripts again. We forgot to mention this, but there was an error while running refreshlinks.php (both this time and the last time):

MediaWiki\Revision\RevisionAccessException from line 1296 of /var/www/w/includes/Revision/RevisionStore.php: Main slot of revision not found in database. See T212428.
#0 /var/www/w/includes/Revision/RevisionStore.php(1224): MediaWiki\Revision\RevisionStore->constructSlotRecords()
#1 /var/www/w/includes/Revision/RevisionStore.php(1220): MediaWiki\Revision\RevisionStore->loadSlotRecords()
#2 /var/www/w/includes/Revision/RevisionStore.php(1335): MediaWiki\Revision\RevisionStore->loadSlotRecords()
#3 [internal function]: MediaWiki\Revision\RevisionStore->MediaWiki\Revision\{closure}()
#4 /var/www/w/includes/Revision/RevisionSlots.php(175): call_user_func()
#5 /var/www/w/includes/Revision/RevisionSlots.php(117): MediaWiki\Revision\RevisionSlots->getSlots()
#6 /var/www/w/includes/Revision/RevisionRecord.php(192): MediaWiki\Revision\RevisionSlots->getSlot()
#7 /var/www/w/includes/Revision/RevisionRecord.php(175): MediaWiki\Revision\RevisionRecord->getSlot()
#8 /var/www/w/includes/page/WikiPage.php(805): MediaWiki\Revision\RevisionRecord->getContent()
#9 /var/www/w/maintenance/refreshLinks.php(236): WikiPage->getContent()
#10 /var/www/w/maintenance/refreshLinks.php(188): RefreshLinks->fixRedirect()
#11 /var/www/w/maintenance/refreshLinks.php(84): RefreshLinks->doRefreshLinks()
#12 /var/www/w/maintenance/doMaintenance.php(107): RefreshLinks->execute()
#13 /var/www/w/maintenance/refreshLinks.php(496): require_once('/var/www/w/main...')
#14 {main}

Bawolff (talkcontribs)

huh.

That might be consistent with the updater not running fully. I'm not sure.

Wuzh (talkcontribs)

So, head bureaucrat bunni is proposing that our single-leap update from version 1.19 to 1.35 could have broken the database and caused all these weird coding issues; he proposes that we should restore a backup and then update from 1.19 to 1.2 then to 1.3.

Bawolff (talkcontribs)

Seems unlikely to me. Last time mediawiki changed encoding was version 1.5. It is most likely the encoding issues are at the layer brlow mediawiki.

Restoring from backup is probably the best way to go though, if doable.

Reply to "Broken ASCII title characters during Wiki update"

Install error XAMPP for osx 8.2.4 : Malformed characters

2
Tnpot7s (talkcontribs)

Getting the same problem reported for topic " Malformed UTF-8 characters, possibly incorrectly encoded” after setting the language in the installation sequence.

Config:

XAMPP for OS X 8.2.4

msyql is listening on port 3306.

MediaWiki

PHP 8.2.4 is installed.

ICU 73.2 is installed (supports Unicode 15.0.0

Object caching is not enabled.

Found ImageMagick: /usr/local/bin/convert

Found the Git version control software: /usr/bin/git

Host - 127.0.0.1

Port - 8080


XAMPP control phpmyadmin loads just fine, connects to db server, can create DB, user etc.

I tweaked the exception string & to add the full text passed into the MagicWordArray function:

[ZX28RZpT3IFBxM9dbTF-YQAAAAY] … page=Welcome Exception: preg_match_all error 4: Malformed UTF-8 characters, possibly incorrectly encoded ...

You should have received … /�__�.invalid

The bracketed prefix changes on each reload.

So the host:port isn’t getting decoded properly for some reason?

I had to install intl for php 8.2.4 by hand, so I don’t know if that could come into it. Seems unlikely.

Tnpot7s (talkcontribs)

OSX Monterey 12.7.1

Reply to "Install error XAMPP for osx 8.2.4 : Malformed characters"

Malformed UTF-8 characters, possibly incorrectly encoded

15
Delta5768 (talkcontribs)

Got stuck on Connect Database;


[92c66aff7b86e27481dece49] /mywiki/mw-config/index.php?page=DBConnect Exception: preg_match_all error 4: Malformed UTF-8 characters, possibly incorrectly encoded

Backtrace:

from C:\xampp\htdocs\mywiki\includes\MagicWordArray.php(319)

#0 C:\xampp\htdocs\mywiki\includes\parser\Parser.php(4116): MagicWordArray->matchAndRemove(string)

#1 C:\xampp\htdocs\mywiki\includes\parser\Parser.php(1636): Parser->handleDoubleUnderscore(string)

#2 C:\xampp\htdocs\mywiki\includes\parser\Parser.php(724): Parser->internalParse(string)

#3 C:\xampp\htdocs\mywiki\includes\language\MessageCache.php(1374): Parser->parse(string, MediaWiki\Page\PageReferenceValue, ParserOptions, boolean)

#4 C:\xampp\htdocs\mywiki\includes\Status.php(331): MessageCache->parse(string, MediaWiki\Page\PageReferenceValue, boolean, boolean, NULL)

#5 C:\xampp\htdocs\mywiki\includes\installer\WebInstaller.php(1044): Status->getHTML()

#6 C:\xampp\htdocs\mywiki\includes\installer\WebInstallerDBConnect.php(41): WebInstaller->showStatusBox(Status)

#7 C:\xampp\htdocs\mywiki\includes\installer\WebInstaller.php(271): WebInstallerDBConnect->execute()

#8 C:\xampp\htdocs\mywiki\mw-config\index.php(82): WebInstaller->execute(array)

#9 C:\xampp\htdocs\mywiki\mw-config\index.php(40): wfInstallerMain()

#10 {main}

Bawolff (talkcontribs)

Certainly weird. Maybe could be caused if the database returned an error that was not encoded as valid utf-8.

Delta5768 (talkcontribs)

I don't know. I followed everything exactly step by step from the xampp manual for mediawiki.

Bawolff (talkcontribs)

As a hack, you could try in includes/installer/WebInstaller.php on around line 4042 replace the line

$html = $status->getHTML();

with:

$html = UtfNormal\Validator::cleanUp( $status->getHTML() );

If that actually fixes it, you should get a more descriptive message. Please let me know if that works, and what the more descriptive error message is.

Delta5768 (talkcontribs)

There's only ~1200 lines in WebInstaller.php, but I found the line of code and replaced it; it didn't do anything.

Bawolff (talkcontribs)

Oh, i guess it should be line 1042.

I suppose you could try doing: $html = htmlspecialchars( UtfNormal\Validator::cleanUp( print_r( $status->getErrorsArray(), true ) ) );

instead. Not sure if that will work.

Delta5768 (talkcontribs)

Array ( [0] => Array ( [0] => config-connection-error [1] => Cannot access the database: :real_connect(): (HY000/2002): php_network_getaddresses: getaddrinfo for local/localhost failed: ���� ���� ����������. ) )

Bawolff (talkcontribs)

Super weird. Some sort of locale issue in the error i guess.

But for actual cause, what did you use as your db server?

Delta5768 (talkcontribs)

MySQL

Ciencia Al Poder (talkcontribs)

The error message "getaddrinfo for local/localhost failed" is concerning... Are you using "local/localhost" (with a literal /) as the hostname for the database connection?

Delta5768 (talkcontribs)
Ciencia Al Poder (talkcontribs)

The server name outside of PhpMyAdmin should be "localhost", or even better, "127.0.0.1" on Windows. See Manual:$wgDBserver

Delta5768 (talkcontribs)

I set it to 127.0.0.1....


Array ( [0] => Array ( [0] => config-connection-error [1] => Cannot access the database: :real_connect(): (HY000/1045): Access denied for user 'admin'@'localhost' (using password: YES) ) )

Ciencia Al Poder (talkcontribs)

Well, that means you didn't provide the correct database credentials for user admin

Delta5768 (talkcontribs)

I verified everything thrice and it should be corrected


EDIT: Solved it by changing MySQL port in XAMPP to "3307" and adding port to hostname (127.0.0.1 --> 127.0.0.1:3307)

2804:D55:4638:DF00:4EEB:42FF:FE5C:6EC6 (talkcontribs)

Icant idenntifier the kapcha

Reply to "create a account"

Title is not showing when logged out

2
Zeyn1 (talkcontribs)

Title of the Wiki "Notes" is not showing when I'm logged out. I have these lines in LocalSettings.php:

$wgSitename = "Notes";

$wgMetaNamespace = "Notes";

And I thought I removed the logo but sometimes I see the logo too. How can I fix these?

https://1notes1.com/index.php/Main_Page

Bawolff (talkcontribs)

Try clearing your cache.

Reply to "Title is not showing when logged out"

Wiki Programmers who don't test their code

4
2600:8801:8C00:2B00:9D2D:E53E:4DA0:AFB8 (talkcontribs)

When you write code to chase donors away, and you write code that promises to not stick your PITA donation appeals in my face for a week and it pops up the very next time I look something up on Wikipedia, it's obvious that you're not testing your code.

I've been sending donations to Wki for a decade or two, since I've been relying on Wikimedia since nearly it's inception. If you want me and other like me to stop contributing keep this brutal donor appeals going and continue to make promises that don't occur because you dont test your code.

As a retired SPAWAR Systems Engineer who ran testing on/within some of the largest integrated systems, it's disappointing to see this kind on disfunction in one of my favorite sources.

Edward Eric Matus, ETC USN ret. eericmatus@gmail.com

2600:8801:8C00:2B00:9D2D:E53E:4DA0:AFB8 (talkcontribs)

Wiki has to send receipts to donors for use in tax returns. How hard would it be to add a database and direct the donor IDs into it and then add a subroutine to ensure you do not send your obnoxious appeals to people who regularly donate. That would be good social networking/marketing.

TheDJ (talkcontribs)
Bawolff (talkcontribs)

> How hard would it be to add a database and direct the donor IDs into it and then add a subroutine to ensure you do not send your obnoxious appeals to people who regularly donate.

Umm, have you tried creating an account and logging in? Maybe the world you want already exists.

Reply to "Wiki Programmers who don't test their code"

Images & pages missing after 1.33.1 upgrade

9
Exxosuk (talkcontribs)

My wiki was running a older version 25 so I upgraded to version 35LTS and about 90% of the articles disappeared including the main page. Looking in the database it looks like all the information is still actually there.

Long story short, I upgraded one version at a time which was successful until I hit version 1.33.1 where the majority of articles have disappeared and also the images have as well.

The images are on the server and I can access them via direct URL. but they do not load on the wiki page. When looking at the files section there is only about 15 images listed. Half of them are ones which I uploaded last week and several were from the original wiki in 2006. However in trying to fix this problem has now broken the thumbnails. This happened after I change the folder permissions to 777.

I keep seeing people saying run the scripts..

php maintenance/update.php

php maintenance/cleanupUsersWithNoId.php --prefix '*' --table revision

php maintenance/migrateActors.php

php maintenance/rebuildImages.php

But this did not help.

After several hours of looking around the Internet I came across this article..

https://www.mediawiki.org/wiki/Topic:Vy4x2pb18ebrvqix

Where it says run..

INSERT INTO revision_actor_temp (revactor_rev, revactor_actor, revactor_timestamp, revactor_page) SELECT rev_id, 1 as actor, rev_timestamp, rev_page FROM revision WHERE rev_id NOT IN (SELECT revactor_rev FROM revision_actor_temp);

Running that went from 4949 rows and 12489 after.

Now this did seemingly bring back the majority of the pages. The main page was still missing but when I clicked edit the information was there. So I saved the page and then it was working again afterwards. However I still have the problem with the images.

I have seen some posts talking about..

$wgHashedUploadDirectory = false;

But true or false makes no difference. I did try some other things in the file to no avail. I also tried deleting it and resetting up the wiki and re-uploading the settings file. But this did not change anything either.

I'm not really sure where to go from here now. It seems like something is fundamentally broken during the update.

If anyone has any suggestions please let me know because after fighting with this all week I really don't know what to do now.

Exxosuk (talkcontribs)

The only problem I found when running the update.php is what others seem to get stuck with , and never seems to be a solution.

User name "Exxos" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.

User name "Adolobe" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.

User name "Dazarz" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.

User name "Tin" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.

User name "Docrv" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.

User name "Rockyone" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.

User name "Rainwarrior" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.

User name "Steelz" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.

User name "Bikerbob" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.

User name "Bigclaw" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.

User name "Tomh" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.

User name "Panthen10" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.

User name "Magikgimp" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.

User name "Ragnar76" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.

I had to delete about 9 million spam users. So not sure where these names are all coming from now. There are 56 users left in the table. I wrote a script to verify they all had posts somewhere on the wiki. Though one listed is my account "EXXOS" which exists plus a lot of users which don't exist.

I ran the cleanupUsersWithNoId.php , it output some stuff, but all the problems remain. If I run update.php it just goes back to telling me to run cleanupUsersWithNoId.php , which I did multiple times.

As for the images. It seems if I try and upload the same file, it won't let me do it. Says already exists. So the wiki knows the file is there and yet it doesn't show on the wiki itself. Uploading a new image is fine and shows fine also. The only thing I can do is figure out how the wiki deals with images and see if I can figure anything out that way.

Bawolff (talkcontribs)

> php maintenance/cleanupUsersWithNoId.php --prefix '*' --table revision


Why --table revision? Try running without that.

Exxosuk (talkcontribs)

It doesn't seem to matter what I put..

php maintenance/cleanupUsersWithNoId.php --prefix '*' --force

Beginning cleanup of revision

... rev_timestamp=20231128214153 rev_id=1000000026

Completed cleanup, assigned 0 and prefixed 0 row(s)

Beginning cleanup of archive

... ar_id=100

... ar_id=200

... ar_id=300

... ar_id=400

... ar_id=500

... ar_id=600

... ar_id=700

... ar_id=800

... ar_id=900

... ar_id=1001

... ar_id=1102

... ar_id=1208

... ar_id=1324

... ar_id=1426

... ar_id=1528

... ar_id=1633

... ar_id=1739

... ar_id=1843

... ar_id=1951

... ar_id=2055

... ar_id=2156

... ar_id=2256

... ar_id=2365

... ar_id=2465

... ar_id=2584

... ar_id=2688

... ar_id=2788

... ar_id=2888

... ar_id=3016

... ar_id=3147

... ar_id=3253

... ar_id=3388

... ar_id=3497

... ar_id=3597

... ar_id=3709

... ar_id=3817

... ar_id=3933

... ar_id=4043

... ar_id=4143

... ar_id=4252

... ar_id=4367

... ar_id=4479

... ar_id=4587

... ar_id=4700

... ar_id=4805

... ar_id=4907

... ar_id=5007

... ar_id=5107

... ar_id=5207

... ar_id=5307

... ar_id=5407

... ar_id=5507

... ar_id=5607

... ar_id=5707

... ar_id=5807

... ar_id=5907

... ar_id=6007

... ar_id=6107

... ar_id=6207

... ar_id=6307

... ar_id=6407

... ar_id=6507

... ar_id=6607

... ar_id=6650

Completed cleanup, assigned 0 and prefixed 0 row(s)

Beginning cleanup of logging

... log_timestamp=20081014215605 log_id=501

... log_timestamp=20081014215622 log_id=601

... log_timestamp=20081014215638 log_id=701

... log_timestamp=20081014215648 log_id=801

... log_timestamp=20081014215707 log_id=901

... log_timestamp=20081014215726 log_id=1001

... log_timestamp=20081014215741 log_id=1101

... log_timestamp=20081014215751 log_id=1201

... log_timestamp=20081014215803 log_id=1301

... log_timestamp=20081014215815 log_id=1401

... log_timestamp=20081014215830 log_id=1501

... log_timestamp=20081014215844 log_id=1601

... log_timestamp=20081014215907 log_id=1701

... log_timestamp=20081014215923 log_id=1801

... log_timestamp=20081014215931 log_id=1901

... log_timestamp=20231128214153 log_id=1826850

Completed cleanup, assigned 0 and prefixed 0 row(s)

Beginning cleanup of image

... img_timestamp=20231128214153 img_name=Hydra3333.jpg

Completed cleanup, assigned 0 and prefixed 0 row(s)

Beginning cleanup of oldimage

... oi_name=ST_Motherboard_C070789-001_Rev_C_exxos2.jpg oi_timestamp=20080927121714

... oi_name=Ym2149.png oi_timestamp=20060913135635

Completed cleanup, assigned 0 and prefixed 0 row(s)

Beginning cleanup of filearchive

... fa_id=32

Completed cleanup, assigned 0 and prefixed 0 row(s)

Beginning cleanup of ipblocks

... ipb_id=236

... ipb_id=3593

... ipb_id=4312

Completed cleanup, assigned 0 and prefixed 0 row(s)

Beginning cleanup of recentchanges

... rc_id=7352200

... rc_id=7352269

Completed cleanup, assigned 0 and prefixed 0 row(s)


Then....


php maintenance/update.php > update9.txt &

User name "AciYc9" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.

User name "LopU7l" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.

User name "KiqAoj" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.

User name "CytZ92" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.

User name "QpuJ2e" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.

User name "Ramya" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.

User name "Zhangpeng" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.


etc

Exxosuk (talkcontribs)

The image problems are weird.

php maintenance/checkImages.php

170px-Megan_Fox_71.jpg: missing

Dizzy.png: missing

Hydra3333.jpg: missing

Good images: 31/34

Thing is, 2 of those images actually show up on the wiki. Its like the wiki is using the wrong table for the images. But there are over 800 in the images table and the recent ones I uploaded work. Oddly a couple of older images are showing up in the mainpage now.

All the paths are correct and accessible direct in the browser. The file hashes match all the folders in the images folder on the server.

Exxosuk (talkcontribs)

So I've deleted all the rows for one particualr file in the images/page tables and anywhere else I can find the filename I am working on, and still the wiki says the file exists. I've even deleted all the same filenames out of the images folder and thumbs folder.

At this point I am looking at the getExistsWarning function in Specialupload.php trying to figure out what the full path is that its "finding" the image file at, but I can't seem to work out anything but what the actual filename is, which I know already.

So does anyone know how to patch the function to output the FULL path its looking for the file at ? It may give me some clues. Its "finding" the file somewhere, but if its seemingly not in the tables anywhere or on the server as a file, WHERE is it finding the thing ?!

I also have the wiki debug logs enabled. All the SQL statements I ran them manually in phpmyadmin and all return "nothing".

Fokebox (talkcontribs)

I would not suggest to jump from 1.25 to 1.35 or even to 1.33, try to upgrade 1.25 -> 1.29 -> 1.31. Or something like that.

Exxosuk (talkcontribs)

It seems Apache was causing a lot of these problems. It seems to store pages, even SQL data in a cache by itself somewhere. Restarting SQL doesn't change anything. But if I restart apache2 after SQL edits, things start behaving afterwards. Though on my main server I changed to Nginx anyway as Apache kept having various odd issues with no solution.

Bawolff (talkcontribs)

If using apcu as cache, what likely happened is you forced a cache clear by doing that.

Reply to "Images & pages missing after 1.33.1 upgrade"