Symlink for new template file on meta.trac

[4621] adds a new template file for which, according to @nacin, needs to be symlinked.

Could someone do that please? Thanks!


HTTPS for is currently just a redirect to but when accessing via https you’ll get a warning about an invalid certificate because it uses the * one.

Can we get a proper certificate for Noticed this because links to


Update public key for Jenny Wong

@miss_jwo has a new public key (the old one is no longer accessible). Can someone please update her proxy access?

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDPWI879mwT38UUj+zRqbgtzKgCXoqcgjrsacZit0B+JvPf3kr6a6cIBiHIs3L9f9wg4ht8aSD8e8u1YQ4YnI9vMyldFtlJ1KqqsM01IotWDJIe8b3ad/TtBDBmCxh65amxl5wj0Vdfl6bg3YFQJo1d6lemZqQmsE/m2zTxwdEZYcr/xp/k97tUFVPpWIuwj7W5bSZEFwTGB3i7BZBWc0ufgkw6iTvrHHGqwRBvQ2SpQC6gInUi6oEPpnx4tgPrEu1wKZwvDZGdJVQifLOx1KF4JXmupB2nYs+s/iOueQd5ajdSALnBOTCiyY4GO9FGmdPveYpq678OsTjo67sQ6QDf jenny@Bishop


Can I please have commit…

Can I please have commit access granted to for SergeyBiryukov? He’s been patching bbPress consistently for years, and ramped up recently from working on the forums.

(He’s a prolific WordPress core developer already, so the typical Uncle Ben pep-talk doesn’t really apply.)

#bbpress, #commit, #prio2

Codex returns 500 error when WordPress cookies are set

Since March 14th Codex is sometimes returning a 500 error. It seems like this only happens if the wporg_logged_in cookie is set.

➜  ~ curl -v --cookie "wporg_logged_in=fooo%7C123456789%7C25ce9fd05b1aewf00509d6g5a602ae23" ""
*   Trying
* Connected to ( port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: *
* Server certificate: Go Daddy Secure Certificate Authority - G2
* Server certificate: Go Daddy Root Certificate Authority - G2
> GET /index.php?title=Special:UserLogin&returnto=Help%3AContents HTTP/1.1
> Host:
> User-Agent: curl/7.51.0
> Accept: */*
> Cookie: wporg_logged_in=fooo%7C123456789%7C25ce9fd05b1aewf00509d6g5a602ae23
< HTTP/1.1 500 MediaWiki exception
< Server: nginx
< Date: Fri, 17 Mar 2017 10:40:10 GMT
< Content-Type: text/html; charset=utf-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< X-Content-Type-Options: nosniff
< Strict-Transport-Security: max-age=31536000
<div style="border:1px solid #ffd0d0;padding:1em;">This is a cached copy of the requested page, and may not be up to date.</div><hr /><h1>Sorry! This site is experiencing technical difficulties.</h1><p>Try waiting a few minutes and reloading.</p><p><small>(Cannot contact the database server)</small></p><hr /><div style="margin: 1.5em">You can try searching via Google in the meantime.<br />
<small>Note that their indexes of our content may be out of date.</small>
<form method="get" action="//" id="googlesearch">
	<input type="hidden" name="domains" value="" />
	<input type="hidden" name="num" value="50" />
	<input type="hidden" name="ie" value="UTF-8" />
	<input type="hidden" name="oe" value="UTF-8" />

	<input type="text" name="q" size="31" maxlength="255" value="" />
	<input type="submit" name="btnG" value="Search" />
		<label><input type="radio" name="sitesearch" value="" checked="checked" />Codex</label>
		<label><input type="radio" name="sitesearch" value="" />WWW</label>
* Curl_http_done: called premature == 0
* Connection #0 to host left intact



Theme previewer missing a theme.

web1 appears to be missing the “tempo” theme for the theme previewer. I tried the normal commands to get it to update as well as reapproving the theme manually, to no effect. Need somebody to take a look at it, see if something is wrong with that directory.

It’ll be in /extend/theme-preview/wp-content/themes/tempo. Should have version 0.0.33 in there like the other webs do.


Marx cPanel License Expired

When I log in to cPanel, I get a License not activated error instead of the normal dashboard.


Marx blacklisted by Barracuda

I noticed a legitimate message in the WordCamp Help Scout account was flagged as spam because is blacklisted by Barracuda.

Lookup | Removal

I can request removal, but it seems like it’ll just get added again if we don’t figure out what outbound messages caused the blacklisting and prevent that from happening again.


nginx rewrite from `/forums` to `/support`

For two international forums I need a nginx rewrite from /forums to /support.

  • ->
  • ->

That seems to be something for the wporg-rosetta config:

location = /forums {
    return 301 /support/;

location ~ ^/forums/(.*) {
    return 301 /support/$1;

Not sure if we need to restrict that to the both hosts. We have a similar rule for

Once the configs are deployed the site URL needs to be updated as well:

Could someone please add the rules if they are looking good? Thank you!


Whitelisted WordCamp Production Data for Dev Environments

Right now WordCamp devs use a small subset of the production database that was manually created, because it wouldn’t be safe to keep copies of the production database in local environments.

That works good enough for most things, but we keep running into situations where reproducing bugs and testing fixes is much harder, and takes much longer, than it would if we had real-world data to work with.

So, I’d like to create a way to safely use a whitelisted copy of production data in local environments. Here’s how I envision it working:

  1. Create a script that runs on the production web server once a day
  2. It would create a copy of the primary database on the production database server
  3. Then run lots of SQL commands against that copy in order to redact anything that hasn’t been whitelisted
  4. Have another script in dev environments that uses sftp to download a copy of the whitelisted database once a day

The whitelist would contain a list of tables, columns, and keys that have been determined to not have any sensitive data. For example:

  • wp_users – The table itself would be whitelisted, but only the ID, user_login, user_nicename, user_registered, user_status, display_name, spam, and deleted fields would be whitelisted. Because user_pass, user_email, and user_activation_key would not be in the whitelist, the script would replace the contents of those columns with [redacted] (or in the case of user_email,
  • wp_usermeta – The table itself would be whitelisted, along with the umeta_id, user_id, meta_key, and meta_value columns, but only certain meta_key rows would be whitelisted. For instance, first_name, last_name, description, and wp_capabilities would be whitelisted, but session_tokens and wordcamp-qbo-oauth would not be.

Additionally, the script would have some logic to redact potentially sensitive values within whitelisted columns. For example, any e-mail addresses inside a meta_value value would be replaced with

What does Systems think about that? I’d do all the work to build the script, but I want to make sure you don’t have any security/privacy concerns.