Michael

Perfect, thanks Frank. BTW API-Codes WITH restrictions work, too, now.

+1 to this error without any extra information here…

Alright, thanks. So easiest would be to set return to the dreaded “-1” and activate caching, if I want to make sure that all posts (and pages? and custom post types?) are included. Right? Thank you!

Oh wow, that answer was fast. Thank you!

(BTW: Is the sitemap.xml dynamically generated every time it is called or only if some specific action is triggered? I noticed it takes some time to load and the generation date is up to the second…)

Thanks! (I – the admin – never had this issue. Editors complain all the time…)

Just happened again on a single wp install – again to an editor, not to me (admin). I use ACF and Yoast SEO. Template is Twenty Seventeen… Could not find anything session-related in my configs.

This setting is active: Add all logged in users to the whitelist.

…on a subsite of WP multisite!

Hi,

No error in PHP Session, but yet:

01/Mar/17 15:04:07 #5142228 critical – 123.123.123.123 POST /wp-admin/async-upload.php – Blocked file upload attempt – [filename.png (56,508 bytes)] – domain.com

…several such lines.

Upload has been made not by admin, but by editor.

Best,
Michael

Perhaps related to what is being discussed here – if not, I will post this question somewhere else:

I have set a high value for content_width (2000px).
Tiled gallery is inside a container-div which has a width of 720px.

Through custom JS I resize div.tiled-gallery to the width given in the data-original-width-attribute (as long as this is lower than browser-width). This works fine and imgs are displayed nicely on load.

On resize, however, although div.tiled-gallery still gets the right size, the imgs inside it are calculated to fit the parent div (i.e. 720px).

Where do I need to change what, so that img sizes are calculated from div.tiled-gallery downwards, and not, as it seems to be now, from the outer most div?

Thanks,
Michael

It did not happen in the last week. Once it does, I will update this thread here. (But thanks for the – really appreciated! – follow-up-question!

Hi Christina,

Your question made me curious and I downgraded to PHP 7.0.14 (64bit). Now everything is fine again. I can live with that for now. (Thank you anyway!)

Hallo Christina,

PHP-Version: 7.1.0 (64bit)

Hi, I have the same issue, but my host did not block anything. Instead, Ninja Firewall itself (version 3.2.6) marked this file as malware. The log-entries are practically identical to fraudiebels’ entries.

Need for concern?

Hi, is there a way to limit allowance for system.multicall to JetPack only and not allow it globally as suggested from dm4n?