User Details
- User Since
- Aug 8 2016, 22:25 (398 w, 3 d)
- Roles
- Administrator
- Availability
- Available
- IRC Nickname
- Voidwalker
- GitHub User
- The-Voidwalker
- Miraheze User
- Void [ Global Accounts ]
Sun, Mar 24
I'm wondering if we could just make canned responses a MediaWiki interface page similar to MediaWiki:Deletereason-dropdown. Alternately, changing the form field from selectorother to combobox may work to make the canned responses editable in the form itself.
Tue, Mar 12
Feb 12 2024
This appears to be caused by the DisplayTitle extension. As it forces the link text of a page link to be that page's displaytitle property, unexpected behavior can (and does) happen when the interface is not expecting HTML in the link text.
Feb 1 2024
Jan 31 2024
Jan 30 2024
Latest change seems to have fixed it for me.
Responded on discord before I saw this task, anyway, here's a copy of my response in case anyone else is following this:
Jan 18 2024
Jan 6 2024
Jan 4 2024
Jan 3 2024
Sounds good to me. Though I'll note that looking into our logging and alerting infrastructure (as well as IDS) is one of my long term goals (from a SecOps perspective). Please reach out to me with ideas.
Approved by me.
Jan 2 2024
Approved by me
Approved by me
Dec 17 2023
Error 1364: Field 'dumps_completed' doesn't have a default value Function: DataDumpPager::onGenerate Query: INSERT INTO `data_dump` (dumps_status,dumps_filename,dumps_timestamp,dumps_type)
Dec 2 2023
I've removed the broken data dump entry. If anything happens with that one, please reopen this ticket.
Looks like there's still a no file revision, that indicates it's likely still broken. May need a maintenance script run to fix it.
Please reopen if/when you find more details about this bug.
RawHTML cannot be enabled due to security concerns. You may be able to do some of what you want to do using JavaScript in MediaWiki:Common.js, there is some useful documentation available here.
Added permissions.
Is this issue still persistent? Also, can you please link to your wiki and specify more details about what you were trying to do so we can see if we can reproduce the issue while investigating?
Caused by adding every single skin to $wgSkipSkins in Special:ManageWiki/settings under Preferences. I recommend removing at least the skin you have set as default, if not all.
Nov 30 2023
Doesn't seem to be a persistent problem, though it does seem like a few accounts still need permissions. Wondering if there might be something we can do to increase resilience against similar failures in the future.
Nov 24 2023
Per ^
Nov 23 2023
Should be fixed now, please reopen if you continue to encounter errors.
Closing per comment, if you encounter this issue again, feel free to reopen.
Second issue has been fixed, please see P493 for details on what pages were moved.
Nov 22 2023
Fixed with cleanupTitles.php. Four pages were moved, details:
Should be fixed with the running of cleanupTitles.php. Some pages have been moved on the wiki, check P492 for details.
Nov 21 2023
After T11430, we're back to where we started. Will be running script again after we bring swiftac back online.
Nov 20 2023
Nov 18 2023
Nov 17 2023
Nov 3 2023
Script done running.
We've fixed the config problem that caused this to happen and have a script running now to recover all broken revisions/pages.
Nov 2 2023
Nov 1 2023
Running rebuild script again on all servers. Seems some files are missing, though it's hard to tell as the checking script seems to fail the swift auth after being left along for long enough.
Oct 28 2023
Fixed with a hack locally, upstream task (private) still needs to be resolved.
Oct 27 2023
Doesn't seem to be fully resolved.
Deploying a fix now.