Lethalmiko

I am using Google Drive and experienced the same thing. I have set Updraft to make one backup of the entire website and two backups of the database and this is daily for both. But once a backup is done, the old backups are NOT deleted and the Google Drive gets filled up and I have to delete manually.

@bcrodua after some investigation, it seems the problem arose because a caching plugin consumed too much disc space and Updraft backups were failing to complete as you suggested.

However, the plugin in that case should not just keep adding incomplete backups forever when this happens. The space it was consuming from incomplete backups was more than twice the size of the website.

It should be intelligent enough to calculate that the space consumed by the incomplete backups is sufficient for a normal single backup and it should delete them all automatically and then create a single full backup as per settings.

At the very least, it should throw up warnings in the Admin area about low disc space and failed backups.

I figured out what was happening. It was an issue with manually created orders. I have written some code and the problem is resolved.

Another idea I suppose is to put a switch in the settings to enable an admin decide the default setting for access. Perhaps that is a good compromise between the two positions. Thanks for your help.

Thank you @andrewza for your guidance. However, please note that in my testing, the user does NOT have an active subscription initially. All they are doing is registering and then creating an order that goes into a pending state and yet they have access immediately that pending order is created.

I do not believe this should be the case and the $hasaccess parameter should be set to false by default for all users unless they have a successful order, without having to code a custom access function. In fact, for the pay by check addon, this is precisely what happens as orders go into a pending state but no access is granted until the admin marks the order as successful. May I suggest that you consider adding this no-access-by-default setting to the core plugin codebase. Or maybe write a guide on your website since it is a core plugin issue.

And finally, I am not asking for support for any paid addons, so I am not sure why there is a constant reference to it. I reiterate that I only mentioned the addon to give extra information that may be deemed relevant to my problem.

Thanks.

Thanks for the reply.

I only mentioned Approvals Add On in case it is relevant information to my issue, not that I am asking for support on that. My experience is that users have access just by creating a pending order and that is not the expected behaviour. That is a core plugin matter.

My question thus remains unanswered.

• This reply was modified 2 years, 3 months ago by Lethalmiko.

I will revert if I discover anything new about the disappearing cron jobs. So far they are still there.

And I also need to know why

https://mydomain.com/wp-content/plugins/paid-memberships-pro/scheduled/expirememberships.php

throws up a 403 Forbidden error. The error is there even if I run wget from the command line on the same server.

My plan was to create a server cron job to be running that URL so that memberships are expired even if the prmpro cron jobs disappear as they did.

• This reply was modified 2 years, 10 months ago by Lethalmiko.
• This reply was modified 2 years, 10 months ago by Lethalmiko.

Thanks for the reply.

I did manually run the cron job via WP Crontrol before I posted my question and it does work, but my issue is that I want it to run automatically via a server cron job which I have already setup thus:

*/5 * * * * wget https://mydomain.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1

I also have a separate server cron job to visit the homepage every minute thus:

*/1 * * * * wget -q https://mydomain.com/ > /dev/null 2>&1

In wp-config.php, I have put in:

define(‘DISABLE_WP_CRON’, ‘true’);

I have root access to the server and I tested the WordPress cron job and it does create a log file, meaning it works. ie:

*/1 * * * * wget https://mydomain.com/wp-cron.php?doing_wp_cron > /path-to-wordpress/test.log

So my biggest issue is that the pmpro cron jobs listed in WP Crontrol just mysteriously disappeared from the list and had to be added back manually. I found that a hundred subscriber accounts were still active beyond their expiry dates because of this problem.

• This reply was modified 2 years, 10 months ago by Lethalmiko.
• This reply was modified 2 years, 10 months ago by Lethalmiko.

Great. I have tried new version and it is now working as expected.

@wpuserca , on the main plugin page on the right under the version number and tags, click on “Advanced View” and scroll to the bottom of the page. You will see downloads of previous versions.

Also here: https://www.ads-software.com/plugins/co-authors-plus/advanced/

From what I can tell, it appears that the latest WordPress update must be connected to this problem which only arose when I did a manual upgrade on Friday 26th March 2021.

@quasimodo84, I tried your solution and it also worked for me immediately. I did not have to disable any other plugin. I have 70 plugins installed and the process of enabling one by one is rather tedious. When I tried it today, I could not find the offending plugin. I shall try again more slowly this time.

Thanks a lot mate. You have saved my life today!! ??

SNAP calls Facebook and says “Hi Facebook. Here the URL of the link I want to publish on my Facebook page”. Facebook visits the provided URL, collects title, description and image from OG metatags and than publishes the link with collected from OG tags title, description and image.

@nextscripts, you are basically claiming that the mechanism Facebook uses to automatically pick data from the OG tags doesn’t work correctly after receiving the URL from your plugin, yet the mechanism works when someone posts the exact same URL manually on a facebook page. If this is true, then you should get in touch with Facebook to alert them about this and ask them to fix it.

It is simply NOT TRUE that the OG tags are not set correctly or that they are missing at time of publication. Insisting on believing in something that is demonstrably false makes it impossible for you to get to the bottom of this problem and solve it.

By the way, whenever I post an article manually on Facebook, it picks the correct featured image every single time but the autoposting doesn’t work. So if it is true that this plugin merely sends the URL to Facebook which then picks the details from the OG tags on the story, then logic dictates that the result should be exactly the same in both cases. If autoposting fails to make Facebook get the data from OG tags, then even posting manually should also fail since the OG tags are incorrect or not there.

• This reply was modified 7 years, 3 months ago by Lethalmiko.