Sorry, no Tweets were found.

Hi willc0de4food,

Sorry the plugin is not working as intended for you.

The debug tweet data shows why you see the error message, there is no Tweet data stored only the expiry time. This can happen when there is a problem and no tweets can be fetched from the API. Once the expiry time is stuck there alone, it prevents the cache refreshing.

Usually clicking ‘Save Changes’ on the plugins settings page would delete the cache and refresh the data. However, the steps you have taken (especially deleting the plugin and reinstalling) should have done this too.

It is very interesting that it worked on the old host but not the new, can I ask what the new host is please?

The new host is linode. Interestingly, it works in my Fedora virtual machine. /baffled
Forgot to mention I did try to save and refresh since I saw you mention that to others.

Hi willc0de4food,

This is baffling indeed, I have many sites running on Linode that work fine, however due to Linode being open to any setup/config it could be anything.

The API Status box on the plugin settings page is designed to check for compatibility, so that showing Success should mean everything is okay.

Are you running an Object Cache with WordPress (APC or Memcached)? Is there anything unusual about your Linode setup/config?

Nothing unusual about the setup, and no caching.. It’s a pretty basic setup. :/

Hi willc0de4food,

This is strange indeed, everything suggests it should be working.

I will have a think about how I can debug this further this afternoon and, if you are willing, make a debug version of the plugin which will email me the responses it gets from my API so that I can check the data is being received correctly (and if not, see what the response is). This would then be overwritten by the next update as normal.

Sounds good. Thanks for the help!

Hi willc0de4food,

Sorry for the slow response, I had to make a quick bug fix today for something I had caused in the latest update. I have just made a debug version of this latest version (1.5.7) which you can download here.

This will function exactly like the current version on wp.org but will email me the responses received from my API. You will be able to update to the latest version once I make another update on wp.org and be back to normal.

Do use this debug version you will need to download it, delete the current version of the plugin and then add a new plugin by zip file. You won’t see any difference, but if you request the relevant pages with the Twitter Feed on a few times, I will get sent emails with the response from my API.

This will allow me to check what format the responses are and that they are being received correctly.

If any of that doesn’t make sense or you have problems let me know. Thank you for your patience and helping me to debug the problem.

Sounds, good & no problem :] I appreciate the help.
I have uploaded your debug version to the server, so you should be receiving info from it.

Hi willc0de4food,

That is fantastic, I just got an email with the response from my API and it shows a problem. The returned data is…gobbledygook (not in the format it should be). I think the most likely culprit is GZIP, there might be a situation where the API is still sending data GZIPd even if the client server is not showing support.

I will have a look into it and see what I can find.

Huh.. Interesting. Is it possible there’s some software we’re missing?

Hi willc0de4food,

I think I may have found the problem. While my API checks for compatibility before using GZIP compression, it was actually checking for ‘deflate’ instead of ‘gzip’. Although both endup using the same compression technique the implementations are not identical.

It looks like this could well have been the problem, as it did look like the response from the API received by your server was not properly decoded.

I need to spend some time updating the API now, to improve the compression compatibility checking. It is quite easy to begin sending more people corrupted responses (as I just found out).

I will let you know once I believe the API should be sending the correct format back to you. I will also be adding an option to force no encoding from the API as a debug tool in the future.

Awesome. Thanks so much for your help, and all the work you do with this plugin.

Hi willc0de4food,

I wanted to update you here instead of Twitter as 140 characters really isn’t enough.

I had assumed that my script was incorrectly sending the wrong compression type in some rare cases. What I found was that it was actually always sending the appropriate format of compression, but only when the client server supported ‘deflate’, instead of checking for deflate and gzip.

My assumption at the moment is that there is either an intermittent bug in the compression support or that it is possible for some servers to display compatibility through the Accept-Encoding headers, but not actually be capable of decompressing the data.

I have tried switching to PHP (instead of the Web Server) to handle the compression, however this resulted in more problems than before.

At the moment I am left needing to do a lot more research until I can pin point whether this problem is caused by the compression on my servers or the ability to decompress on client servers.

I don’t think this is something I will be likely to resolve in the short term, so it is probably better for you to find another solution which works on your current server for now.

Sorry you have had problems using the plugin, but I will continue to debug this issue until I can resolve it permanently. It will help me to improve this service and others in the future.