Peter Booker

I was out for the evening so missed the fun. I am glad you got it working, good job troubleshooting and detailing your findings!

No problem, something simplified in a script you can run directly should allow you to troubleshoot further:

<?php
$r = wp_remote_get( admin_url(), compact( 'cookies', 'headers', 'timeout' ) );
var_dump( $r );

• This reply was modified 6 years, 4 months ago by Peter Booker.
• This reply was modified 6 years, 4 months ago by Peter Booker.

Do you have a docker-compose.yml or more details on your Docker setup? I suspect that you do not want to make the domain point to 127.0.0.1 from within the PHP container but to the web server container instead.

That is the main issue with loopback requests in Docker setups, by default the PHP container does not know how to get from the domain to the correct entry point (web server).

The plugin will be attempting to connect to the ‘WordPress Address’ from the admin under Settings -> General.

The way I do it, in a docker-compose setup, is by adding to the PHP container:

extra_hosts:
      - "localhost:172.18.0.1"

iirc, 172.18.0.1 is the default docker gateway and ‘localhost’ is the WordPress Address in my setup (without the http bit at the start).

In case it is helpful here is a link to my docker-compose.yml.

• This reply was modified 6 years, 4 months ago by Peter Booker.
• This reply was modified 6 years, 4 months ago by Peter Booker.
• This reply was modified 6 years, 4 months ago by Peter Booker.
• This reply was modified 6 years, 4 months ago by Peter Booker.

Hi Chris,

The file you mention /wp-content/plugins/kebo-twitter-feed/views/dirs98.php is not part of the Kebo Twitter Feed plugin. You can see the files in the views folder here.

I have no idea how the file has been added to your hosting, there is no mechanism for files to be added through the Kebo Twitter Feed plugin. I had a quick search for dirs98.php and google returns lots of results, some WordPress sites (various plugins and core folders) and some non-WordPress. It looks to me like this is a general spam file which gets added to random folders to hide it.

The easy answer is that you can safely delete it, either just the file dirs98.php or the entire plugin folder /kebo-twitter-feed/ and no harm will be done. If you contact your host they should be able to do this for you and to un-suspend your account. However, without identifying how the file was added it could happen again.

To be confident that the problem is resolved there are many professional services that could help, like Sucuri. Alternatively, your host might be able to help too.

Hi say_hello,

Unfortunately the plugin cannot be used as a general RSS feed. The data source is hardcoded as the Twitter API and it is setup to only handle Tweet data.

Good luck finding a plugin which fits your needs.

Hi Steven,

It was not critical, however it should also not have existed. I just updated the plugin to 1.5.12 which resolves this.

Thank you for letting me know.

Hi guys,

I have just updated the plugin (1.5.11) to resolve this (switched domains). This should have been included in an earlier update to give people plenty of time to update, but was mistakenly not included. I updated my tests to use the new domain and so didn’t pick up on it breaking.

I will try and get the old domain working again to resolve the issue for those who have not noticed yet, or who might take longer to notice.

Sorry for the inconvenience caused.

Hi again,

I have just updated the plugin (1.5.11) to resolve this (switched domains). This should have been included in an earlier update to give people plenty of time to update, but was mistakenly not included. I updated my tests to use the new domain and so didn’t pick up on it breaking.

I will try and get the old domain working again to resolve the issue for those who have not noticed yet, or who might take longer to notice.

Sorry for the inconvenience caused.

Hi guys,

Thanks for letting me know, unfortunately this is my error in letting the domain expire. I am on my way home now and will see if I can get it back up quickly, if not I may need to release a plugin update later tonight with a domain change.

Either way I will try to have it working again later tonight, sorry for the inconvenience to you all.

Hi James,

This is the particularly frustrating problem. When saving on the options page, it calls:

delete_transient( 'kebo_twitter_feed_' . get_current_blog_id() );

Which should wipe out the badly stored data, allowing it to fetch the correct data again and continue working as expected. While this works fine in my tests (and for many people), it does not for everyone and I have no idea how or why.

Transients are stored in the database (options table) by default, but can be stored in an object cache if WordPress is setup for it (APC, Memcache, Redis, etc). Do you know if your site is using one of those?

I could also just be barking up the wrong tree completely. I think my best bet now is to ensure that it is impossible to get into this position in the first place (with bad data stored in the transient).

In general:

I have spent many weeks attempting to identify why this problem exists, I strongly suspected that it could be related to some sites losing the ability to delete the contents of options. Sadly I have been unable to reproduce anything like this.

I have test sites across 11 different webhosts, from cheap to premium, none of which I can make reproduce this issue.

Most recently I have been working with other languages (Golang) to expand my development awareness, especially with a statically typed language to get over bad habits picked up from learning with PHP.

I intend on making another attempt at my WordPress plugins soon, with the hope that my experience now will help me to avoid and/or better deal with issues like this (unexpected errors).

Hi James,

I am sorry you are experiencing this problem and I really do wish that I could resolve it so no-one had to deal with it.

The issue is the tweet data getting stuck with just an expiry, as can be seen from:

{"expiry":1448454018}

The plugin should be able to deal with this, but for reasons I cannot explain it does not for everyone. You should be able to manually delete the tweet data, and force it to be fetched again, by clicking save on the plugins options screen (or more severely by un-installing/re-installing the plugin).

There are a few cases where this process does not work properly and people are still suck with errors, which is the issue behind this thread. This is still something I am struggling to resolve as I cannot find a way to reproduce the problem.

Hi Graham,

It picked up that successful API requests were being made for that username, which leaves me in a world of frustration.

I have absolutely no idea what is going wrong, as there are measures designed to catch errors at each point after that. There is clearly a gap which is letting some errors go unnoticed, however I cannot yet pinpoint where this is.

I will run some more tests over the weekend to see if I can reproduce situations which my current code does not catch. In the mean time I cannot promise to have this fixed quickly, so for your sake you may be better off finding an alternative which works for you right now.

I really appreciate your help with debugging and I will continue work to identify the cause of this problem either way.

Hi DorianeM,

This is a very interesting suggestion. I have plans for making any customisations much easier but this would make adding Tweets into a page much more usable.

I have added this to the development list, and I quite like the idea as currently there is no good way to display Tweets on a wide area (like a page).