Page MenuHomePhabricator

Consider moving policy.wikimedia.org away from WordPress.com
Open, NormalPublic

Description

See T132103 for the more immediate issue, but even the fact that it uses WordPress.com directly (it's not proxied by us, the policy.wikimedia.org sub domain points to their servers) is somewhat unfortunate. While this isn't our actual privacy policy (those are on https://wikimediafoundation.org) it is about our policies in general and often linked from social media.

Perhaps we can convert it to a static html site (it's pretty simple) like https://transparency.wikimedia.org/, https://15.wikipedia.org/ and https://annual.wikimedia.org/2014/.

Or perhaps we can proxy it (and then make sure all requests are routed through our domain, and analytics disabled).

See also:

Event Timeline

Krinkle created this task.Apr 7 2016, 10:31 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 7 2016, 10:31 PM
Krinkle changed the visibility from "Public (No Login Required)" to "Custom Policy".
Krinkle changed Security from None to Software security bug.
Krinkle updated the task description. (Show Details)
Krinkle updated the task description. (Show Details)
Krinkle added subscribers: Jalexander, Dzahn.
Krinkle updated the task description. (Show Details)Apr 8 2016, 12:34 AM

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?

ZhouZ moved this task from Backlog to Assigned on the WMF-Legal board.Apr 14 2016, 12:23 AM
Dzahn added a comment.Apr 18 2016, 6:27 PM

@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

Dzahn added a parent task: Restricted Task.Apr 18 2016, 6:28 PM
Dzahn added a comment.Apr 18 2016, 6:47 PM

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.

Krinkle triaged this task as Normal priority.Apr 19 2016, 5:57 PM
Krinkle removed a project: Security.
Krinkle changed the visibility from "Custom Policy" to "Public (No Login Required)".
Krinkle changed Security from Software security bug to None.
Restricted Application added subscribers: TerraCodes, JEumerus. · View Herald TranscriptApr 19 2016, 5:57 PM
jayvdb added a subscriber: jayvdb.Apr 20 2016, 12:59 AM

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

Dzahn added a comment.Apr 20 2016, 1:16 AM

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

@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.

Dzahn added a comment.May 4 2016, 7:12 PM

@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/

Danny_B added a subscriber: Danny_B.May 5 2016, 1:28 AM

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?

Dzahn added a comment.May 5 2016, 4:54 AM

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.

jayvdb added a comment.May 5 2016, 5:59 AM

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.

Dzahn added a comment.May 5 2016, 5:23 PM

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 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)

Dzahn added a comment.May 6 2016, 2:28 AM

@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.

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?

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.

Krinkle removed a subscriber: Krinkle.May 10 2016, 3:30 PM
Dzahn added a comment.EditedMay 11 2016, 6:36 PM

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

ZhouZ moved this task from Assigned to Legal Done on the WMF-Legal board.Jun 8 2016, 5:16 PM
ZhouZ moved this task from Legal Done to Assigned on the WMF-Legal board.