I'm very interested in getting it hosted internally, converted to a simple static site, or having it proxied internally. Who's able to help?

I don't think there's any reason this needs to be a security bug, and would benefit from being public (maybe we can find a volunteer to help convert it!). @Krinkle, mind if I make this public?

@Slaporte I am able to help with setting up a simple static site on our servers.

That being said, here is the old ticket where we did the opposite and moved from our cluster to Wordpress T110203

I agree with csteipp that making this ticket public would be helpful and i like it if we could host it on our servers again.

This task mentions T132103, which isnt public. Has it been resolved?

@jayvdb No, it's still open. If @csteipp is ok with it we can add you to it.

In T132104#2215041, @Dzahn wrote:

@Slaporte I am able to help with setting up a simple static site on our servers.

Thanks! I can share a github repo with the Wordpress skin, but I'd like someone to review for any private keys before we make to the repo public. Do you have experience building a static site with Jekyll or something similar? It will need to be updatable by people who may not be familiar with HTML in the future.

@Slaporte, you will probably know better the target authors. Who will be changing this site and how often?

Currently, there seems to be 9 pages on the site:

• https://policy.wikimedia.org/
• https://policy.wikimedia.org/about/
• https://policy.wikimedia.org/licensing/
• https://policy.wikimedia.org/privacy-policy/
• https://policy.wikimedia.org/policy-landing/censorship/
• https://policy.wikimedia.org/policy-landing/liability/
• https://policy.wikimedia.org/policy-landing/access/
• https://policy.wikimedia.org/policy-landing/copyright/
• https://policy.wikimedia.org/policy-landing/privacy/

With redirects to policy-landing/$1 from:

• https://policy.wikimedia.org/censorship/
• https://policy.wikimedia.org/liability/
• https://policy.wikimedia.org/access/
• https://policy.wikimedia.org/copyright/
• https://policy.wikimedia.org/privacy/
• https://policy.wikimedia.org/category/privacy/
• https://policy.wikimedia.org/category/liability/
• https://policy.wikimedia.org/category/censorship/
• https://policy.wikimedia.org/category/copyright/
• https://policy.wikimedia.org/category/access/

It probably isn''t even worth using a static blog builder, with its own idiosyncrasies.
When making a new entry, and with such low frequency, I'm quite sure you could find someone from the staff or community to convert from MediaWiki/Wordpress/OpenDocument to a html page suited for this site.

In T132104#2227051, @Slaporte wrote:

In T132104#2215041, @Dzahn wrote:

@Slaporte I am able to help with setting up a simple static site on our servers.

Thanks! I can share a github repo with the Wordpress skin, but I'd like someone to review for any private keys before we make to the repo public. Do you have experience building a static site with Jekyll or something similar? It will need to be updatable by people who may not be familiar with HTML in the future.

Hi @Slaporte, sorry for the delayed reply. While I don't have experience with Jekyll and i'm not sure i can help with converting a wordpress skin, here's what i could do:

I'd add puppet code that adds a simple Apache config for policy.wm.org and automatically clones the actual site content from a second gerrit project.

We could then give non-ops people the permission to merge changes in that repo and that would mean you wouldn't have to go through Operations each time there is a change.

It would then just be a matter of Gerrit config which users get to do the review and accepts changes and anyone could upload files for review, it wouldn't matter if they are external designers or volunteers or WMF employees.

But it would still be a Gerrit project and people would have to upload HTML/CSS files to it. The people who want to change content could use any tool they like, online or offline, just in the end somebody would have to still upload them to code review. So they don't really need to know HTML but still Gerrit, or somebody else would have to be in between to upload it for them. There is a form-based uploader though that should make it a lot easier.

https://tools.wmflabs.org/gerrit-patch-uploader/

Can't we simply for the very beginning create the static dump of the current site and present it until something new/better will be used?

How often is it edited?

Yea, agree. That is an option to solve this and then T132103, and then see again for a longer term solution.

It won't work to move from WordPress unless there is a system that will allow us to create/edit pages without editing HTML. I'm not necessarily attached to the other features in WordPress, but a replacement would need to be similarly easy to update and maintain.

How many pages are on the site, and how frequently are they updated?

What about Pelican? You can a variety of formats, Markdown being one example.

I wonder if we could skin MediaWiki and still have it easy to use, which would mean transferable knowledge for those that need to edit it, and something less for the ops team to manage.

If we could actually use MediaWiki that would be lovely too. As you say, usually the skinning is the issue. Maybe we could pay a consultant to convert the Wordpress skin to a Mediawiki skin, i don't know how realistic it is, but it would be nice.

In T132104#2267669, @Dzahn wrote:

If we could actually use MediaWiki that would be lovely too. As you say, usually the skinning is the issue. Maybe we could pay a consultant to convert the Wordpress skin to a Mediawiki skin, i don't know how realistic it is, but it would be nice.

Couldn't a self hosted wordpress install be used? (this might have been already discussed, I don't know if it has)

@TerraCodes No, not really. WMF has hosted their own wordpress in the past for blog.wm.org, discussed it many times, it was high maintenance (regular security patches), there weren't enough resources to properly maintain it and in a long process involving an external contractor it was moved from the cluster to wordpress.com hosting.

At first, we're still missing the answer on question How often is it (supposed to be) edited?
It would be great if somebody relevant (WMF-Legal people?) answered that, and according to it we could look for the proper solution.
In any case, I think that what I mentioned before is the fastest/easiest/best approach considering all the issues which having it on third-party wordpress installation means.

In T132104#2266284, @Danny_B wrote:

Can't we simply for the very beginning create the static dump of the current site and present it until something new/better will be used?

In T132104#2267669, @Dzahn wrote:

If we could actually use MediaWiki that would be lovely too. As you say, usually the skinning is the issue. Maybe we could pay a consultant to convert the Wordpress skin to a Mediawiki skin, i don't know how realistic it is, but it would be nice.

If there was a budget and it was something we really wanted to do, @DanielFriesen and @ashley both do skinning though their employers from my understanding.

From my quick thinking, It would be best to have a very basic skin that is served to anon users (the visitors) and just serve Vector to the logged in users (those that can edit the site) so not everything has to be redesigned in the new skin.

Porting over WordPress skins is pretty easy (though you can almost always ditch the PHP code, since MediaWiki is rather different in that respect).
As a quick test, I created a MediaWiki backend for the skin currently used on policy.wikimedia.org and applied resources (CSS, JS, fonts) on it...it mostly works as you'd expect, save for the fonts -- and thus the footer? or maybe that's a separate issue -- on IE11; for whatever reason(s) ResourceLoader is breaking it, since it works just fine on policy.wikimedia.org, which is currently WordPress-based and therefore doesn't have ResourceLoader. Needless to say, since this was a quick mockup, there's plenty of things related to the dynamic functionality of the skin (custom menus, etc.) which aren't yet implemented.

As @Peachey88 noted above, there are design concers to think of. WordPress and MediaWiki sites differ when it comes to users, and specifically those who have an account. On traditional blogs, only the author or authors have accounts, whereas on a traditional wiki anyone can create an account (and even edit without creating one!); so obviously you need to slap things like personal tools or content action links somewhere -- but where?
As you can see with the Desk Mess Mirrored skin, the content action links (tabs on MonoBook & Vector) looks kinda tacky and out-of-the-place, to put it nicely. That's because there wasn't originally space for those, so I just had to shove 'em somewhere, so that things like page history etc. remain at least somewhat accessible.

@ashley They just want to use MW to host the policy pages rather than use it like an actual wiki. So omitting things like content_actions and just switching to Vector for logged in users should be fine.

One could even include a "Preview" tab to preview pages in the logged out user's skin.

Or I suppose one could try and match the general behaviour of WordPress; When logged in add a black bar to the top and shove the various actions and tools inside there.

One question I would probably ask is whether the hero image on the front page should be configured with the i18n system like navigation usually is, $wg settings, or some other configuration system.

I recently saw that we have now "blogs" as apps in phabricator (https://phabricator.wikimedia.org/phame/ I don't know much about it yet but just wanted to throw it out there in case it might be another option for hosting this. What @ashley said still sounds very promising for Mediawiki too though.

edit: the ticket i saw was T134951

I would be happy to help converting this to a simple static site on our own infra. The amount of work would be limited (as long as it's just static files). Feel free to contact me about it.

This is open since over 4 years now and still an unfortunate situation that, of all pages, our own policy page is hosted externally and requires accepting a 3rd party policy.

This ticket from 2016 is still stalled and it seems the reason is nobody really feels responsible for it. Looking at the tags we have "Operations" (I offered to help converting it but we are not the ones who can make that decision by ourselves), "Privacy" (not a team but topic based?), "Privacy Engineering" (only 2 members and in status "watching" which sounds like waiting for others and "WMF-Legal" (not sure if using Phabricator).

also T132103#6610462 where Legal says that it is consistent with a "non-wiki privacy policy".

Personally I still think it's kind of ironic that of all sites the policy site is under a different policy than the projects but I don't see much of a path forward anymore.

Hey @Dzahn:

"Privacy" (not a team but topic based?),

Yes, just means a Privacy issue is probably implicated.

"Privacy Engineering" (only 2 members and in status "watching" which sounds like waiting for others)

Yes - Privacy Engineering is just me at this point. Unfortunately, I can point out, like you, that this is not great optics, and I can suggest alternative solutions that are more privacy-respecting. But I don't get to make decisions about what gets hosted where.

Thanks for the feedback @JFishback_WMF , cheers! Yes, we are on the same page here, this needs to be decided by management talking to legal (and/or comms team?) somehow. My offer stands though to help with the technical part.

Looks like T310738 will resolve this.

Change 808309 had a related patch set uploaded (by Dzahn; author: Dzahn):

[operations/dns@master] switch policy.wikimedia.org back from Wordpress to WMF DNS

https://gerrit.wikimedia.org/r/808309

Change 809324 had a related patch set uploaded (by Dzahn; author: Dzahn):

[operations/puppet@production] mediawiki/appservers: redirect policy and related sites to wikimediafoundation.org/advocacy/

https://gerrit.wikimedia.org/r/809324

Change 810073 had a related patch set uploaded (by Dzahn; author: Dzahn):

[operations/puppet@production] httpbb: add tests for policy.wikimedia.org, fixcopyright.wikimedia.org

https://gerrit.wikimedia.org/r/810073

Change 810073 abandoned by Dzahn:

[operations/puppet@production] httpbb: add tests for policy.wikimedia.org, fixcopyright.wikimedia.org

Reason:

merged into https://gerrit.wikimedia.org/r/c/operations/puppet/+/809324/

https://gerrit.wikimedia.org/r/810073

Change 809324 merged by Dzahn:

[operations/puppet@production] mediawiki: redirect policy and related sites to wikimediafoundation.org

https://gerrit.wikimedia.org/r/809324

Change 808309 merged by Dzahn:

[operations/dns@master] switch policy.wikimedia.org back from Wordpress to WMF DNS

https://gerrit.wikimedia.org/r/808309

Mentioned in SAL (#wikimedia-operations) [2022-07-21T23:53:04Z] <mutante> https://policy.wikimedia.org moved from Wordpress DNS back to WMF DNS - now redirects to https://wikimediafoundation.org/advocacy/ as requested on T310738 | this might also resolve T132104 or not because wikimediafoundation.org is also on wordpress VIP

Superseded by T310738: Setup redirect of policy.wikimedia.org to Advocacy portal on Foundation website?

@Aklapper If the intention of this ticket was that the site is not hosted on Wordpress VIP anymore and instead becomes completely in-house again... no.. since wikimediafoundation.org itself is just another site on Wordpress VIP.

If the part that it is back in WMF DNS and not directly pointing to Wordpress VIP....when then our Apache cluster redirects it to the above counts .. then yes.

In T132104#8149544, @Dzahn wrote:

@Aklapper If the intention of this ticket was that the site is not hosted on Wordpress VIP anymore and instead becomes completely in-house again... no.. since wikimediafoundation.org itself is just another site on Wordpress VIP.

If the part that it is back in WMF DNS and not directly pointing to Wordpress VIP....when then our Apache cluster redirects it to the above counts .. then yes.

I do agree that whether this task should be closed as resolved would depend on precisely what the author meant. Regardless, I think it's worth emphasizing that this task specifically relates to policy.wikimedia.org and not any other subdomain.

There still are a few CNAME records in the wikimedia.org zone file for WordPress VIP, including the recent T314626: Setup URL (soundlogo.wikimedia.org) for Sound Logo website. I don't know whether any security, privacy, or similar concerns regarding Wikimedia's use of WordPress VIP still apply, particularly since I don't have access to the linked task T132103.

In particular, if the author intended that WMF could continue to host sites on WordPress VIP, provided that wikimedia.org subdomains are not used for that purpose, then this task should be closed (assuming of course that redirecting from the old to the new is OK). However, there would still be work left to do for the remaining subdomains; such work would not fall within the scope of this particular task.

I completely agree with the premise that this was a net-negative and that it affects our credibility. I am afraid this feedback won't reach the relevant parties though because they appear to be using completely different tools to organize their work.