briandd

Edit: i see you updated the plugin and put a performance fix, thanks!

I will try it

• This reply was modified 5 months, 3 weeks ago by briandd.

Removing all dashboard widgets solved my problem, for anyone:

add_filter( ‘aioseo_show_seo_setup’, ‘aio_remove_dashboard_widgets’, 10);
add_filter( ‘aioseo_show_seo_overview’, ‘aio_remove_dashboard_widgets’, 10);
add_filter( ‘aioseo_show_seo_news’, ‘aio_remove_dashboard_widgets’, 10);
function aio_remove_dashboard_widgets() {
return false;
}

help further but disabled the feature

• This reply was modified 5 months, 3 weeks ago by briandd.
• This reply was modified 5 months, 3 weeks ago by briandd.
• This reply was modified 5 months, 3 weeks ago by briandd.
• This reply was modified 5 months, 3 weeks ago by briandd.

I’m not mainly talking about assets but that the whole givewp code is loaded as well, maybe there’s some logic to implement to avoid loading all the code on all pages, it takes disk and cpu time to process all the php code, this can significantly increase the ttfb of the WP pages.

Looking forward for your proposed changes! ??

(rewrite_rules gets recreated on the next page load on subsites with the correct data)

The code is incorrect and was probably taken online, it should be $this->validate_ip when calling it.
The plugin author probably had copied this function also in his theme, outside of a class, and didn’t realize it is calling that one. You should try the plugin on a fresh WP.

The function get_ip_address is unsafe though, the plugin author shouldn’t try to implement his own way to get the IP, if every plugin does this, this can only go bad.

In fact this function is vulnerable, it gets the CLIENT_IP header if it’s set, in most cases it can be spoofed (if it’s not set by the webservers).

The second check, it gets the first IP in X_FORWARDED_FOR = spoofed.

I understand you don’t want people abusing and refreshing an article to increase the counter, but you shouldn’t attempt to reinvent the wheel when trying to fetch the IP.

$_SERVER[‘REMOTE_ADDR’] should be used, it’s for the hosting of the websites to make sure it is populated with the correct IP.

• This reply was modified 3 years, 2 months ago by briandd.
• This reply was modified 3 years, 2 months ago by briandd.
• This reply was modified 3 years, 2 months ago by briandd.

Hi

Any specific reason why it is requiring ajax? It is multiplicating the number of requests that the clients do, on every page load, the client does an additional request to admin-ajax.php , even if you accept the banner

I think other plugins use mostly javascript (including to handle cookies), to avoid showing the banner again, and all the banner settings are directly in the page content, then it avoids doing more requests

I realize that might be why we had huge issues when the plugin was enabled – even if not in use

Thanks ! Looks great!

I think there’s another issue: it seems the elb_update_liveblog requests run on all articles, whether the liveblog is enabled or disabled on the article, do you think it could be possible to enable those requests only on articles with liveblog enabled?

Edit: I see there’s a check “elb.status !== ‘closed'”

However i noticed many of the articles have status: “” (empty):

“interval”:”30″,”status”:””,”liveblog”:XXX”

i didn’t have the plugin enabled all the time so i don’t know if it’s the reason

• This reply was modified 3 years, 6 months ago by briandd.
• This reply was modified 3 years, 6 months ago by briandd.
• This reply was modified 3 years, 6 months ago by briandd.

edit: i see you fixed it in v4.7.1, nevermind, thanks!

Your plugin is creating 1 transient per page or something, this is filling dbs with thousands of transients.
Yes it’s possible to clear but it’s not the solution, as it won’t solve the problem and it repopulates quickly.
The solution is not to use transient if not necessary or re-work that part in your code.

On a site with a lot of pages there are 200k transients.
This plugin is currently broken.

• This reply was modified 4 years, 2 months ago by briandd.

Any hope to have this fixed? For security reasons

Note: if you’re doing it for cache busting, then you should use another method, as it’s not recommended to do that (admin-post is meant for writers)

• This reply was modified 4 years, 3 months ago by briandd.

And the same with the mod_* and timeout_* transients, well generally using the options table isn’t a good idea for this i think

In fact my issue is with these transients:

set_transient( ‘instantarticles_content_’ . $this->_post->ID, $content, WEEK_IN_SECONDS );

if you have thousands of articles that are a few kb, you end up with a HUGE option table that eats up MBs of memory on every request and makes everything slower.

I think there should have another solution to this..