This user is a MediaWiki enthusiast and third-party wiki system administrator.
Languages: de-N, en-3, fr-1
Based in Berlin, Germany: UTC+1 (CET) / UTC+2 (CEST)
The profile picture is licensed CC BY-NC-ND DE 3.0, my contributions here are licensed CC BY-SA 4.0, and my code contributions are licensed according to the software's license or ISC if the software provides no explicit license information.
It will be great to get a note about this new special page in the release notes for 1.43
I am a bit late with my reply. :( Thank you for your responses and work on this issue; I appreciate it. Really cool!
@Paladox Could this be backported to 1.43? Since that one will be an LTS release?
@Paladox It would be fantastic if you could continue your work.
Fine with me. I see no reason why 4.5.3+ should not work with this extension. A field test with a couple of widgets confirmed this. If @Yaron_Koren is OK with this change, Robert could add the patch to Gerrit.
I guess i would check if the page table has any pages with a negative id. If not i would just delete the negative entries from page_props. Afterall it should be impossible to ever match the negative entries.
It will probably remain a mystery. The wiki uses a lot of extensions. Thus, it may well be that the issue is to find somewhere here.
Well, what I reported is what I got. I'm not sure how this can happen, either, but it appears to be like this.
Ah, oh, that was fast. :)
@Winston_Sung https://github.com/wikimedia/mediawiki-extensions-Editcount/commit/116bf43c5ab68cc5f124627f4fa099e5c6a27c4a#diff-6a6295f752062fb0eec4a9df4e87c164b8d8d3b48023a54a1e682671296eb8a3R12 This should have been 1.40.0 if I am not mistaken.
or
I checked out REL1_39. Aaaaarrrrgh. Thanks for the info.
In this case, we are talking about a public wiki.
I like the proposed changes. As an MW LTS user, I am forced to stick to outdated versions of MLEB due to PHP incompatibility, so the first proposed change is no change for me. If I am not mistaken, integration into the MediaWiki tarball as proposed with change 2 would even improve my situation.
On top, we have the policy not to support upgrades from older versions than two LTS releases: T259771: RFC: Drop support for older database upgrades
1.32 is 5 years old, which is pretty old...
Thanks a bunch for the patch! I also think it should be forward-ported from REL1_40 to master.
See also the Search Suggestion using DisplayTitle topic Here it is about the ability to search for Page ID123654789 with the display title John Doe. Yeah, this will indeed be nice to have.
You were to fast responding. Somehow I pulled the code it the wrong extension directory. Senior moments.
It looks like the error went away. Thanks.
Thanks a lot.
It does. Tested with
It was a fresh installation done with install.php, and all it got was the rfc and pmid prefixes. In the meantime, more prefixes were added, but none were removed. Anyhow, I believe this discussion has already left the scope of this task. There should be a separate issue for it.
For documentation purposes and others that run into the issu. I just dropped the three fields with:
Thanks a lot for this information. I will get back here once I have an answer about the past of that wiki, which could further help in identifying the cause. This should bring some clarity.
I will check back and ask if somebody tried to update this wiki created with MW 1.34. I do not understand why a MW 1.34 should work with a MW 1.35 schema in this situation. If it does, well ... If not, I would assume that the old backup with the MW 1.34 schema was used again, which does not explain why MW 1.35 schema changes should be in there. I will ask what they did to have background information about it.
Thanks a lot for your comment. Let's see what we have.
No, I cannot tell when MW stopped providing a predefined set of interwiki links. Definitely before MW 1.39.x or starting with MW 1.39.x latest.
So, let's ask this question: What happens if I skip this step? So far, the wiki appears to work without issues. However, I am not a database wizard to be able to assess the impact fully.
I get this issue when trying to upgrad a MediaWiki 1.34 to 1.39 with "update.php". That wiki was initially installed using MW 1.34 and was never upgraded.
This is nice. Thanks a lot!
I have just successfully tested the following setup:
I discovered this because, for some reason, my preference was changed to HTML. Probably a side-effect of this issue.
I cannot tell exactly if the bug fix version changed, but the general PHP version is and was 8.1.x. The server was set up mid November 2023 and updated when I reported the issue. The issue did not happen in the four weeks before also on PHP 8.1.x. It could be that the minor version Ubuntu 22.02. ships changed during this time.
Thanks a lot for this info! Wow, quite a bunch of skins.
It sounds like it, but this is way out of my range of expertise to figure out and fix/harden.
Regrettably, the issue is persistent. After about 2 hours, the respective wiki was down again. I will go with the cron solution for now. The problem is far more significant than expected.
This issue happened to me not when installing freshly but when updating, not upgrading, my instance with git. After the update, I am now on:
How can I find out which skins support this responsive mode? Pretty sure Medik does not, which is why I set the following in the "LocalSettings.php" file:
$wgDefaultUserOptions['skin-responsive'] = 0; $wgHiddenPrefs[] = 'skin-responsive';
This assumes that no skin supporting this mode is installed for the wiki. This option uses quite a lot of space on the special page "Preferences," which is why I rather not show it if this feature is not supported anyway.
Thanks a lot for fixing the issue. My wiki logs are silent now.
MariaDB [DB99093932820210211]> show create table searchindex; +-------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Table | Create Table | +-------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | searchindex | CREATE TABLE `searchindex` ( `si_page` int(10) unsigned NOT NULL, `si_title` varchar(255) NOT NULL DEFAULT '', `si_text` mediumtext NOT NULL, UNIQUE KEY `si_page` (`si_page`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci | +-------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ 1 row in set (0.000 sec)
I looked for the offending page in the database with SELECT * FROM page WHERE page_id = 3380;and got the following result:
I also observe this error on 1.40.1. I’m not completely sure, but it seems to appear when the (default?) skin in not Vector
I suggest to revert the change. This issue is spamming my logs day by day.
I think that arraymap and arraymaptemplate will never make it to ParserFunctions. I suggest moving them to the Arrays extension.
I got the same issue when I was on REL1_39 for Mobile Frontend—some version of February or April 2023. After updating to the latest revision on REL1_39, everything is working as expected again.
Was "rebuildLocalisationCache.php" running for a specific language or all?
Is this issue persistent?
Fantaxtic! Thanks for both resolving the issue and making the changes available in the supported branches. I really appreciate your efforts.
@Ammarpad It appears that nobody detected your patch set yet. Do you happen to know how is working on email integrations to MediaWiki? Probably that person will be able to check your patch set.
I was just about to report this, too.
Awesome! Thanks a lot!!
Cool, thanks a bunch. I will give this a shot by going to the page table. Hopefully, it is just this one page.
Thanks a lot! Perfect!
This is still an issue for the extension's version (REL1_35), which is meant to work with MediaWiki 1.35.x. I have not tested 1.39.x yet.
Is there any way to figure out which page is / which pages are causing the issue?