Bug report: M2P in network mode, posts leak into other sites — semi urgent

M2P in network mode is "leaking" pages into other sites on the WPMS network.

In this particular instance, post ID 474 happens to be a Page in one particular site, and once M2P was deployed, that page disappeared. It also happens that post ID 474 in rootsite (where the M2P pages are) is an email template (in this case, the recurring payment failure email).

On the site where the page disappeared, in "All Pages" the entry where the missing page should have been, the type is listed as "Membership2 Email Templates". See the attached screenshot for what I mean. Note that the title has changed as well as the post type.

This is only one example I know of. It seems likely that M2P is interfering with pages on other sites right across the network, so this is a semi-urgent bug to fix.

  • David King

    It can only be an M2P bug because it is an M2P post_type that is showing up in a site where it shouldn't. Here are some other things you can do to demonstrate the problem:

    1. Get a list of post IDs that belong to M2P in rootsite:

    mysql> SELECT id FROM wp_posts WHERE post_type = 'ms_communication-n';
    +-----+
    | id  |
    +-----+
    | 468 |
    | 469 |
    | 470 |
    | 471 |
    | 472 |
    | 473 |
    | 474 |
    +-----+

    2. In a WPMS instance with M2P in network mode, either create a new site or pick a site that has little to nothing on it (or, at least, has some of those post IDs free).

    Execute the following SQL to create four entries, two of which will collide with M2P, the other two of which won't (but will prove the INSERT statements produced sufficiently valid post table entries). You will need to adjust the post table names suitably and post IDs in the first and last INSERTs to be those that belong to ms_communication-n but don't already exist in the target table.

    mysql> INSERT INTO wp_32_posts
        (ID, post_author, post_title, post_name, post_type, post_status, post_date, post_date_gmt)
        VALUES
            (470, 1, 'Unreachable page', 'unreachable-page', 'page', 'publish', '2015-07-06 14:30:42', '2015-07-06 19:30:42'),
            (472, 1, 'Unreachable post', 'unreachable-post', 'post', 'publish', '2015-07-06 14:30:42', '2015-07-06 19:30:42');
    
    mysql> INSERT INTO wp_32_posts
        (post_author, post_title, post_name, post_type, post_status, post_date, post_date_gmt)
        VALUES
            (1, 'Reachable page', 'reachable-page', 'page', 'publish', '2015-07-06 14:30:42', '2015-07-06 19:30:42'),
            (1, 'Reachable post', 'reachable-post', 'post', 'publish', '2015-07-06 14:30:42', '2015-07-06 19:30:42');
    
    mysql> SELECT ID, post_author, post_title, post_name, post_type, post_status
        FROM wp_32_posts ORDER BY ID DESC LIMIT 2;
    +-----+-------------+----------------+----------------+-----------+-------------+
    | ID  | post_author | post_title     | post_name      | post_type | post_status |
    +-----+-------------+----------------+----------------+-----------+-------------+
    | 515 |           1 | Reachable post | reachable-post | post      | publish     |
    | 514 |           1 | Reachable page | reachable-page | page      | publish     |
    +-----+-------------+----------------+----------------+-----------+-------------+
    
    mysql> INSERT INTO wp_32_term_relationships
        (object_id, term_taxonomy_id, term_order)
        VALUES
            (472, 1, 0),
            (515, 1, 0);

    (NB: the difference between the two posts table INSERT queries: one specifies the ID, the other does not.)

    3. Satisfy yourself that the reachable page and post are, indeed, valid and reachable by visiting (in my example):

    http://domain.com/siteslug/?p=514
    http://domain.com/siteslug/?p=515

    4. Now try visiting the unreachable page and post:

    http://domain.com/siteslug/?p=470
    http://domain.com/siteslug/?p=472

    » In my example, 470, the page, will give a 404 not found where, in contrast, the other page we inserted (that does not share a post ID in common with M2P's post IDs on rootsite) works as expected.

    » The same happens with post_type = 'post' case (in my example, ?p=472 vs ?p=515) and, in addition, the unreachable post redirects to http://domain.com/siteslug/ms_communication-n/472/ — something that only M2P would or could do.

    5. Look at 'all posts' and 'all pages' in wp-admin:

    » in both cases, the unreachable post/page shows a post type of 'Membership2 Email Templates' instead of post or page.

    I have not explored whether other M2P post types exhibit the same behaviour, but it is at least clear that M2P is diverting requests (to sites that aren't rootsite) for posts whose IDs match those of rootsite posts where post_type = 'ms_communication-n' , both in wp-admin and on the front-end.

    This evidence persuades me that there is a bug in M2P.