TimThemann

From what I can see, esc_html() has been added to $label in Templates/Front/Comment/checkbox.php. The backend says that HTML code is allowed at this point. The release notes mention “Improved code quality” so I suspect this is just a little bit over the top.

Hi Bryle,

it pretty much looks like as if the problem disappeared for no reason (no relevant change on my side). One scheduled and one manual backup completed successfully and very fast. I guess the problem has been caused by some sort of (networking?) issue at the host which has been resolved in between.

Thanks a lot for your support!

Tim

Hi Bryle,

sure – https://pastebin.com/RBKbJdFs

Thanks,

Tim

One additional remark: If it does not complete, but stops after a few hours, it seems to be caused by an overlapping resumption (see log below). Anyway, the root cause seems to be that the actual upload to Dropbox is remarkably slow and somehow broken.

23623.971 (57) Requesting backup semaphore lock (86cf888d6364)
23623.972 (57) [Lock option (updraft_lock_86cf888d6364, wp_options) already existed in the database] debug
23623.973 (57) [Lock (updraft_lock_86cf888d6364, wp_options) could not be acquired (it is locked)] info
23623.973 (57) Failed to gain semaphore lock (86cf888d6364) - another resumption for this job is apparently already active
23623.974 (57) Failed to get backup job lock; possible overlapping resumptions - will abort this instance

Hi Bryle,

since I use UpTimeRobot to generate some traffic during nighttime, the backup sometimes completes successfully after > 10 hours (time needed before the problems started: a couple of minutes). From what I can see from the logs, most of the time the process waits to be rescheduled. Looks like the actual problem is the upload itself which needs to be rescheduled multiple times per file.

Thanks,

Tim

Bryle,

the only thing I can customize is the memory limit. Unfortunately, increasing the memory limit did not help. I’m currently talking to the hoster’s support about things they might have changed which could cause the issue etc.

Thanks,

Tim

Hi Bryle,

unfortunately, that didn’t cure the problem. As far as I can see, the logs pretty much look like before (the log simply ends during upload).

Thanks,

Tim

Hi Bryle,

perfect – you′ll find the log at https://pastebin.com/7PPQKWBY .

Thanks,

Tim

Hi,

is there a way to provide the log w/o publicly posting a Dropbox or Pastebin URL?

Regards & thanks,

Tim

Perfect! ?? Thanks a lot!

At least for 1.5.3, the AMP validator says “The attribute ‘href’ in tag ‘link rel=stylesheet for fonts’ is set to the invalid value ‘//fonts.googleapis.com/css?family=Merriweather:400,400italic,700,700italic’. (see https://www.ampproject.org/docs/reference/spec#custom-fonts)”?

Perfekt – danke!

Toll! Danke! ??

Sure ??

By the way: You might want to get rid of that if-statement referring to the exclusion of <h1> and <h2> at the very beginning of PHP_Typography::process(). After today′s fixes, these lines of code seem to be some sort of a “leftover” from an (outdated) workaround, aren′t they?

Thanks again for your help :-).