David E. Smith

The link is added by another plugin, that includes the below code:

function ws_show_jetpack_modlist() {
        if ( ! class_exists( 'Jetpack' ) ) {
                return; }

        jetpack_require_lib( 'admin-pages/class.jetpack-settings-page' );
        $jetpack_settings = new Jetpack_Settings_Page;
        $jetpack_settings->add_actions();

        $hook = add_submenu_page(
                'jetpack',
                'Modules',
                'Modules',
                'jetpack_manage_modules',
                'jetpack_modules',
                array(
                        $jetpack_settings,
                        'render',
                )
        );

        // This uses a <code>don't show if not connected</code> class so we need to add these manually.
        add_action( "admin_head-$hook", array( $jetpack_settings, 'admin_head' ) );
        add_action( "admin_print_styles-$hook", array( $jetpack_settings, 'admin_styles' ) );
        add_action( "admin_print_scripts-$hook", array( $jetpack_settings, 'admin_scripts' ) );
        add_action( "admin_print_styles-$hook", array( $jetpack_settings, 'additional_styles' ) );
}
add_action( 'jetpack_admin_menu', 'ws_show_jetpack_modlist' );

According to a comment in the code, the above was borrowed from jeherve’s Github.

Our sites are all on PHP 7.4, and no modifications were made either to Core or to Jetpack itself.

The most public and most visible site where I’ve seen this issue is The Source, but I have a few other examples (some of which unfortunately are not public). This site is, admittedly, one of the more complex examples, with over a dozen other plugins installed, and as it’s a production site I can’t easily do the standard troubleshooting (of turning off other plugins and/or switching to a stock theme).

It looks like the site no longer has the tagline, at least not in any of the obvious places. (I looked at the source of several pages, including the “hello world” page that you may no longer need.) It can take search engines hours to days to update their indexes, there’s not much you can do beyond be patient.

Just to tie this one off: I opened a bug. The bug so far has gotten about as much response as this support post. ??

I’ve used plugins like that before, but that’s not really the focus of my question. This feels like a bug, in that I would expect not to need a plugin if I’ve enabled ALLOW_UNFILTERED_UPLOADS. I don’t want to waste too much of the devs’ time, so I’m hoping to find out whether this is an intended behavior before going to Trac.

Done. Feature request submitted. Marking thread as resolved. Thank you! ??

The whole comment form lives in an iframe, I’m not sure that’s even possible without running afoul of cross-site security measures. In any event, it’s certainly more work than I want to do. Please consider this a feature request, though I admit it’s a niche request that may not really have a very large audience. Thank you for taking a look!

Maybe this highly advanced MS Paint image will help with what I’m looking for:

https://bureau42.com/wp-content/uploads/2021/02/Screenshot-2021-02-22-151935.png

That doesn’t quite do what I’m looking for – it effectively requires a visitor to have an account on the site to comment. I want that to be an option, but not the only option. I want visitors to be able to log in with a site-local account, or with any of the supported social networks.

Essentially I want to suppress the bottom part of the Jetpack comment form, where a visitor can enter an arbitrary name/email to go with their comment.

If it’s an internal site, maybe. (I’m the one who posted the above-linked issue.) I determined that, in my case, the plugin was not acting properly because many of my users are internal (in the RFC1918 sense, i.e. the IPs are all 10.x.x.x, or 192.168.x.x, or “private” IP addresses).

This is the un-tested two-minute implementation — basically, add a define() if you know you have users in private IP space, and ignore those flags in that case. This should prevent the change from adversely affecting any existing users, as it would require an affirmative action (editing wp-config.php) for there to be a change in the plugin’s behaviour.

diff -ru /home/davidsmith/wordpress-shared/plugins-shared/restricted-site-access/restricted_site_access.php ./restricted_site_access.php
--- /home/davidsmith/wordpress-shared/plugins-shared/restricted-site-access/restricted_site_access.php	2019-12-26 08:10:47.513527000 -0600
+++ ./restricted_site_access.php	2020-02-19 14:34:09.183198200 -0600
@@ -1484,7 +1484,12 @@
 			) as $ip ) {
 				$ip = trim( $ip ); // just to be safe.
 
-				if ( filter_var( $ip, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE ) !== false ) {
+				$filter_flags = FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE ;
+				if ( defined( 'RSA_ACCEPT_PRIVATE_IPS' ) && RSA_ACCEPT_PRIVATE_IPS === true ) {
+					$filter_flags = 0;
+				}
+
+				if ( filter_var( $ip, FILTER_VALIDATE_IP, $filter_flags ) !== false ) {
 					return $ip;
 				}
 			}

I think I’ve found the real problem.

When the plugin looks through the headers, to identify the apparent client IP address, it does so with the FILTER_FLAG_NO_PRIV_RANGE flag, to exclude private IP addresses. Which is most of my users, as the site I’m trying to restrict is primarily an intranet site. So all the validations fail, and I end up getting the REMOTE_ADDR value as it’s the last one in the list. And in my case, REMOTE_ADDR is the IP of a cache server in front of the Web server. (Clients connect to a load-balancer, which connects to Varnish, which connects to Apache when necessary.)

It’s easy enough to edit the plugin to disable those checks, but that’s not a long-term solution. Any chance for a “I know what I’m doing” checkbox that disables that (and maybe FILTER_FLAG_NO_RES_RANGE, in case a site is being accessed via loopback)?

That snippet (with modifications for my attributes) was basically perfect. Thanks!

It’d probably be better if this sort of thing were built into the plugin, as not everyone using Events Manager is going to be comfortable with PHP, but I could also see that code getting really hairy to implement.

Fortunately for me, but unfortunately for everyone else, at some point in the last couple days the Google Maps integration started working on my site. It could be a combination of settings I’d changed, related to caching somewhere (server opcode caching, CloudFlare, browser, who knows), it could have been a hiccup on Google’s end, it could be any number of things.

I’m resolving my forum post, but I certainly encourage others having similar issues to create their own threads to dig into it.

I have two concerns with that link.

First, it only shows how to make the interval really long. I want to disable the feature completely, so that I don’t have to remember this in twenty years’ time. I suspect that many people using external authentication schemes will benefit from the ability to completely disable this feature. (As an interim measure, I’ll be doing an add_filter('admin_email_check_interval', (240 * MONTH_IN_SECONDS)); but I’m hoping that eventually I can just do a __return_false and be done with it forever.

Second, this should be documented somewhere other than the source itself and a random third-party blog. I’m still curious as to why the blog post announcing it disappeared just a few hours after it was posted.

I get that WordPress is “decisions, not options,” and I certainly understand that this feature is useful in a lot of cases. Maybe even most cases, but certainly not all. In my case, it will be actively confusing (since my users can’t change their email from inside WordPress).