Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scheduled backups are not consitent #144

Open
saranshj4 opened this issue Oct 10, 2024 · 5 comments
Open

Scheduled backups are not consitent #144

saranshj4 opened this issue Oct 10, 2024 · 5 comments

Comments

@saranshj4
Copy link

Before submitting an issue please check that you’ve completed the following steps:

  • Made sure you’re on the latest version
  • Used the search feature to ensure that the bug hasn’t been reported before

Describe the bug
Few of our users reported that backups that are scheduled using WP Cron only runs when they are logged in as admin. Also, in some cases, next backup gets scheduled for year 1970.

To Reproduce
Steps to reproduce the behavior:
Schedule any backup using WP Cron. It should run when you are logged in as per scheduled time. It will not run if you are logged out for few days until the next login.

Expected behavior
Backup job should run consistently as scheduled.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

Acceptance Criteria (for WP Media team use only)
Clear instructions for developers, to be added before the grooming

@MathieuLamiot
Copy link
Collaborator

@Honemo Most cases reported here are not related to the jobs not being triggered at the exact right time (which is due to WP Cron management) but to the next run of BackWPUp jobs being set to Jan. 1970. This is something we should look into after v5.
@saranshj4 To move forward on this, we would need a website to replicate and investigate the issue.
With the current focus on BackWPUp v5, we can not prioritize this investigation (unless you start seeing an important incoming flow of reports). To move forward, I would suggest that we get a website to reproduce the issue on our own test servers so that we don't make the end user wait and maintain the test website. You might be able to achieve this by cloning a website with the error.
Once v5 is released and the team has more bandwidth, we can investigate directly on this test website ; or if we don't have any then, by directly getting accesses from a customer facing the issue.

@saranshj4
Copy link
Author

Noted about the prioritizing UI update. This specific issue has received hate on [org], somehow managed to get credentials of the site that I escalated a week ago.
https://secure.helpscout.net/conversation/2775842595/526718?viewId=7806633
If we can get something meaningful out of this, I suggest checking; otherwise, we can wait. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants