Blamedutchie

Unfortunately…

Entering WordPress admin area, immediately results in the “called too early” line in debug.log, as does every subsequent click on menu items.

• This reply was modified 3 weeks ago by Blamedutchie.

@tigroumeow Always the latest version, will check the logs later today.
Thanks for this status update!

Hi @vupdraft

Sorry it took a while, I’ve been busy with other things.

You write: “There are only two reasons why scheduled backups don’t run but manual ones do.”
That, I understand. What I don’t understand, is why setting up the plugin did not create the necessary WP-cron job to perform the back-up in the first place.

Which is why I specifically mentioned the difference in cronjobs between my live site and a test site in a Virtual Machine.

But anyway, using real cron instead of WP-cron is the better option anyway – imho.

Cheers!

@vupdraft

That… Created the cron jobs.
How it makes sense logically and/or technically is a different question, though…

Bump.

@vupdraft

Hi, I beg to differ, for the following reasons:

1.
No matter what I change in the schedule settings, the only cron job that ever gets created on this WordPress install is:

updraftplus_clean_temporary_files

On a Virtual Machine running an exact copy of my WordPress install, after installing and configuring UpdraftPlus there are more cron jobs being created:

updraftplus_clean_temporary_files
updraft_backup
updraft_backup_database

2.
Because I know that WordPress cron is not the most reliable scheduling tool, I have cron jobs running on the server level and those run flawlessly.

…right…

Oh well, here you have it:

screenshot

Done!
Link to file.

@bcrodua

Done, thanks for looking into this.
Link to file.

I see,
Maybe you could reconsider. For me, the list of posts is a great tool to see all possible information about the posts in one screen. The columns are there, so you may as well give them data. Admins can always decide to hide the columns.
Cheers!

Hi @rilwis ,

Re the possibility to edit the meta title and description: great you are working on that.

About the data not being visible in the lists of posts, I’ve added two screenshots to explain the issue.
The data is generated, because it is visible in the editor. However, it is not visible in the post list, unless it is edited by hand.

The way I see it, is that if the plugin is able to pull the title/description out of the post and push them into the appropriate fields in the editor, should it not also be possible to push them into the fields in the post list?

Meta data in editor
Meta data in post-list

Thanks!

Hi,
Decided I actually don’t really need this plugin.
Facebook/Instagram App creation is just too much of a hassle, on the Meta side, not a problem of the plugin. Marked as resolved.

Hi @qtwrk

Thanks for being on top of this.
I’ve added the lines and ran a few tests.
Everything worked well and as intended, meaning that both optimization and pulling went without errors.

I know, theoretically, the CDN has nothing to do with these processes.
However, I was experiencing several issues that all disappeared after disabling the QUIC.cloud CDN, even though all signs were green. For me it is clear that something is not working as it should on that end.

The cURL error 28 still pops up every once in a while, but not necessarily related to this image processing. I know that already for many a year, many people using WordPress have that error and discussions on the topic are ongoing on various levels.

So, for now… Let’s consider this issue resolved.

Thanks!

Hi @jahidcse

Thanks, it took me a while to get back to this issue.
I just re-enabled the plugin and this time without problems.

Retracing my steps, the only reason I can see that your plugin failed, was a conflict with the CDN I was using at the time. I am no longer using that, since it was raising all kinds of issues, so…

For now, I am a happy camper.

Thanks!

The list was too long…
But, I did try to access some if the URL’s directly and that always resulted in a 404.
I’ve had long chats with my provider and there are no issues on that end.
On the QUIC.cloud dashboard, I’ve switched Bypass CDN On, and that appears to help, but I am not sure that anything is being cached right now. To be honest, I am spending way too much time getting all the quic processes to work. (no offense)

I know that cURL is very difficult to troubleshoot, but I am starting to suspect QUIC’s DNS performance. Right now, I lack the time to dive into that deeper though. I may decide to do a roll-back tonight and stop using their CDN, but I first want to be sure what the effect of that will be on the webp process. As I said in another thread, the documentation is rather unclear at times.

Thanks for looking into this!

• This reply was modified 5 months, 2 weeks ago by Blamedutchie. Reason: clarification
• This reply was modified 5 months, 2 weeks ago by Blamedutchie.