Incorrect post numbers in Jetpack dashboard

Hi @saowp

While your site is publicly accessible, we cannot access your site’s XML-RPC file:

https://vikalpsangam.org/xmlrpc.php

This file is used by Jetpack and other plugins and apps to connect to your site. It must return the following message:

XML-RPC?server accepts POST requests only.

You can see a working example here:

https://jetpack.com/xmlrpc.php

Since your site returns a 503?error?for this page, I would recommend that you check the following:

1) Can you see the /xmlrpc.php file at the root of your WordPress installation when accessing your site via FTP? If you don’t, then please try re-installing WordPress. You can do this by going to the Dashboard -> Upgrades page, then click the “Reinstall WordPress” button.

2) Do you use any security plugins that may block access to this file? If so, could you try to disable them? You might also want to check your site’s .htaccess file for any rules that might be blocking access to the?xmlrpc.php file.

3) Does your hosting provider block access to this file? If you don’t find any plugin that may block access to the file on your site, I would recommend that you get in touch with your host.

Once we are able to access your site’s?xmlrpc.php file, you should be able to connect Jetpack to?https://wordpress.com.

We need to have a good working connection for Jetpack in order to be able to troubleshoot the issue you’re reporting.

Let me know how it goes!

Thanks @bruceallen for looking into it. It indeed was a security plugin. I disabled it, and now get the message

XML-RPC server accepts POST requests only.

Can you please retry?

Hello,

I am also a maintainer for the site

Just to add some additional context:

This endpoint:
https://public-api.wordpress.com/rest/v1/sites/vikalpsangam.org/posts/66754/related/

(corresponding to this https://vikalpsangam.org/?p=66574)

returns the following

{
    "total": 3122,
    "max_score": 1224.21,
    "hits": [
        {
            "_score": 1224.21,
            "fields": {
                "post_id": 16273,
                "blog_id": 185206640
            }
        },
        {
            "_score": 389.5459,
            "fields": {
                "post_id": 65491,
                "blog_id": 185206640
            }
        },
        {
            "_score": 389.5459,
            "fields": {
                "post_id": 15298,
                "blog_id": 185206640
            }
        },
        {
            "_score": 304.49744,
            "fields": {
                "post_id": 16067,
                "blog_id": 185206640
            }
        },
        {
            "_score": 304.49744,
            "fields": {
                "post_id": 66699,
                "blog_id": 185206640
            }
        },
        {
            "_score": 223.99667,
            "fields": {
                "post_id": 14909,
                "blog_id": 185206640
            }
        },
        {
            "_score": 223.99667,
            "fields": {
                "post_id": 65502,
                "blog_id": 185206640
            }
        },
        {
            "_score": 218.80615,
            "fields": {
                "post_id": 15542,
                "blog_id": 185206640
            }
        },
        {
            "_score": 218.80615,
            "fields": {
                "post_id": 66180,
                "blog_id": 185206640
            }
        },
        {
            "_score": 159.543,
            "fields": {
                "post_id": 66850,
                "blog_id": 185206640
            }
        }
    ]
}

However, some of these post ids [ 16273, 15298, 16067, 14909, 15542 ] do not exist.

It’s possible that these invalid ids are a residual from when our staging environment was migrated to a live site and that these invalid ids may refer to posts on a now non-existent site.

After scanning a dump of the live site database I verified that these page ids are not present in any form anywhere in the live database at all, so it appears that these invalid ids are perhaps being stored on the wordpress servers (?) and not being deleted. These seem to persist even after manually initiating a full sync (both through the web UI and via the wp cli).

Is my understanding of the data being stored on wordpress servers correct?

And if so, is there some way to remove this invalid data from the site and start from scratch?

As an additional (possibly relevant) note, the jetpack connection does seem to be at least partly functional – new changes made on the live site are reflected in the wordpress.com interface, such as modifying or deleting posts. Also, the wordpress.com interface does list the correct posts in the list itself but the count is wrong – for example see this screenshot:

https://i.imgur.com/pML0ZOG.png

Thanks again

Hello @saowp and @moxon6,

Thanks for the further details. It looks like it is indeed a sync-related issue.

The latest full sync got completed about 21 hours ago, after your latest reply in this thread. Could you please double-check your site again and let us know if the problem persists?

We’re ready to escalate this to our developers in case it does. Let us know what you find out!

Hi @erania-pinnera and @bruceallen ,

This is the present situation:
On WordPress.com

Published 3,517 Drafts 65 Scheduled 0 Trashed 4

On the site admin:

All (1,818) | Published (1,787) | Drafts (30) | Pending (1) | Trash (3)

• This reply was modified 4 years, 2 months ago by Shrik.

@saowp Yeah, I show the same on our end even after we performed that sync, so there’s something else going on here.

At this point, we’d like to run some more tests with you on your site to try to figure out what’s happening.

Could you contact us via this contact form and mention this thread?

Thanks @csonnek I have submitted the form on your link with a link back to this thread.

Thanks, we’ll get back to you by email, so I’ll mark this thread as resolved.

Hi @drawmyface , I got an automatic email from [email protected] when I filled the form. It has been more than 24 hours since then, but I have not received any message subsequently and the post numbers are still incorrect.

Is there a support site similar to this one on Jetpack.com where I can track the request history and status?

Hey @saowp,

We’ve received your message – sorry for the delay in getting back at you. We’re working on a backlog of support requests at this time, and we generally answer in the order received.

Thanks for the patience!