Chris Jean

I’m terribly sorry for not replying earlier wpcharged.

While I don’t recommend the code that you posted above (the jetpack_sync_listener_should_load filter), looking at the data on our end, I do see that it succeeded in significantly reducing the requests. I don’t recommend it for two reasons:

1. It’s likely only a temporary solution for your specific needs as the data that Stats uses may look accurate now since it has relatively-fresh synced data, but as time goes on, it may try to request data that either has gotten stale or does not exist as it was created after you disabled that filter. You’re correct that the actual stats are tracked using the external request, but Stats also pulls in other data, such as content titles, using synced data.
2. I can’t offer any guarantees that this filter will continue to function or exist in the same manner in the future.

In short, it’s quite possible that this solution will work for you for now, I just can’t offer any assurances that it won’t cause problems for you in the months and years ahead.

My team found other sites that exhibit the same bug, and we’re narrowing in on the root cause of the issue.

For the time being, perhaps the most pragmatic solution is the following:

1. You add that filter to the affected sites.
2. I post an update here once my team has a solution.
3. You remove the filter on the sites.
4. I confirm with you that the solution resolved the issue.

Does this plan work for you?

Hello wpcharged.

Getting back to your initial question about a filter to disable Jetpack Sync requests as you’re only using the Stats feature, the Stats feature does make use of data synced by Sync. So, if Sync is disabled on the site, Stats would not function as expected.

As for the frequency of requests, I worked with my team to look over the data, and there seems to be a bug causing the relatively-high number of requests. Some data on the site is switching back and forth between two values. Each time the value switches, additional Sync requests are triggered. Since this value switch happens frequently, so do the requests.

We’re unsure of the cause just yet, but we suspect that it some kind of compatibility issue. We’ve been trying to recreate the specific situation happening on your site. Unfortunately, we have yet to determine exactly which combination of factors is creating the situation.

Would be possible for us to gain access to the site? That access would help us identify the cause much more quickly. If so, please contact our support privately here and include a link back to this support thread.

If sharing access is not possible, would you be able to tell us which plugins are active on the site? If so, you can either share that information here or share it privately in a support thread.

That’s exactly what I needed. Thanks wpcharged.

I may not have any answers for you tonight (it’s getting late for me where I’m at). I’m going to share these details with my team, and we’ll make sure to get a response with more information for you within the next 24 hours.

Hello again wpcharged.

Sorry for the followup before I hear back from you. I was thinking more about the endpoints that are being hit on your site. Do you see any patterns in the requests that the site receives? If so, what are the patterns?

For example, you shared that the /wp-json/jetpack/v4/sync/spawn-sync endpoint is requested. Is that the endpoint that receives the most requests or is there a mix of different /wp-json/jetpack/v4/sync/* endpoints and rest_route values that are hit? If it is a mix, can you give me examples of the endpoints that have the most requests?

Thanks in advance for both the URL and endpoint details.

Edit: Looks like you just beat me on the response. Thanks for the URL information. I’ll start looking using that information while waiting for the endpoint details.

• This reply was modified 8 months, 2 weeks ago by Chris Jean.

Hello wpcharged.

I’m looking into this issue. Depending on the site’s content and frequency of data changes, the number of requests could be as expected. Sync is part of Jetpack that syncs data so that specific features can operate. Thus, disabling it might result in features no longer functioning as expected. You can find more details about the synced data here.

Would it be possible for you to share the URL of the site in question? With this information, I can better determine if this is expected behavior or if there is some other issue and can work with you to resolve it.

If you do not wish to post it publicly here, you can contact our support privately here. If you submit a support request on our site, please include a link back to this support thread and the URL of the site receiving these requests.

It has not been abandoned. The functionality is very simple, so it doesn’t require changes to maintain compatibility. To bump it for a while, I released a new version just to indicate that it’s still maintained. There are no code changes in this release.

Unfortunately, I don’t have enough information to give a confident answer. If you made modifications to the theme files (which I assume to be the case), this plugin does nothing to preserve those changes.

Upgrading a theme with a zip file with this plugin active is no different than deleting the theme’s directory and replacing it with the contents of the zip file. If you are unsure what this means for your site, I recommend using a backup of the site to create a duplicate site somewhere else and testing the upgrade in that test site to know exactly what will happen without breaking the live site.

If you made modifications to the theme files, there isn’t any tool that will automatically apply your modifications to the new theme. You will likely need to take the new version and manually apply your changes.

It looks like your site runs Genesis as a parent theme and Derby as a child theme. I assume that the Derby child theme has modifications. The best solution going forward is for there to be a Derby parent theme. That way you can create a child theme of Derby that holds just your modifications. This will allow you to upgrade Derby without losing your changes. The details of how to merge Genesis and Derby to make a Derby parent is technical and beyond the scope of what I’m wanting to provide answers for here.

This plugin doesn’t modify any directory names. The only thing it does is remove the existing directory if a directory matching the one in the zip file already exists. It does this just before WordPress installs the new plugin.

I don’t know which directory is the one with the old version plugin. You can figure this out by hovering over the activate and deactivate links on the plugins page and looking at the URL for those links. You’ll see the plugin directory as part of each link.

• This reply was modified 4 years, 3 months ago by Chris Jean.

I’m going to give the answer that no one likes to hear: It depends.

In general, a plugin’s settings have nothing to do with the directory name of the plugin. Also, most plugins won’t clear their settings unless you delete the plugin from the WordPress dashboard.

So, assuming that this plugin functions like most plugins do and that your site is still running the old version of the plugin with the new version ready but not activated yet, this would be the safest way to upgrade without losing any settings:

1. Deactivate the old version plugin.
2. Activate the new version plugin.
3. Use FTP or some other file management tool to manually delete the old version plugin’s directory (such as public_html/wp-content/plugins/learndash-lms-3.1.7). This is because deleting the plugin from the WordPress dashboard may result in the settings being cleared.

If you are in doubt on how to do any of this, I recommend contacting the plugin author to see how they recommend upgrading.

The issue is separate from this plugin.

WordPress sees plugins by their directory name. The zip file with the plugin has the directory name inside of it. Installing a plugin simply unzips the contents of the zip file and puts the contained directory in the plugins directory.

I’ve seen plugin developers that include the version number in that directory name, which will cause this problem. For example, if the old version is in a directory named learndash-lms-3.1.7 and the new version is in a directory named learndash-lms-3.2.2, then both versions will be present after you install the new version.

Assuming that something like this is happening with this plugin, from WordPress’s perspective, you aren’t installing a plugin upgrade; rather, you are simply installing another plugin. The real solution for this is for the plugin developer to always use the same directory name inside their zip files, such as learndash-lms.

For your situation, you’ll need to manually deactivate the old version, activate the new version, and delete the old version.

Yes, it is fully compatible with PHP 7.4.

The blank screen likely means that there is a fatal error, which is when code fails to run for a variety of reasons. Since you updated the theme, I can think of three primary reasons that this might have happened:

1. The theme you installed has a bug in the code. Sometimes a bad version is released.
2. The theme update you installed requires a version of WordPress greater than 5.0.
3. The updated theme code created a conflict with one or more plugins running on the site.

The specific error that is happening can be found in your server’s error log. I recommend that you contact your hosting company to find out what the error is which can point you in the right direction for getting the site fixed.

I would think that the proper solution for your situation is to:

1. Get the site running with a default theme, such as Twenty Nineteen. Your host should be able to help you with this.
2. Update WordPress and all plugins.
3. Try to switch back to your desired theme. Hopefully the updates will allow it to run properly now.

For the future, if the choice is between using a specific theme/plugin or updating WordPress, update WordPress every time. Not updating WordPress can create situations like you are experiencing now, or worse, can make your site vulnerable to hackers. Always keep WordPress, plugins, and themes up-to-date.

Glad to help. Sorry to hear that your host disables so much functionality. I find that a bad sign when looking at a host, but that’s just me editorializing.

All the unzipping logic is from WordPress and not the plugin, so there isn’t anything that I can control from the plugin. The logic in WP is fairly simple:

/**
 * Filters whether to use ZipArchive to unzip archives.
 *
 * @since 3.0.0
 *
 * @param bool $ziparchive Whether to use ZipArchive. Default true.
 */
if ( class_exists( 'ZipArchive', false ) && apply_filters( 'unzip_file_use_ziparchive', true ) ) {
    $result = _unzip_file_ziparchive( $file, $to, $needed_dirs );
    if ( true === $result ) {
        return $result;
    } elseif ( is_wp_error( $result ) ) {
        if ( 'incompatible_archive' != $result->get_error_code() ) {
            return $result;
        }
    }
}
// Fall through to PclZip if ZipArchive is not available, or encountered an error opening the file.
return _unzip_file_pclzip( $file, $to, $needed_dirs );

Given the logic and how PclZip is being used, the possible explanations are:

1. The ZipArchive class is not present which would indicate that the php-zip library is not installed or properly configured.
2. Something is disabling ZipArchive using the unzip_file_use_ziparchive filter. This plugin does not touch that filter. If this filter is the cause, it would be from a different plugin, the theme, or some other config such as an mu-plugin.
3. The ZipArchive class is having problems unzipping archives. In the event that ZipArchive is available and not disabled by the filter, PclZip will be tried if unzipping using ZipArchive failed with an error code other than incompatible_archive. The code doesn’t log or display the specific error, so if this is happening, someone with access to the system would have to debug the code to find out what the error is. Perhaps with those specific error details, the problem with ZipArchive could be found and corrected.

• This reply was modified 5 years, 1 month ago by Chris Jean.

The warning occurs because the site’s hosting config disabled the php_uname function. Some hosting companies do this for various reasons. (Typically because it’s thought to improve security. I disagree that disabling the function does anything to improve security, but I digress.)

Unfortunately, there isn’t anything I can change in the plugin to fix the problem. You would get the same warnings if this plugin was deactivated and you installed a new plugin on the site. The problem would remain because all the unzipping is done using code in WordPress and not from this plugin.

You have the following options:

1. Disable WP_DEBUG mode on the site so that warnings do not render in the page output.
2. Have your host install the PHP ZipArchive library. This is typically listed as the php-zip library in operating system package managers. WordPress only uses the PclZip library if ZipArchive isn’t present. So, having ZipArchive present would bypass the issue. I wouldn’t expect the host to do this, but it is an option. I should note that most quality hosts provide this library.
3. Have your host enable use of the php_uname function. As with #2, I wouldn’t expect the host to do this and most quality hosts do not disable this function.
4. Change hosts.

• This reply was modified 5 years, 1 month ago by Chris Jean.
• This reply was modified 5 years, 1 month ago by Chris Jean.