Alexandre Froger

Hi @kingcooper ,

Is there any idea how to fix it? No errors in error log.

The best would be to address these below, because if I cannot reproduce the issue with my own installation, then this is near impossible to troubleshoot.

Could you let me test that the issue also happens with absolutely no other plugin activated?
During my test, there was at least 12 plugins in use, as well as the Astra theme activated. Each of them (and any I could not detect) may be involved in the issue.

What I mean is, I would like to test for myself the site without any other plugin turned on, and a default theme, and replicate the issue there.
This is because although I have seen WPRUS work normally with many plugins (and have many on my test installs), there is virtually no way to test every single plugin.
The best is to isolate the issue first, by establishing what is different between when it works, and when it does not.

Are the warnings you mention happening only when WPRUS is on, with only WPRUS and a default theme?
I also cannot reproduce, and looking at the referred code, this happens when a plugin or theme attempts to register a function/method with a priority set to a floating point number (instead of an integer), which is something WPRUS does nowhere in its entire code base

Also, could you please send a screenshot of your settings? You may blur or leave out the address of the remote site if necessary.

Thank you for uploading screenshots, however I cannot access the 2 last ones: here is what I see.

And in the browser’s logs:

GET https://s3.amazonaws.com/i.snag.gy/g9oLK3.jpg?nocache=1739492851367 403 (Forbidden)
Image load failed.

Best,

Hello @kingcooper,

By visiting https://integritytoysales.net/wprus/login and getting a page not found, I can confirm the WPRUS plugin is deactivated.

I proceeded to get a new reset password email, and clicking the link I landed on the password reset page without error.

If you need, you may reactivate WPRUS.

Could you let me test that the issue also happens with absolutely no other plugin activated?
During my test, there was at least 12 plugins in use, as well as the Astra theme activated. Each of them (and any I could not detect) may be involved in the issue.

Also, could you please send a screenshot of your settings? You may blur or leave out the address of the remote site if necessary.

Hi @kingcooper
I tried to register, got the email, and when clicking on it to set my password, I got an error message:

This key is invalid or has already been used. Please reset your password again if needed.

So, the problem you encounter is not solely bound to password reset.
I tried on my own test installs (without all the plugins and themes you have) and could not reproduce the issue.
Could you please deactivate the WPRUS plugin, so that I can test again?

Also, nothing was noted about the redirect action I mentioned.

Yes it was noted ; most of my previous message was about it, actually.

Here is the preface:

Only bugs are addressed, if and only if properly documented ; they are addressed either here or on Github, but must have a reliable way to be reproduced with 2 minimal installs of WordPress ; better if the report actually pinpoints where in the code it occurs (and unlikely to be addressed otherwise).

There is no email support, no troubleshoot of user installs, no experimenting and testing based on non-technical or anecdotal description. This would be the case if I closed the plugin here and charged for updates, maintenance, and hands-on support, which I have no plan to do so far.

And here is the actual note:

This is why you need to find your own proper technical support. I am including this here to manage your expectations regarding the redirect issue you’re referring to in your last message.

Please make sure you also acknowledged:

When you have been able to properly document your issue, you are welcome to open a new topic, I would be glad to improve the plugin for everyone.

Oh I think I did understand: if any of the headers I suggested to test (and it would be useful to know which one) is showing the right IP, it does mean that, internally, on the network somewhere, the header with the REMOTE_ADDR key was set to a different value.

How, I can’t know, and I don’t think it matters in the context of WPRUS ; that IP is what is set in REMOTE_ADDR everywhere else on the receiving site when a request from your source site is received (and possibly in other cases). If this is a concern for you, then you may want to keep investigating, by sending test requests yourself from the source site with your own code, and checking the headers on the receiving site in your own code (no need to rely on WPRUS in any way for that, and it is entirely out of scope).

Anyway ; now that you know what header to check, you can create your own plugin, or a code snippet, and use the provided filters, something like:

// add this code during init hook, with a priority greater than PHP_INT_MIN + 100
// change 'MY_HEADER_KEY' to the header value you want to check
add_action(
    'init',
    function () {
        add_filter(
            'wprus_is_authorized_remote',
            function ( $is_authorized_remote, $method, $remote_addr, $ip_whitelist ) {
                $header_to_check = 'MY_HEADER_KEY';

                if (
                    $is_authorized_remote ||
                    'POST' !== $method ||
                    ! isset( $_SERVER[ $header_to_check ] )
                ) {
                    return $is_authorized_remote;
                }

                $ip    = $_SERVER[ $header_to_check ];
                $match = function ( $ip, $range ) {
                    list ( $subnet, $bits ) = explode( '/', $range );
                    $ip                     = ip2long( $ip );
                    $subnet                 = ip2long( $subnet );

                    if ( ! $ip || ! $subnet || ! $bits ) {
                        return false;
                    }

                    $mask    = -1 << ( 32 - $bits );
                    $subnet &= $mask; // in case the supplied subnet was not correctly aligned

                    return ( $ip & $mask ) === $subnet;
                };

                foreach ( $ip_whitelist as $range ) {

                    if ( $match( $ip, $range ) ) {
                        $is_authorized_remote = true;

                        break;
                    }
                }

                return $is_authorized_remote;
            },
            10,
            4
        );
    },
    PHP_INT_MIN + 50
);

This is a proof of concept based on the documented wprus_is_authorized_remote filter.
The same piece of advice as before applies: do not simply execute code pasted here. Review it, understand it, and only then consider using it.

Cheers

Hi xtension!

Glad you found the source of this IP!
It is as suspected: part of the network setup, and not related to WPRUS proper.

This plugin is free, and does not have a premium tier. It is maintained, but it is up to you to spend the resources to integrate it with your specific environment.

A stated in the main plugin page’s description:

Each bug report will be addressed in a timely manner if properly documented – previously unanswered general inquiries and issues reported on the WordPress forum may take significantly longer to receive a response (if any).

Only issues occurring with included plugin features mentioned in “Synchronise all user data”, core WordPress and default WordPress themes (incl. WooCommerce Storefront) will be considered.

Only bugs are addressed, if and only if properly documented ; they are addressed either here or on Github, but must have a reliable way to be reproduced with 2 minimal installs of WordPress ; better if the report actually pinpoints where in the code it occurs (and unlikely to be addressed otherwise).

There is no email support, no troubleshoot of user installs, no experimenting and testing based on non-technical or anecdotal description. This would be the case if I closed the plugin here and charged for updates, maintenance, and hands-on support, which I have no plan to do so far. This is why you need to find your own proper technical support. I am including this here to manage your expectations regarding the redirect issue you’re referring to in your last message.

When you have been able to properly document your issue, you are welcome to open a new topic, I would be glad to improve the plugin for everyone.
I am considering this one as resolved.

Best,
Alexandre Froger

Hi xtensions

I understand the frustration. It is also present on my side, since I cannot reproduce the behavior at all. All I can do is inform you of how the plugin operates, and there is no more standard way than what it does: use $_SERVER[‘REMOTE_ADDR’]. Other headers could be checked but they may be tricky to rely on, so instead I make the IP whitelist an extra safeguard, not a requirement, and mostly rely on strong encryption of the communications. Security in layers and all that.

I would advise you to consider checking the following headers and see if the real IP is in there, using something like:

// Add an action to the init hook
add_action( 'init', function () {

    // Check if the wprus_log function exists and if the request is for the wprus plugin
    if (
        ! function_exists( 'wprus_log' ) ||
        false === strpos( $_SERVER['REQUEST_URI'], '/wprus/' )
    ) {
        return;
    }

    // Initialize the possible headers that can contain the IP
    $headers = array(
        'HTTP_CF_CONNECTING_IP',
        'HTTP_CLIENT_IP',
        'HTTP_X_FORWARDED_FOR',
        'HTTP_X_FORWARDED',
        'HTTP_X_CLUSTER_CLIENT_IP',
        'HTTP_FORWARDED_FOR',
        'HTTP_FORWARDED',
        'REMOTE_ADDR',
    );

    // Loop through the headers and check if the IP is valid
    foreach ( $headers as $header ) {

        // Check if the header is set
        if ( ! empty( $_SERVER[ $header ] ) ) {
            // Split the IP list
            $ip_list = explode( ',', $_SERVER[ $header ] );
            // Get the first IP
            $ip = trim( $ip_list[0] );

            // Check if the IP is valid
            if (
                filter_var(
                    $ip,
                    FILTER_VALIDATE_IP,
                    // Exclude private and reserved ranges
                    FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE
                )
            ) {
                // Log the IP
                wprus_log( "Found a proper IP [$ip] for header [$header]", 'info', 'db_log' );
            } else {
                // Log the invalid IP
                wprus_log( "Private, reserved, or invalid IP [$ip] for header [$header]", 'info', 'db_log' );
            }
        } else {
            // Log that the header is not set
            wprus_log( "Header [$header] is not set", 'info', 'db_log' );
        }
    }
} );

You can use the Code Snippets plugin for that, for example. Then, from there, you could report here, and we could work together in finding ways to maybe use the header that works in your case. But please, never blindly copy-paste code you see online, this one included: understand and double-check it, maybe with AI tools, better with a professional.

That’s what I mean by hiring a programmer or a sysadmin, or devOps. The issue you are describing here is not preventing the plugin from working safely, is about an optional feature, is specific to your install, and requires studying the code (and producing some, as seen above) to troubleshoot, which takes up resources (time being one of them).

I sincerely hope you find the source and suggest a fix for the issue, so that it can be a contribution for the other users you mention as well.

Hi gardenal and thanks for using WPRUS!

Let’s try to isolate the issue. You are mentioning both “metadata” and “metabox” ; these are 2 different concepts in WordPress.

Metaboxes are UI elements allowing core, plugins and themes to add new functionalities. The data they save may or may not be metadata (they can be anything, it’s up to the logic behind when submitting the form). Indeed, WPRUS uses metaboxes for its own options, and they are not saved as metadata, but as, well, options!
Therefore, this is not strictly speaking what WPRUS synchronizes.

Metadata in this WordPress context is extra data associated with a main entity: post, orders (in the case of WooCommerce), and, here, users. WPRUS only synchronizes user metadata – no post, no order, etc.
For that, the sending end and the receiving end must be configured: the sending end must specify what metadata is sent, and the receiving end must specify what metadata it accepts.
Please see the screenshot below:

The lists contain the metadata that exist on the sites. At least one user on the site where the configuration is being set must have the metadata assigned for the associated key to show in the lists.

If, for instance, you need to send the metadata mobile_number, this key must exist for at least one user on the sending end, and must be chosen in the “List of metadata to transfer”. The receiving end may be configured to accept all metadata, or if you want to do some filtering, then the same restriction applies.

I hope this helps!

• This reply was modified 1 month, 2 weeks ago by Alexandre Froger.
• This reply was modified 1 month, 2 weeks ago by Alexandre Froger.
• This reply was modified 1 month, 2 weeks ago by Alexandre Froger.
• This reply was modified 1 month, 2 weeks ago by Alexandre Froger.
• This reply was modified 1 month, 2 weeks ago by Alexandre Froger.
• This reply was modified 1 month, 2 weeks ago by Alexandre Froger.

Hi xtensions,

Web hosting environments are generally set up so that—even if DHCP is used internally—the IP address that external sites see remains consistent and controlled by the host.

How DHCP Is Used by Web Hosts

• Internal vs. External IPs:
  Many web hosts might use DHCP within their internal networks to assign IP addresses to servers or devices dynamically. However, these internal IP addresses are not usually the ones used for communicating with the public Internet.
• Public (Static) IP Addresses:
  Outgoing requests from a web server are typically sent from a public IP address that is either statically assigned or managed in a way that it appears static to the outside world. Even if the server’s internal IP is assigned via DHCP, Network Address Translation (NAT) or other routing mechanisms ensure that external requests use the public IP address provided by the hosting provider.

Impact on $_SERVER[‘REMOTE_ADDR’]

• What $_SERVER[‘REMOTE_ADDR’] Represents:
  On the receiving end of an HTTP request, $_SERVER['REMOTE_ADDR'] contains the IP address of the client making the request. In the context of a request from one server to another, this will be the public IP address of the originating server.
• DHCP’s Role:
  Whether a web host uses DHCP to manage its internal network does not affect the public-facing IP address. The public IP—what shows up in $_SERVER['REMOTE_ADDR']—is determined by the outgoing interface (and any intervening NAT or proxy), not by the internal DHCP process. Thus, even if the web host uses DHCP internally, the external request’s IP address remains that of the server’s public interface.

I don’t see why DHCP would have an impact here. Either way, this is a conversation you should be having with your sys admin, not on this forum.

Please avoid using @ unless you have found an explanation or a solution for your specific setup.
I cannot afford to be involved with troubleshooting issues specific to the servers and networks where the plugin is installed.

• This reply was modified 1 month, 2 weeks ago by Alexandre Froger.
• This reply was modified 1 month, 2 weeks ago by Alexandre Froger.

My suggestion would be for you to investigate the code: the plugin only uses the standard $_SERVER['REMOTE_ADDR']. Nothing more. No IP manipulation.

You could use a code snippet plugin and output the $_SERVER variable somewhere in the php logs, on screen, a file, etc. You could test several cases (calling the homepage from a browser, on VPN or not, then calling the homepage with a request in code from the problematic remote server with wp_remote_get function for instance, and compare the content of the variable). There could be many ways to do that. All of them that I can think of involve code. If you are not a programmer, I would invite you to hire the services of one.

I cannot troubleshoot your specific server installation. Feel free to report back if you find an explanation to your issue, and a solution.

• This reply was modified 1 month, 2 weeks ago by Alexandre Froger.

fixed in latests version (although this was unlikely to be the cause: a warning should not affect your products)

The line “To find the IP addresses (of the remote sites), use the “Test” button on remote sites while Logs are enabled and check the local log results.” is here to account for CDNs and proxies that can be hit along the way when the sender’s request reaches destination and give some indication (but nothing guaranteed) to configure the plugin; that’s pretty much it. The plugin does not manipulate anything on the network: it takes what it gets and rolls with it to check what it can.

I guess you could check with another source: if the source IP detected at destination is the same, then you would know that something is happening internally on the destination’s server.

The rest is entirely dependent on the servers’ setup, something that is I am afraid out of scope of this forum.

• This reply was modified 1 month, 3 weeks ago by Alexandre Froger.

Thank you for reporting!
A fix has been deployed (v2.0.7)

Hi,
The plugin does not and cannot assign IPs. This is all dependent on the network between the 2 servers (proxys, CDNs like Cloudflare, etc). As this may be different for each install, and is more of a server & configuration issue, this cannot be addressed here.

• This reply was modified 1 month, 3 weeks ago by Alexandre Froger.

fixed in 2.0.6!