userwords

looks fixed now after reinstalling thanks.

Here you have:

Modified plugin file: wp-content/plugins/category-posts/cat-posts.php

Filename:
wp-content/plugins/category-posts/cat-posts.php 

File type:
Plugin 

Issue first detected:
11 days 2 hours ago. 

Severity:
Warning 

Status
Ignoring this file until it changes  

This file belongs to plugin "Category Posts Widget" version "4.1.7" and has been modified from the file that is distributed by www.ads-software.com for this version. Please use the link to see how the file has changed. If you have modified this file yourself, you can safely ignore this warning. If you see a lot of changed files in a plugin that have been made by the author, then try uninstalling and reinstalling the plugin to force an upgrade. Doing this is a workaround for plugin authors who don't manage their code correctly. [See our FAQ on www.wordfence.com for more info]

Thank you very much. Im reviewing it, as apparently i had too much css in the inline and defer box. Speed in fact improved upon disabling this option considering how much css i was inlining in the header. At least i discovered there is a lazy point limit for facebook tag. Thank you very much for reaching ill test the filter.

Actually the tag is in the header but at the end after css stylesheet, next to the og: tags and is identically the same in both plugins, no errors, but the add meta tag plugin adds it at the beggining of the header before de css stylesheet and for some reason it works there but not more down in the header where yoast puts it. This is the error:

Bad Request

No admin data found at root webpage ‘https://www.yourdomain.com/’. Insights requires admin data at the root webpage for the domain ‘www.yourdomain.com’. Use https://developers.facebook.com/tools/debug to verify that we are able to extract the admin data from your root webpage.

Css stylesheet is minified and theme is customizr and is indeed a long stylesheet so my guess is facebook has set a limit for how long code will read in the header before stop trying to find the tag, so if there is a lot of code stuffed up there before the tag it wont make all the way down to it even if it is before the closing header tag. This looks like a bug or more appropriately an unexpected behaviour that may affect certain users with minified long css stylesheets as far as i can see.

I also bump and ask the same question.

I bump and ask the same question.

Te puedo decir casi con toda seguridad, que si no puedes acceder por ftp ni cpanel es tu hosting el que esta fallando porque eso no tiene nada que ver con este plugin. Habla con tu hospedaje.

Anyone pls.

Thats what i did as a temporary solution. But as you tell me it is not a missconfig on my part, but it is indeed beyond the scope of both plugins, i consider that solved anyway. Thank you very much for your reply Frank. I tried your plugin after w3c and along with super cache it improved speed a lot. I used almost an entire day to configure w3c total cache, and yours with a few clicks was performing far better. Thanks for keeping it simply. Im sure in certain scenarios w3c total cache can perform better of what i got, as im using a shared hosting. But for my config yours is awesome and simple. Keep it that way Frank, keep it simple and as auto as you can so we can concentrate in writing good content for everyone.