Add site test for page cache #6456

dhaval-parekh · 2021-07-15T05:57:35Z

Summary

Page Caching Detected

Page Caching Not Detected

No error scenario:

Error scenario:

Absent Persistent Object Caching when Page Caching Present

As outlined in #5780 (comment), when page caching is detected, the persistent object caching will no longer have a status of recommended but will rather be good.

Checklist

My code is tested and passes existing tests.
My code follows the Engineering Guidelines (updates are often made to the guidelines, check it out periodically).

github-actions · 2021-07-15T06:02:12Z

Plugin builds for 4d905f2 are ready 🛎️!

Download development build
Download production build

pierlon · 2021-07-20T11:21:28Z

includes/class-amp-http.php

+				$intl_idna_variant = defined( 'INTL_IDNA_VARIANT_UTS46' ) ? INTL_IDNA_VARIANT_UTS46 : false;
+
 				// phpcs:ignore PHPCompatibility.Constants.RemovedConstants.intl_idna_variant_2003Deprecated
-				$domain = idn_to_utf8( $domain, IDNA_DEFAULT, defined( 'INTL_IDNA_VARIANT_UTS46' ) ? INTL_IDNA_VARIANT_UTS46 : INTL_IDNA_VARIANT_2003 );
+				$intl_idna_variant = ( empty( $intl_idna_variant ) && defined( 'INTL_IDNA_VARIANT_2003' ) ) ? INTL_IDNA_VARIANT_2003 : false;
+
+				// The third parameter is set explicitly to prevent issues with newer PHP versions compiled with an old ICU version.
+				if ( ! empty( $intl_idna_variant ) ) {
+					$domain = idn_to_utf8( $domain, IDNA_DEFAULT, $intl_idna_variant );
+				}


As you noted in chat @dhaval-parekh this change was necessary due to phpstan throwing the error:

------ -------------------------------------------------------------------- Line includes/class-amp-http.php ------ -------------------------------------------------------------------- 240 Constant INTL_IDNA_VARIANT_2003 not found. 💡 Learn more at https://phpstan.org/user-guide/discovering-symbols ------ --------------------------------------------------------------------

This is not being logged as an error currently as this only occurs on PHP 8. The PHP static analysis GHA currently runs on PHP 7.4 so we'll have to bump that.

I've opened #6466 to bump the PHP version to 8.0, amongst other related changes.

Why did this start failing in this PR?

If I recall correctly the INTL_IDNA_VARIANT_2003 constant did not have a is_defined check and so phpstan flagged it as it would be undefined in PHP 8.

Oh, so because Dhaval was doing development locally using PHP 8. It wasn't failing on GHA (yet).

src/Admin/SiteHealth.php

pierlon · 2021-07-20T11:52:04Z

src/Infrastructure/Injector/SimpleInjector.php

+			if ( null === $type ||
+				( is_a( $type, 'ReflectionType' ) && method_exists( $type, 'isBuiltin' ) && $type->isBuiltin() )
+			) {


I see that this change was also necessary due to phpstan on PHP 8 failing with:

------ ---------------------------------------------------------- Line src/Infrastructure/Injector/SimpleInjector.php ------ ---------------------------------------------------------- 328 Call to an undefined method ReflectionType::isBuiltin(). ------ ----------------------------------------------------------

According to the PHP docs the isBuiltin() method has been moved to the ReflectionNamedType class in PHP 8:

ReflectionType has become abstract and ReflectionType::isBuiltin() has been moved to ReflectionNamedType::isBuiltin().

I've opened #6466 to bump the PHP version to 8.0, amongst other related changes.

tests/php/test-class-site-health.php

src/Admin/SiteHealth.php

pierlon · 2021-07-21T10:25:56Z

src/Admin/SiteHealth.php

+			add_action( 'admin_print_styles-site-health.php', [ $this, 'add_styles' ] );
+		}
+
+		add_action( 'template_redirect', [ $this, 'render_random_string_page' ] );


This could be limited to only users who have the ability to view Site Health checks:

Suggested change

add_action( 'template_redirect', [ $this, 'render_random_string_page' ] );

if ( current_user_can( 'view_site_health_checks' ) ) {

add_action( 'template_redirect', [ $this, 'render_random_string_page' ] );

}

@pierlon We should not add that check. Since idea is to check if page cache is enabled for end-user or not. And for that reason, we make a plain request (without any cookies). If we add that check then when we make a request that won't execute.

The only time we would need this request to execute is to check if page caching works, no?

If we add that check then when we make a request that won't execute.

It won't execute for users who can't view the Site Health checks, which I think would be valid in this case. One problem I did not recognize at the time was that if page caching was enabled it would be possible for a non-authenticated user to request that URL and cache the home page instead of the random number. That could be resolved by using a random query param value (like home_url( '?amp_page_cache=' . wp_rand( 1000, 10000 ) ) instead of home_url( '?amp_page_cache=1' ).

@pierlon I think this does need to be added for unauthenticated users. The site health check is run by an authenticated user, but the requests are made in an unauthenticated context. So the template_redirect needs to be added for unauthenticated users.

@dhaval-parekh After thinking about this some more, I think the use of a query parameter will be problematic a some caching plugins prevent all caching altogether when query parameters are present.

So here's my suggestion:

Use a HTTP request header to request the random string, and send that random string back via an HTTP response header rather than dying.

Even better, perhaps the entire random variable in the response was a bad idea from me to begin with. To detect page caching, should we not rather be checking the Expires response header that in the future or that Cache-Control that has a non-zero max-age? Alongside Expires/Cache-Control we can also check if the response includes an ETag header and/or a Last-Modified header, which are also signals that the response is cacheable.

If doing the latter, we don't need to do multiple requests. We can just do one request to the homepage, without any cookies and without any custom request headers or query parameters. If that one request returns with Expires/Cache-Control/Last-Modified/ETag that indicates caching is page enabled, then that all we need.

This presumes that page caching always will include HTTP response headers that tell the client they can cache the pages as well, which I think is a fair assumption. Caching plugins are “behooved” to send such response headers as it allows other caching layers to cache and serve back responses without requiring hits to origin.

Nevertheless, if it turns out that caching plugins don't send back response headers for client-cacheability, then there will still be the need to do multiple requests as in option 1 above, where the client can send a X-AMP-Request-Random-Number: 1 request header, and then the response can include an X-AMP-Random-Number: ... response header. By using HTTP headers, we can avoid false negatives for detection while also avoiding accidentally polluting the cache by using harmless HTTP headers.

I think both of these approaches are needed actually. The Site Health test can have two degrees of passing:

Server-caching: Repeated unauthenticated requests to the server return the same response (by checking the random response header).

Client-caching: Server sends back Cache-Control/Expires/Last-Modified/ETag headers.

Both of these should be checked because both will result in a better page experience. For 1, this reduces the TTFB for users requesting a page even if they have not visited before. For 2, this allows browsers to serve from disk cache a page that they previously visited, either without hitting the server at all (if within the max-age) or by making a conditional request (sending If-Modified-Since or If-None-Match requests headers).

The first check should be critical in terms of priority. Otherwise, if that passes, the second one would be recommended.

Note: If repeated requests with an X-AMP-Request-Random-Number request header result in responses without a X-AMP-Random-Number response header, it could be that there is a caching layer that is stripping that out. In such case, that could indicate that caching is working and the client-caching check should be used to confirm that server-caching is indeed working.

pierlon

Besides my suggestion in #6456 (comment), this looks great ✅.

Passing unto @westonruter for review.

pierlon · 2021-07-22T17:39:58Z

src/Admin/SiteHealth.php

+				'label' => $this->get_badge_label(),
+				'color' => $is_using_page_cache ? 'green' : 'orange',
+			],
+			'description' => esc_html__( 'The AMP plugin performs at its best when page object cache is enabled.', 'amp' ),


Suggested change

'description' => esc_html__( 'The AMP plugin performs at its best when page object cache is enabled.', 'amp' ),

'description' => esc_html__( 'The AMP plugin performs at its best when page caching is enabled.', 'amp' ),

src/Admin/SiteHealth.php

pierlon · 2021-07-22T18:09:06Z

src/Admin/SiteHealth.php

+			add_action( 'admin_print_styles-site-health.php', [ $this, 'add_styles' ] );
+		}
+
+		add_action( 'template_redirect', [ $this, 'render_random_string_page' ] );


The only time we would need this request to execute is to check if page caching works, no?

If we add that check then when we make a request that won't execute.

It won't execute for users who can't view the Site Health checks, which I think would be valid in this case. One problem I did not recognize at the time was that if page caching was enabled it would be possible for a non-authenticated user to request that URL and cache the home page instead of the random number. That could be resolved by using a random query param value (like home_url( '?amp_page_cache=' . wp_rand( 1000, 10000 ) ) instead of home_url( '?amp_page_cache=1' ).

…amp-wp into add/4386-detect-page-caching

src/Admin/SiteHealth.php

westonruter · 2021-07-26T18:42:52Z

src/Admin/SiteHealth.php

+		if ( ! empty( $query_var ) ) {
+			die( esc_html( wp_rand( 1000, 10000 ) ) );
+		}


Problem: some page caching plugins may ignore custom query parameters from impacting the cache, and this could result in the random number page being cached for responses without the query parameter.

westonruter · 2021-07-26T18:47:53Z

src/Admin/SiteHealth.php

+			add_action( 'admin_print_styles-site-health.php', [ $this, 'add_styles' ] );
+		}
+
+		add_action( 'template_redirect', [ $this, 'render_random_string_page' ] );


@pierlon I think this does need to be added for unauthenticated users. The site health check is run by an authenticated user, but the requests are made in an unauthenticated context. So the template_redirect needs to be added for unauthenticated users.

@dhaval-parekh After thinking about this some more, I think the use of a query parameter will be problematic a some caching plugins prevent all caching altogether when query parameters are present.

So here's my suggestion:

Use a HTTP request header to request the random string, and send that random string back via an HTTP response header rather than dying.

Even better, perhaps the entire random variable in the response was a bad idea from me to begin with. To detect page caching, should we not rather be checking the Expires response header that in the future or that Cache-Control that has a non-zero max-age? Alongside Expires/Cache-Control we can also check if the response includes an ETag header and/or a Last-Modified header, which are also signals that the response is cacheable.

If doing the latter, we don't need to do multiple requests. We can just do one request to the homepage, without any cookies and without any custom request headers or query parameters. If that one request returns with Expires/Cache-Control/Last-Modified/ETag that indicates caching is page enabled, then that all we need.

This presumes that page caching always will include HTTP response headers that tell the client they can cache the pages as well, which I think is a fair assumption. Caching plugins are “behooved” to send such response headers as it allows other caching layers to cache and serve back responses without requiring hits to origin.

Nevertheless, if it turns out that caching plugins don't send back response headers for client-cacheability, then there will still be the need to do multiple requests as in option 1 above, where the client can send a X-AMP-Request-Random-Number: 1 request header, and then the response can include an X-AMP-Random-Number: ... response header. By using HTTP headers, we can avoid false negatives for detection while also avoiding accidentally polluting the cache by using harmless HTTP headers.

westonruter · 2021-07-26T19:10:16Z

src/Admin/SiteHealth.php

+			add_action( 'admin_print_styles-site-health.php', [ $this, 'add_styles' ] );
+		}
+
+		add_action( 'template_redirect', [ $this, 'render_random_string_page' ] );


I think both of these approaches are needed actually. The Site Health test can have two degrees of passing:

Server-caching: Repeated unauthenticated requests to the server return the same response (by checking the random response header).

Client-caching: Server sends back Cache-Control/Expires/Last-Modified/ETag headers.

Both of these should be checked because both will result in a better page experience. For 1, this reduces the TTFB for users requesting a page even if they have not visited before. For 2, this allows browsers to serve from disk cache a page that they previously visited, either without hitting the server at all (if within the max-age) or by making a conditional request (sending If-Modified-Since or If-None-Match requests headers).

The first check should be critical in terms of priority. Otherwise, if that passes, the second one would be recommended.

westonruter · 2021-07-26T19:10:44Z

src/Admin/SiteHealth.php

+	 */
+	private function is_site_has_page_cache() {
+
+		$request_url    = home_url( '?amp_page_cache=1' );


See notes above about how an HTTP request header will likely be a better approach.

westonruter · 2021-07-26T19:13:30Z

src/Admin/SiteHealth.php

+			add_action( 'admin_print_styles-site-health.php', [ $this, 'add_styles' ] );
+		}
+
+		add_action( 'template_redirect', [ $this, 'render_random_string_page' ] );


Note: If repeated requests with an X-AMP-Request-Random-Number request header result in responses without a X-AMP-Random-Number response header, it could be that there is a caching layer that is stripping that out. In such case, that could indicate that caching is working and the client-caching check should be used to confirm that server-caching is indeed working.

src/Admin/SiteHealth.php

pierlon · 2021-08-12T12:18:02Z

src/Admin/SiteHealth.php

+		}
+
+		if ( wp_doing_ajax() ) {
+			add_action( 'wp_ajax_health-check-site-status', [ $this, 'ajax_site_status' ], 11 );


This could instead run at the wp_ajax_health-check-amp-page_cache action, which would simplify the ajax_site_status method and could be renamed to ajax_check_page_cache, for example.

Suggested change

add_action( 'wp_ajax_health-check-site-status', [ $this, 'ajax_site_status' ], 11 );

add_action( 'ajax_site_status', [ $this, 'ajax_check_page_cache' ] );

Hey @pierlon

We can not change the action name, since it triggers from the "Health Check" plugin.

Oh OK I see. However, this test is not running whenever the Health Check plugin is disabled though, as the AJAX action is now health-check-amp-page_cache instead of wp_ajax_health-check-site-status:

Health Check plugin disabled:

Health Check plugin enabled:

However, this test is not running whenever the Health Check plugin is disabled though

This test will only be on the "Health Check" page if the health-check plugin is active. Here we are just adding one more callback in already registered ajax call specifically for amp_page_cache.

Right, but on the Site Health page the page cache test is not running because there is no action registered to return the test result. With the Health Check plugin enabled it works just fine.

As of WordPress 5.2 and r49154, the Site Health tests can now be invoked via the REST API . I'll try reworking this to make use of that.

Sorry, I mean as of WordPress 5.6: https://make.wordpress.org/core/2020/11/15/site-health-check-changes-in-5-6/

Eww, but the Site Health plugin doesn't support the REST API async tests 😦

OK, the issue is that the Health Check plugin is way out of date. The last release was 2 years ago. There are various issues reported in the GitHub repo about incompatibilities with current tests. So I'm going to add logic to prevent this REST-based async test from being added when on WP<5.6 and when this stale version of Health Check is active.

src/Admin/SiteHealth.php

westonruter · 2021-09-17T19:20:49Z

I just tested this with WP Super Cache and… it doesn't work. Looks like it's a fatal flaw in my proposed solution. For one, by default HTTP headers are not cached with the page content:

Even when that is enabled, the plugin will only cache the known headers, which naturally does not include any X-AMP... request header.

So yeah, my whole random number in a request header as I proposed in #6456 (comment) was wrong.

We'll instead need to only look at response headers to see if caching is enabled.

pierlon · 2021-09-17T19:25:13Z

Can confirm I had to fine-tune W3 Total Cache to work as well. I had to tell it to manually cache the header:

westonruter · 2021-09-17T19:29:23Z

The first request made to a page when WP Super Cache is enabled will return no Cache-Control response header (which seems like an omission), whereas the second request when a page has been cached will return: Cache-Control: max-age=3, must-revalidate. So at least for WP Super Cache we can check for page caching by making 2 requests to the homepage, and if the second one includes a Cache-Control response header with a max-age value greater than 0, then that would be a pass.

@pierlon What does W3 Total Cache return for repeated requests to the homepage?

westonruter · 2021-09-17T19:35:42Z

For Pantheon with Varnish, the relevant response headers (on amp-wp.org):

age: 10
cache-control: public, max-age=600

We could continue to check for a non-zero age as well as a max-age in Cache-Control.

Looking at a post from WP Rocket blog, they return:

last-modified: Fri, 17 Sep 2021 13:56:37 GMT
etag: "61449e95-18219"
expires: Sun, 17 Oct 2021 19:33:07 GMT
cache-control: max-age=2592000

The 1-month expiration on the document is quite surprising to me. Nevertheless, it is a number greater than zero, so it would pass our page cache test.

pierlon · 2021-09-17T19:38:21Z

@pierlon What does W3 Total Cache return for repeated requests to the homepage?

By default it sends:

cache-control: max-age=3600, public

westonruter · 2021-09-17T19:41:14Z

Looking at WordPress.com for an example post, Batcache sends:

last-modified: Fri, 17 Sep 2021 19:38:00 GMT
cache-control: max-age=300, must-revalidate
x-nananana: Batcache

For Batcache, by default it will only cache a page after 2 visits.

…eader detection

tests/e2e/specs/admin/amp-options.js

This reverts commit 5c0507b.

…detect-page-caching * 'develop' of github.com:ampproject/amp-wp: Only verify save button is disabled after being clicked

…ponse header detection

…ent object cache

westonruter

Whew, this was another journey!

pierlon · 2021-09-18T03:05:48Z

src/Admin/SiteHealth.php


 		if ( ! $is_using_object_cache ) {
+			if ( $has_page_caching ) {


Given that the page cache test is async and this is direct, there would be a chance of this being a false positive right?

Yes, the first time the Site Health tests run then this will always be false. I don't see a way around that so I think it's acceptable for the first time.

Hmm yea, seems like an acceptable trade off.

src/Admin/SiteHealth.php

pierlon · 2021-09-18T03:17:25Z

src/Admin/SiteHealth.php

+			}
+
+			$expires_header = wp_remote_retrieve_header( $http_response, 'expires' );
+			if ( $expires_header && strtotime( $expires_header ) > time() ) {


src/Admin/SiteHealth.php

Co-authored-by: Pierre Gordon <[email protected]>

pierlon

Thanks for you hard work on this @dhaval-parekh and kudos to @westonruter for getting across the finish line. LGTM!

Add site test for page cache

8cfaa2f

dhaval-parekh requested review from westonruter and pierlon July 15, 2021 14:49

pierlon suggested changes Jul 20, 2021

View reviewed changes

dhaval-parekh mentioned this pull request Jul 21, 2021

Show admin notice to flush cache when user change the template mode or reader theme #6467

Merged

2 tasks

dhaval-parekh self-assigned this Jul 21, 2021

pierlon suggested changes Jul 21, 2021

View reviewed changes

tests/php/test-class-site-health.php Outdated Show resolved Hide resolved

src/Admin/SiteHealth.php Outdated Show resolved Hide resolved

dhaval-parekh added 2 commits July 21, 2021 15:48

Apply suggestions from PR

405adf5

Apply suggestions from PR

916f9c3

dhaval-parekh requested a review from pierlon July 21, 2021 10:22

pierlon suggested changes Jul 21, 2021

View reviewed changes

pierlon reviewed Jul 22, 2021

View reviewed changes

dhaval-parekh added 3 commits July 22, 2021 19:44

Add site test for page cache

3249995

Apply suggestions from PR

d834fb7

Apply suggestions from PR

963939f

pierlon suggested changes Jul 22, 2021

View reviewed changes

Merge branch 'add/4386-detect-page-caching' of github.com:ampproject/…

bab8dba

…amp-wp into add/4386-detect-page-caching

westonruter requested changes Jul 26, 2021

View reviewed changes

dhaval-parekh added 6 commits August 3, 2021 20:12

Merge branch 'develop' into add/4386-detect-page-caching

48ced6f

Make page cache test async

900c3dc

Update logic to detect page caching

e00ca0c

Add unit test cases

c59c364

update unit test cases

358f998

Update unit test cases

43b7746

dhaval-parekh requested a review from pierlon August 10, 2021 07:28

pierlon suggested changes Aug 12, 2021

View reviewed changes

dhaval-parekh added 2 commits August 13, 2021 14:09

Apply suggestion from PR

d7417c5

Remove the uses of json_test_amp_page_cache method

af3aa08

dhaval-parekh requested a review from pierlon August 13, 2021 12:17

Require future expires header for client-side caching

a451801

Eliminate attempting to challenge page caching in favor of response h…

df25199

…eader detection

pierlon reviewed Sep 17, 2021

View reviewed changes

tests/e2e/specs/admin/amp-options.js Outdated Show resolved Hide resolved

westonruter added 7 commits September 17, 2021 14:27

Revert "Increase timeout for selector"

fb80ec3

This reverts commit 5c0507b.

Merge branch 'develop' of github.com:ampproject/amp-wp into add/4386-…

893a000

…detect-page-caching * 'develop' of github.com:ampproject/amp-wp: Only verify save button is disabled after being clicked

fixup! Eliminate attempting to challenge page caching in favor of res…

5f70780

…ponse header detection

Improve tests for page caching

53a4dfd

Explain how page cache detection is performed

fdf7165

Store results of page caching to reduce severity of missing a persist…

afe258e

…ent object cache

Eliminate use of deprecated assertion

c31d3c8

westonruter assigned westonruter and unassigned dhaval-parekh Sep 17, 2021

Remove absolete wp_doing_ajax filter

47e46c7

westonruter approved these changes Sep 17, 2021

View reviewed changes

westonruter requested a review from pierlon September 17, 2021 23:09

Improve test coverage for get_persistent_object_cache_learn_more_action

72e2645

pierlon suggested changes Sep 18, 2021

View reviewed changes

westonruter and others added 2 commits September 17, 2021 21:32

Simplify language for condition for what headers are looked for

c6fde2f

Co-authored-by: Pierre Gordon <[email protected]>

Advise to check loopback request test

4d905f2

pierlon approved these changes Sep 18, 2021

View reviewed changes

westonruter merged commit 77ff4c4 into develop Sep 18, 2021

westonruter deleted the add/4386-detect-page-caching branch September 18, 2021 05:48

westonruter added the Changelogged Whether the issue/PR has been added to release notes. label Dec 14, 2021

westonruter mentioned this pull request Mar 8, 2022

Add Site Health test for full page caching (advanced cache) WordPress/performance#220

Closed

	'description' => esc_html__( 'The AMP plugin performs at its best when page object cache is enabled.', 'amp' ),
	'description' => esc_html__( 'The AMP plugin performs at its best when page caching is enabled.', 'amp' ),

	add_action( 'wp_ajax_health-check-site-status', [ $this, 'ajax_site_status' ], 11 );
	add_action( 'ajax_site_status', [ $this, 'ajax_check_page_cache' ] );

Add site test for page cache #6456

Add site test for page cache #6456

Conversation

dhaval-parekh commented Jul 15, 2021 • edited by westonruter Loading

Summary

Page Caching Detected

Page Caching Not Detected

Absent Persistent Object Caching when Page Caching Present

Checklist

github-actions bot commented Jul 15, 2021 • edited Loading

Choose a reason for hiding this comment

pierlon Jul 20, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

westonruter Sep 10, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pierlon Jul 20, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pierlon left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pierlon Sep 2, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

westonruter commented Sep 17, 2021

pierlon commented Sep 17, 2021

westonruter commented Sep 17, 2021

westonruter commented Sep 17, 2021

pierlon commented Sep 17, 2021

westonruter commented Sep 17, 2021

westonruter left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

westonruter Sep 18, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pierlon left a comment

Choose a reason for hiding this comment

dhaval-parekh commented Jul 15, 2021 •

edited by westonruter

Loading

github-actions bot commented Jul 15, 2021 •

edited

Loading

pierlon Jul 20, 2021 •

edited

Loading

westonruter Sep 10, 2021 •

edited

Loading

pierlon Jul 20, 2021 •

edited

Loading

pierlon Sep 2, 2021 •

edited

Loading

westonruter Sep 18, 2021 •

edited

Loading