Igor Yavych

Hello, Chuck. Thank you for your interest in 2.0 version.
Since I started working on the new version, time I can dedicate to this plugin got more limited due to job and family commitments.
I would like to think I’ll be able to finish this some day, but honestly, don’t hold your breath for that.

No split doesn’t have issues to begin with. Issues happen with year <=2018.
Also, it’s not the packet size that is being limited, but char length of the query.

I’m not sure about what kind of limiting is being used as we have no control over this server.

Another question is, why is there even a query for taxonomies, if the option to include them is unchecked?

This for some reason only happens with posts from year < 2019. 2019 and 2020 sitemaps both have adequate usage of memory.

You never know. They’re news articles so at some point it might reach that amount of posts per month.
Glad to her about that, though do you have any idea as to what is the cause of high memory usage when generating sitemap from the past years?

That one was for non split.
I did switch to monthly split, but like I said that’s just a temporary solution. Something should be done about these uber long conditions. For one, you could process them in chunks of 100, 200 or whatever else works. Current way causes problems, as you can see, for basically any installation with a lot of posts.
And then, there is still that problem of previous years and memory usage for generating those sitemaps. No matter how you look at it, that kind of behavior is not normal.

Sent you these queries via your contact form. As you can see, problem with long queries arises due an in condition in them.

Hello. Happy New Year, Ravan.
Amount of queries does not get lower during subsequent requests.
Unfortunately, I can’t keep it at no split option as this is production environment and it still causes very long queries that get killed, ~49k to 57k characters long

<!-- Queries executed: 36 | Peak memory usage: 154.18M | Memory limit: 512M -->
For a year of 2016, 832 posts.
<!-- Queries executed: 58 | Peak memory usage: 412.63M | Memory limit: 512M -->
For a year of 2017, 1828 posts.
<!-- Queries executed: 56 | Peak memory usage: 512.05M | Memory limit: 512M -->
For a year of 2018, 2096 posts.
<!-- Queries executed: 2549 | Peak memory usage: 25.5M | Memory limit: 512M -->
For a year of 2019, 2495 posts.
And now,
<!-- Queries executed: 7395 | Peak memory usage: 59.54M | Memory limit: 512M -->
for no split, 7317 posts.

No idea why there is such a difference in queries and mem usage for current year and previous ones. But this seems to be a direction to dig in.

• This reply was modified 4 years, 11 months ago by Igor Yavych.

Because the amount of posts keeps growing fast in our case. Even monthly sitemap will use a lot of resources. And if someone has weaker environment, they could encounter such a problem with a smaller amount of posts, don’t you think?

Hello, Ravan. That’s why I suggested updating it when a new object is added or existing one is updated. If it’s configured to count comment as a modification (not in our case, we don’t even have comments), then update it when a new comment is added. In all other cases, to me personally, it makes no sense to have it dynamic. As I see it, if you made it the way I suggest it’d be a huge performance boost. As for multi site compatibility, I do not see what prevents you from having slightly different logic for single and multi site installation.

Regarding you suggestion to use monthly sitemaps, that’s just a temporary solution.

Thank you. I hope you’ll help with Turkish translation of version 2.0 whenever I get around finishing it.

Hello.
I’m glad you like the plugin. It’s definitely an issue with cache (object cache probably) not being invalidated when it should be.
Do you have a setting to enable object cache in that plugin? Can you, for the sake of experiment, disable object cache, clear cache and see if rating will display properly? If it does, I’ll try to figure out how to help you with this problem.

Hello. Yes, that’s possible with a query like this for example (very basic):

SELECT wp_posts.*, COALESCE(wp_spr_rating.points/wp_spr_rating.votes,0) as rating  FROM wp_posts 
LEFT/INNER JOIN wp_spr_rating on wp_spr_rating.post_id = wp_posts.ID
ORDER BY wp_spr_rating.points/wp_spr_rating.votes ASC/DESC

• This reply was modified 6 years, 6 months ago by Igor Yavych.
• This reply was modified 6 years, 6 months ago by Igor Yavych.

Most likely in 2.0, whenever I get time to release that.

Hello, Jan.
How exactly is this not a development question if it’s about developing a plugin that’s already in the plugin directory and testing it?
And thanks, I will be sure to send an email there.