Context Navigation

Changes between Version 1 and Version 2 of Ticket #2823, comment 13

v1	v2
1	1	> The first problem to solve is #2. I don't think we really need ipv6 support yet since the API should always use REMOTE_ADDR and the WordPress.org API currently doesn't have any AAAA records.
2	2
3		The IP is not the REMOTE_ADDR in most cases - it's the WordPress user client IP, not the server IP. There's some "anonymisation" stuff in there ~~([see maybe_anonymize_ip_address: https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/class-wp-community-events.php#L231])~~. The exception is when the client IP provided is a private range, in which case it uses REMOTE_ADDR.
	3	The IP is not the REMOTE_ADDR in most cases - it's the WordPress user client IP, not the server IP. There's some "anonymisation" stuff in there - [https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/class-wp-community-events.php#L231 see maybe_anonymize_ip_address()]. The exception is when the client IP provided is a private range, in which case it uses REMOTE_ADDR.
4	4
5	5	Would it be better if the client browser was making the request directly? (and not proxied through WordPress) - the detect-location call would need to be made on every request in that case, and not just on the first call / when user searches for a location change.