Unfortunately this has been a known issue for quite a long time, but there is not much we can, I've tried looking into this before, but the issue is with the Upstream extension and thus Unfortunately we can't do anything about on Miraheze other than report upstream once again.

Whoops...

Please raise back to 'normal' when the blocker is resolved and this is no longer stalled.

I've Disabled drafts there isn't much else we can do for this at the moment, I will try and fix the issue upstream

There is nothing we can do even if it is broken, other than disabling, but I've done patches to this extension before myself and could probably do one again to fix it if really broken.

Please raise back to 'normal' when this is no longer stalled.

Since this is Upstream, there is unfortunately nothing we can do other than reporting to its developers. I apologize for the inconvenience.

To streamline complex tasks, integrating a tool like TG Macro can significantly enhance productivity and efficiency in project management.

In T11832#237387, @Rodejong wrote:

Thing is, I use the same code on English WIkipedia, in the same Navigation as I use here on login.miraheze.org and on jwmeeting.miraheze.org and other wiki's.
Why does it only break at jwmeetingwiki?

Thing is, I use the same code on English WIkipedia, in the same Navigation as I use here on login.miraheze.org and on jwmeeting.miraheze.org and other wiki's.
Why does it only break at jwmeetingwiki?

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.

Okay, So @RhinosF1 suggested I created a new account. So I created a new email, and a new account on meta, and logged in.

Seems I was wrong. Could not reproduce with Vector-2022 at mirabeta with my userpage.

Report to upstream is pending btw.

Some skins are escaping the HTML in DisplayTitle apparently, and including both an escaped and unescaped version in the output. Very bizarre issue all around since it didn't happen to me while logged in. Very likely upstream issue.

In T11547#237010, @Reception123 wrote:

@Original_Authority could you confirm that there are no blockers left?

@Original_Authority could you confirm that there are no blockers left?

CSS is now bundled in the skin (https://github.com/immewnity/mediawiki-fluent/commit/331d9a6c98f92c8dff5d1b6a89030ea97dc56614). Not sure if there are any blockers left. Thanks @Original_Authority for fixing my mess with the Gravatar stuff :p.
EDIT: Oops, forgot about #13.

Upstream task filed here: https://phabricator.wikimedia.org/T356329. The search bar won't work with Cosmos if the wiki is private unfortunately until it is fixed in the skin.

The maintainer said that the skin will bundle the CSS it currently downloads from sharepointonline in the skin (https://github.com/immewnity/mediawiki-fluent/issues/16#issuecomment-1915868645), so a CSP review will likely not be necessary after all.

Upstreamed as https://phabricator.wikimedia.org/T356165

I've PR'd to fix all of those issues.

In T11547#234982, @Universal_Omega wrote:

This potentially can't be installed due to how the skin is in a sub directory, which doesn't necessarily work with our setup but maybe I can fix support for it.

Unlikely to be an issue with Miraheze. Advice being given in discord on reporting directly upstream.

Fixed with cleanupTitles.php. Four pages were moved, details:

Could this task be closed as "Resolved" then? Due to recent vandalism on Phabricator, only members of the Trusted Contributors group (created on November 1) are now allowed to close tasks.

Looks like we can take the code between the <graph> tags and paste it into the old editor to generate PNG or SVG: https://vega.github.io/vega-editor/?mode=vega

This also provides a tracking category "Category:Pages with disabled graphs" showing the pages that used to contain graphs. [...]

https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/Archive_205#Graph_extension_disabled_per_immediate_effect

No, it has significant security issues

Is there at least some wiki where it's enabled so that we can paste the code and take screenshots and replace the broken graphs?

Yesterday evening, @Paladox discovered connectivity issues from Miraheze's datacenter to Wikimedia's esams datacenter.

@Paladox mentioned on Discord that a WMF SRE has fixed the issue for now but is still investigating.

Switched to phroge.

Raising priority as phab121 has been updated to bookworm, and phabricator has little support for php 8.2

We should probably think about moving forward with this - the WMF now uses Phorge.

This is an upstream bug fixed in MediaWiki 1.40 (not 1.39 unfortunately). Once we upgrade, this should work. See https://phabricator.wikimedia.org/T318079 for reference.

The upstream issue is marked as resolved.

Upgrading to phorge is a normal phab upgrade with 2 extra steps. There is a guide that details it. I've done it for fossbots and it took 15 minutes.

I've been told there is a way but I'm not sure. Either way, switching without importing tasks would mean that we would have to keep Phabricator in a read only state indefinitely as we frequently need to refer to old tasks.

From what I've read, you can't import tasks from Phabricator instance to Phabricator instance either way due to the way its designed (and so WMF couldn't test Phorge on a separate instance as they couldn't import some tasks without importing the entire database which includes private tasks) but WMF has approved migrating, per https://phabricator.wikimedia.org/T333885

Looks like the WMF didn't have much luck importing tasks from Phabricator to Phorge. Still, we should switch anyway.

@PeterBay please don't reopen or bump tasks that are nearly two years old. As Saper says please open a new task. Thanks.

@PeterBay This is most likely something different - can you please open a new issue and attach the affected images.

I am having this problem as well.

Per discussion on Discord, this is upstream and intended.

I've changed this in DPL3 now it'll be updated during next round of extension updates.

https://phabricator.wikimedia.org/T328595 is relevant. It'll probably be useful to see how the WMF does things

Reported upstream: https://phabricator.wikimedia.org/T331228

This is a different error:

Error happens again on page https://dragontamer.miraheze.org/wiki/Event_Calendar

This has been fixed uostream. I am in the process of updating the skin. When finished, it should be fixed.

This is very likely to be an issue with the extension upstream, so there is nothing that Miraheze can do except wait for the developers to fix. https://github.com/StarCitizenTools/mediawiki-skins-Citizen/issues/580 filed.

Best formatting I can come up with is:

I believe it may be possible to force the TOC to display by editing MediaWiki:Print.css.

Switching to Vector legacy (2010) works for me, and is an acceptable workaround from my viewpoint, as long as I can switch to that skin.

I wasn't able to get it to work on Vector 2022 on enwiki, only on classic Vector.

Then how come it apparently works on Wikipedia?

Looking further into this, it would appear this is intentional per https://phabricator.wikimedia.org/T306719. It would seem though that this only affects the Vector 2022 skin and not classic Vector. Try changing your skin to classic Vector via Special:Preferences -> Appearance -> Vector (2010).

I think it's very unlikely that this is something wrong with Miraheze since another wiki on 1.39.1 has the same issue, so therefore I've created a task upstream which can be followed here: https://phabricator.wikimedia.org/T328556. I

On a hunch, knowing it was probably related to the previous issue we were having but also that the behavior had changed, I assumed that the version of Cargo used on our wiki had been updated to a version that fixed the previous row duplication bug and recreated the table (which admittedly we probably should have tried when the errors started, but the table is very large and has to partially be populated manually using null edits due to an unrelated bug, so it kept getting put off). Tests with the replacement table have not given me any database errors so far, so barring any surprises, I'd consider this resolved.

If there are no more security patches for Phab, I would recommend proceeding with this and even considering making it normal priority. What would the steps entail? Are there the same SQL tables, etc.?

Per above, this is the same issue that has been reported upstream. Unfortunately, since nothing can be done from our end I must close this as invalid.

In T8893#199118, @John wrote:

This is something we can look into post Swift work, as that remains the priority for Infra currently. Given Phabricator is security maintained, there is no urgency currently.

The swift work is now finished.

This seems to be an issue with PageForms and how it parses, it'll have to be reported upstream, as there is not much we can do about it, unfortunately.

In T10143#204428, @Reception123 wrote:

Unfortunately as you rightly point out this issue is upstream and as such there's nothing Miraheze can really do about it as far as I'm aware.

While I wouldn't recommend it if the option provided by Agent above is really that inconvenient for you, you could temporarily assign "skipcaptcha" to user in Special:ManageWiki/permissions.

Unfortunately as you rightly point out this issue is upstream and as such there's nothing Miraheze can really do about it as far as I'm aware.

In T9921#200697, @FatBurn0000 wrote:

Why is this resolved? It's still happening.

Why is this resolved? It's still happening.

Upstream PR merged.

This is something we can look into post Swift work, as that remains the priority for Infra currently. Given Phabricator is security maintained, there is no urgency currently.

Seems it did not work, so I am going to try and respond to upstream, and look further into it.

I updated MirahezeMagic. Please let me know if the issue still persists. Thanks!

Reopening, as a response from upstream made me realise this could've been a simple issue in our own MirahezeMagic, I have patched that, and will update MirahezeMagic shortly. If it doesn't work this task will be closed again, and I will reply upstream with that information. Thank you!

Per above. I will also try and create an upstream one a little later if none is created. I apologise for the inconvenience with the issue, but unfortunately there is not much we can do about it without at least some guidance from upstream. Thank you!

In T8893#197247, @Lens0021 wrote:

I just want to make sure that the EOL of Phabricator is over. There was an update in May 2022. https://secure.phabricator.com/w/changelog/2022.21/

I just want to make sure that the EOL of Phabricator is over. There was an update in May 2022. https://secure.phabricator.com/w/changelog/2022.21/

https://we.phorge.it/w/installation_and_setup/update_from_phabricator/ also

Reopening now that there is an official release. I think we can evaluate this again.

Since there is a workaround and also I am working on fixes for the counts in DPL3 directly, closing as invalid. However, I will note, that as of today, DPL3 is no longer fully maintained (except for emergency patches) on any MediaWiki version less than the upcoming 1.39 LTS release (T9446) so no guarantees on additionally, semi-minor bug fixes being deployed to DPL3 until Miraheze is on 1.39, probably this November or December.

In T9576#197142, @Cornelia wrote:

Thank you for your help. There are no more problems with any of those links.