Remove/Increase showcase rate limits

The showcase currently has a rather low rate limit applied to it. Recently a new showcase design launched (Which included a rewrite of the backend), this should have brought with it a performance boost over the old areas of the showcase which caused performance issues.

The new showcase is reliant upon newer WordPress features, such as the Site Editor which is reliant upon the rest-api, currently these trigger 429 responses pretty quickly due to exceeding the rate limits.

Can we either significantly increase, or remove the rate limits on the showcase please? I would personally suggest removal of the rate limit unless the new design proves to cause issues as previously experienced.

#prio1 #nginx #ratelimit #showcase

trac nginx cache stuck in updating state

The nginx cache for https://core.trac.wordpress.org/ticket/54504 appears to be stuck in an updating state, with 2-day stale content being served.

This isn’t critical, but a sign of an 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/. configuration change being needed I guess, or TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. is crashing on an unauthenticated request to that specific ticket consistently which seems unlikely.

$ curl -Is https://core.trac.wordpress.org/ticket/54504 | grep x-nc
x-nc: UPDATING

In the above example, Comments 94-96 are not visible in the cached response (ie. a logged out incognito request), but are for an authenticated user.

Unknown if this affects many URLs, low priority as it seems likely a rare occurence.

#trac #nginx #cache #prio3

Create wp20.wordpress.net

Please create a new site similar to WP15.

It needs to be done this week so it can be used for the SOTW

#prio1

IP connectivity problem debug request

As posted in #meta: https://wordpress.slack.com/archives/C02QB8GMM/p1670234270428419

I sorry if I chose wrong channel, but I’m having trouble accessing api.wordpress.org from multiple servers, like in these threads: https://make.wordpress.org/systems/2020/11/25/are-there-any-network-level-non-nginx/ https://wordpress.org/support/topic/server-ip-blocked/page/2/ https://wordpress.slack.com/archives/C02QB8GMM/p1605164522008700

For example 31.31.198.124. I can resolve api.wordpress.org, ping it – but not connect to 80 or 443 port: https://pastebin.com/r1B4PvPg
tcptraceroute to 80 and 443 ports: https://pastebin.com/qyQid5aB
tcpdump, GMT+3 time: https://pastebin.com/Tzd3JPMR

From another server (IP 31.31.198.122, same /24 subnet) everything is fine: https://pastebin.com/sHuCRkvG
Or, if i add custom route for 198.143.164.251 on the problem server, api becomes available: https://pastebin.com/1DnmeL1i , https://pastebin.com/hEKrWMwr

Looks like 31.31.198.124 is banned on api.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/ or something in beetwin blocking traffic from api.wordpress.or to 31.31.198.124. Can anyone check this?

Can systems please check, and for future requests, state how they’d like these to be raised when they come in? I didn’t want to just tell them to email y’all without you expecting it.

FYI @ilyaregru

#prio2 #connectivity

Dedicated uploads CDN

Currently uploads on 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/ are served through ms-files.php, which uses the format of a https://{$HOST_PATH}/files/{$FILE} url.

For example: https://wordpress.org/files/2022/12/sotw-drawer-background.png or https://wordpress.org/showcase/files/2019/11/hodge-bank.jpg

For various reasons, including the desire for SVG uploads to be used within the WordPress Site Editor by designers, moving these to a CDN would be appreciated.

These can already be accessed via the s.w.org CDN like so (same file as above): https://s.w.org/wp-content/blogs.dir/1/files/2022/12/sotw-drawer-background.png – Not a pretty URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org, it works, but I’m unsure if we’d want to have SVG files on that hostname, even if only uploaded by trusted users and run through a SVG-sanitizer 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?

As it can be accessed through that CDN, it means it can also be accessed directly without a CDN, through the the main wordpress.org hostname. Ideally, we’d want to remove that functionality / automatically redirect direct blogs.dir access, if we were to allow SVG uploads.

What’s the best option here?

  1. Use the existing CDN as mentioned above, Example: https://s.w.org/wp-content/blogs.dir/1/files/2022/12/sotw-drawer-background.png.
  2. Add a new CDN (eg, u.w.org) and use the BlogID in the URL (instead of a site hostname/path) to avoid the need for 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., something like https://u.w.org/{$BLOG_ID}/files/{$FILE}. Example: https://u.w.org/1/files/2022/12/sotw-drawer-background.png

(Note: I’ve used {$BLOG_ID}/files/{$PATH} here instead of {$BLOG_ID}/{$PATH} simply for the future expansion when/if other uploads are served from it, such as the BuddyPress/bbPressbbPress Free, open source software built on top of WordPress for easily creating forums on sites. https://bbpress.org. uploads which are in a subdirectory, and to simplify the request)

And either way, an automatic redirect would be preferred for requests not from the CDN. ms-files.php requests can be handled from within WordPress.

rewrite blogs.dir/(.+) https://u.w.org/$1 permanent;
or
rewrite blogs.dir/(.+) https://s.w.org/wp-content/blogs.dir/$1 permanent;

The existing CORS headers from s.w.org would be needed on any new CDN.

Access-Control-Allow-Methods: GET, HEAD
Access-Control-Allow-Origin: *

#prio3 #cdn #uploads