Vary nginx cache by wporg_locale cookie value

This cookie gets set by the locale-detection pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party, which is used on the login site, and soon on the Learn WordPress site. In the case of Learn, the value of this cookie will determine the language that is displayed in the front end UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. of the site (see this PR). Caching the pages without consideration of the chosen locale has a lot of potential for bad UXUX UX is an acronym for User Experience - the way the user uses the UI. Think ‘what they are doing’ and less about how they do it..

Could we update the nginxNGINX NGINX is open source software for web serving, reverse proxying, caching, load balancing, media streaming, and more. It started out as a web server designed for maximum performance and stability. In addition to its HTTP server capabilities, NGINX can also function as a proxy server for email (IMAP, POP3, and SMTP) and a reverse proxy and load balancer for HTTP, TCP, and UDP servers. https://www.nginx.com/. config to take this cookie into account when caching wporg pages? This locale switching functionality is intended for use on various wp.org sites beyond just Learn, so ideally this change would apply for *.wordpress.org

#prio1 because we’d like to get the locale switcher launched on the Learn site soon.

Bumping this down to #prio2 as it was worked around, but needs a call on whether this should just be closed or not.

Repair translations table.

Occasionally we’ve been seeing PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. warnings that the translation table is crashed:

Table ‘translate_translations’ is marked as crashed and should be repaired

This seems to have been happening sporadically for the last year or so, while running a translation job however, I ran into this and tracked it down to a range of IDs which appear to be inaccessible:

SELECT * FROM translate_translations WHERE id BETWEEN 43611019 AND 43611031;

Those IDs are accessible, but the 10 between them are not.

Can something be done, even if it’s to repair the table and remove those records in the process.

#prio1

Update gutenberg.run `A` record

Hi, can you please update the A record for gutenberg.run to point to 165.22.42.103?

The current record points to a droplet under @aduth‘s personal account, and we’d like to change it to a Foundation account that several of us have access to. DigitalOcean doesn’t allow transferring droplets, so we had to setup a new one, hence the IP change.

#prio2

DNS hosting for gutenberg.run

Hi, I’m working w/ @aduth to transfer the gutenberg.run domain to the Foundation. MarkMonitor has initiated the transfer, can you please setup DNSDNS DNS is an acronym for Domain Name System - how you assign a human readable address to a website’s exact numeric coded location (ie. wordpress.org uses the actual IP address 198.143.164.252). hosting on our end, and update the nameservers w/ MM after the domain lands?

I think the only needed record is an A to 138.197.4.192, and the www CNAME.

#prio1 (since the old registrar is currently doing DNS hosting)

Thanks!

Update *.git.wordpress.org to rename `master` to `trunk`.

WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. has decided to rename from master to trunk on all repo’s: https://make.wordpress.org/core/2020/06/18/proposal-update-all-git-repositories-to-use-main-instead-of-master/ and Gutenberg did that over here: https://github.com/WordPress/gutenberg/issues/27741

This is primarily for https://github.com/wordpress/wordpress/ & https://github.com/wordpress/wordpress-develop/ ( core.git.wordpress.org & develop.git.wordpress.org) but could also be applied to all of the git mirrors for simplicity.

The full list of *.git.wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ mirrors are the following AFAIK, and all can be updated without issue, as all the projects listed will just follow core’s direction here. I don’t know how this will affect the *.git => githubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ syncing process and/or what will need to change on GitHub.
– core.git.wordpress.org
– develop.git.wordpress.org
– backpress.git.wordpress.org
– bbpress.git.wordpress.org
– buddypress.git.wordpress.org
– glotpress.git.wordpress.org
– meta.git.wordpress.org

Can we make the change to our git mirrors please?

Requested via https://wordpress.slack.com/archives/C02QB8GMM/p1614648674097800

cc @noisysocks @jorbin

#prio2

Relax chinese rate limiting for Trac

In https://make.wordpress.org/systems/2020/03/21/re-evaluate-the-chinese-rate-limiting/ the rate limit for chinese traffic was relaxed, but it looks like Trac still has a rate limit in place.

Can we relax the rate limit for TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. as well?

If DOS traffic is still an issue, is it at all possible for logged in traffic to bypass the limits?

Ref: https://wordpress.slack.com/archives/C02QB8GMM/p1612868603196000

#prio2

Enable cURL on w.org production server?

The script that updates our ip2location database tables relies on cURL to download the newest data files. We’ve been running this script manually on sandboxes for a couple of years and it has always completed without errors. Recently we set up a cron job to run this script automatically, which means it now happens on the production server instead of a sandbox. However, during its inaugural run today, it failed with a curl: command not found error message.

Would it be possible to enable cURL on production so this script can run there?

#prio2

Enable Byte-Range Requests

Request from Chloé Bringmann:

I ran into an error when trying to upload the RSS feedRSS Feed RSS is an acronym for Real Simple Syndication which is a type of web feed which allows users to access updates to online content in a standardized, computer-readable format. This is the feed. on Apple for the new WP Briefing podcast. Would you be able to assist with this?I submitted the WP Briefing podcast to Apple and got the following error:

Can’t submit your feed. Your episodes are hosted on a server which does not support byte-range requests. Enable byte-range requests.

Is this something we can do on w.org, or would this be something where we want to utilize a CDN to serve the files instead?

#prio2

Increase upload size maximum to 100MB on w.org

The current server configuration seems to have a max upload file size of 50MB. I assume this is in the PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. configuration, although it may be limited by the webserver settings as well.

This is currently limited to 10MB on the main w.org network, and 50MB on the make network. These settings are through WordPress itself, in the Network Settings pages.

We would like that to be bumped to 100MB globally. The sites would still be limited to 10 and 50, respectively, with one exception. The https://wordpress.org/news/ site will need larger upload capabilities for the podcast files. Code has been added to allow up to 100MB uploads for the /news site only, but it is currently limited to 50MB by the server.

So, the request is to bump the max upload size on w.org to 100MB.

#prio2

Core build sync node version selection

As part of #52341-core there’s some work being done to standardise the build configuration for WordPress releases, but one of the changes is likely to cause breakage with the develop.svn -> core.svn sync.

Currently package.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. contains (for example) { engines: { node: "1.2.3" } } however the field should ideally contain >=1.2.3.
Due to the way that the nodeVersion switching code works though, I believe it’ll fail to find node ">=1.2.3" and then fail to find node ">=1*" not taking into account the version qualifiers.
See https://github.com/WordPress/wordpress-develop/pull/897/files#diff-7ae45ad102eab3b6d7e7896acd08c427a9b25b346470d7bc6507b6481575d519R9-R12

While not an ideal way to parse the field, altering nodeVersion() {} in develop-core-svn-sync-config.sh like so should make this more reliable and work well enough until this can be replaced.

 nodeVersion() {
 	# Old branches don't have a node version defined
 	if [ "$1" = 'null' ]; then
 		NODE_VER=0.10.5
 	else
 		NODE_VER=$1
 	fi
+
+	# Remove any non-numeric characters and version qualifiers (>=1.2.3)
+	NODE_VER=$( echo "$NODE_VER" | grep -oE '[0-9.]+' | head -n1 )
+
 	echo Switching nodejs to $NODE_VER

This has been tested by copying it to a new file, and running with the following output:

$ cat test.sh && echo ----- && ./test.sh
#!/bin/sh

nodeVersion() {
        # Old branches don't have a node version defined
        if [ "$1" = 'null' ]; then
                NODE_VER=0.10.5
        else
                NODE_VER=$1
        fi

	NODE_VER=$( echo "$NODE_VER" | grep -oE '[0-9.]+' | head -n1 )

	echo $NODE_VER
}


nodeVersion "1.2.3"
nodeVersion ">=0.1.2"
nodeVersion ">=1.2.3 <2.0.0"
-----
1.2.3
0.1.2
1.2.3

After it’s standardised, I believe the build team intends to look at self-containing the build process so it’s less tied to the system it’s being built on.

cc @desrosj

#svn #build #prio1

#52341-core