lukelol

I’ve been able to confirm the last working version is 4.1.5

After some further digging, I think the issue lies in class-googlesitemapgeneratorstandardbuilder.php

I suspect this line is used for some pagination feature?

$posts = array_slice( $posts, ( $limit - $links_per_page) );

I think the limit or links_per_page may not be properly set and thus the $posts array is empty after the array_slice operation.

Commenting out this line (175) as well as adjusting line 94 (increasing the limit to 50000 in the case it is set to 0) fixed the issue for me, though I suppose this may cause links_per_page or limits to not be properly set.

line 94: $limit = (( (int) $limits ) * $links_per_page)?:50000;

Thanks for following up @saurabhdhariwal01 Hope you can get this resolved in the next release.

• This reply was modified 1 year, 11 months ago by lukelol.

I had the same issue, I believe it is a bug with the javascript reaching the completion of all posts, but not forwarding you to the next step.

I solved it by forcing the next step in the url, but this also required that i bypass the ‘nonce’ check in the php code.

You might be able to append &step=2 to the url to get to the next page.

Adding “orderby” + “order” to the function get_not_auto_linked_posts_ids in ./classes/class-related-post-manager.php appears to reduce the time it takes to execute the 2nd query.

public function get_not_auto_linked_posts_ids( $limit ) {
                return get_posts( array(
                        'fields'         => 'ids',
                        'post_type'      => RP4WP_Related_Post_Manager::get_supported_post_types(),
                        'posts_per_page' => $limit,
                        'post_status'    => 'publish',
                        'meta_query'     => array(
                                array(
                                        'key'     => RP4WP_Constants::PM_POST_AUTO_LINKED,
                                        'compare' => 'NOT EXISTS',
                                        'value'   => ''
                                ),
                        ),
                        'orderby' => 'ID',
                        'order' => 'DESC',
                ) );
        }

In this case, we are now ordering by an indexed column (ID) which has a similar result as ordering by post_date

• This reply was modified 3 years ago by lukelol.

Similarly, these two unoptimized queries delay the “Linking” process:

SELECT COUNT(P.ID) FROM wp_posts P LEFT JOIN wp_postmeta PM ON (P.ID = PM.post_id AND PM.meta_key = 'rp4wp_auto_linked') WHERE 1=1 AND P.post_type IN ('post') AND P.post_status = 'publish' AND PM.post_id IS NULL GROUP BY P.post_status;

SELECT wp_posts.ID FROM wp_posts LEFT JOIN wp_postmeta ON ( wp_posts.ID = wp_postmeta.post_id AND wp_postmeta.meta_key = 'rp4wp_auto_linked' ) WHERE 1=1 AND (wp_postmeta.post_id IS NULL) AND wp_posts.post_type = 'post' AND ((wp_posts.post_status = 'publish')) GROUP BY wp_posts.ID ORDER BY wp_posts.post_date DESC LIMIT 0, 5;

The previously added wp_posts indexes (ID,post_type,post_status) and (post_type,post_status,ID) are being used, but don’t seem to be enough to prevent mysql from creating temporary tables and using filesort (on the wp_posts table) in order to execute these two queries.

I’ve found adjusting the ppr (post per request?) value in ./classes/hooks/class-hook-ajax-install-link-posts.php up to 50 increases the number of posts linked per query execution and thus speeds up the process by reducing the number of times these two queries run. By increasing this value, each request will take a longer time so you need to take care to avoid timeouts on the requests.

I suspect “ORDER BY wp_posts.post_date” could be removed from the 2nd query as it is not necessary to sort the posts when we will be linking them all anyways.
I also don’t think “GROUP BY P.post_status” is required as part of the first query as the count should remain the same with or without group by.

I hope this perspective can contribute to the improved linking speed of the plugin.

I’ve been able to substantially speed up this query and therefore the indexing process by adding a BTREE index on the post_id column of wp_rp4wp_cache. A hash index probably would have worked as well. It seems mysql needs this separate index on the post_id column only to properly use indexes for the previously slow query.

Good to hear! Looking forward to subscribing to the pro version.

Also facing an activation issue.
Unable to interact with the settings for CloudFlare.

requests to:
/wp-admin/admin-ajax.php?action=cloudflare_proxy&proxyURL=zones&proxyURLType=CLIENT
result in this response:
{"result":null,"success":false,"errors":[{"code":"","message":"Forbidden"}],"messages":[]}