I have now installed the skin. It can now be enabled from https://facquodvis.miraheze.org/wiki/Special:ManageWiki/extensions#mw-section-skins.

No response. Please reopen if still needed, and provide us with a list to delete. Thanks!

Per @Reception123

Per conversation I had with @R4356th via Discord, declining until the skin reaches a more stable state, right now the code is changing to much to do a proper review.

Add this to MediaWiki:Common.css and it will likely fix it for you.

This was fixed upstream, but should be resolved, but usually Upstream stuff or invalid status.

This should now be fixed.

Should be fixed now.

I see. Thanks anyways!

In T7715#155248, @Henry wrote:

I would like to keep editing existing pages in the main namespace to be possible, and just restrict the creation of new pages, but I don't see that functionality on that ManageWiki page.

I would like to keep editing existing pages in the main namespace to be possible, and just restrict the creation of new pages, but I don't see that functionality on that ManageWiki page.

You can restrict editing to certain namespaces by setting a right required to edit in it in Special:ManageWiki/namespaces/0 ($wgNamespaceProtection)

The linked issue was regarding restrictions on page reading, which I have no interest in restricting. whereas I am looking to restrict page creation for users on the main namespace while allowing them to create pages on their user namespace. Is this possible?

https://github.com/miraheze/puppet/pull/1834 did PR, feel free to close it though if we aren't doing this.

Please read the error. ES6 support is only for core+extensions not on-wiki JS.

So server roles:

• we will have a MW server that has the mediawiki::is_canary value set to true in puppet which will have the ssh keys installed /srv/mediawiki-staging/keys and armed using ssh-agent. This will be the main deploy server. This should also have is_staging set to true.
• we will have a test server with is_staging set to true but not is_canary
• all other MediaWiki servers will have use_remote_deploy set to true. This will add the ssh keys to the www-data account allowing remote access from the is_canary server.
• On most MediaWiki servers for config, simply pushing to puppet will trigger the change to be pulled onto the canary server and then trigger sync checks to run on all servers.
• On MediaWiki servers for l10n, there will be a shorthand that can be run to rebuild the cache when syncing a file or folder.
• For mediawiki, a new sync command will be introduced that will allow you to build them. We could make test3 auto sync on a change. MediaWiki servers can simply require 1 command to be ran or we will automate this.

In T7139#155127, @Void wrote:

@Reception123 can you review my plans on T7676, T7677, and T7678? I'm setting up pull requests for if we do them, but should we decide to take another approach, that's fine as well.

See also: https://github.com/miraheze/puppet/pull/1827

We can't enable Widgets as we have security concerns. Please see https://dev.miraheze.org/wiki/Replacements_for_the_Widgets_extension for alternatives or ask on https://meta.miraheze.org/wiki/Community_noticeboard

Test3 is now running as 'staging':

It would also be good if we could allow for the extension to receive other updates and still have the patch remain applied, which may require some research/testing.

If we copy enough logic, it should be fine. In the worst case, you just run git apply after updating but before syncing.

This also saves on running commands many many times and cloning git. We could probably eventually automate it in puppet if mediawiki or config changes

Deployed!

Declining per above. Will revert the current opt-in

Review in progress.

Declined per T7277#144598

The two mentioned PRs were merged, so closing task.

Ok, we can try that

I'm sorry to bother you again, in that case could you try with wiki-asterix.cf? This time I think it should work, I customized the nameservers with Miraheze's like this: should I do something else?

CSP Desicions can take a while

This is now done in extensions, just $wgWikiDiscoverUseDescriptions = true; needs to be set now. Closing as resolved since support has been implemented.

@Reception123 can you review my plans on T7676, T7677, and T7678? I'm setting up pull requests for if we do them, but should we decide to take another approach, that's fine as well.

Regarding IPv4 addresses, we will either need to repurpose the IPv4 addresses from jobrunner* (which would leave jobchron1 and task1 with no IPv4 address), or we need to purchase an additional two IPv4 addresses for these servers.