added the link to your repo to Plugins wiki page
Thanks @Grant_Pannell we had sent various pull requests to your original repo ages ago which all went unanswered so we came to the conclusion that it had been abandoned. Good to see you’ve given it an update! There’s still many users of it. Though I am wondering about its future now that Fever itself has been discontinued. We may find fever support being removed from various apps now.
EDIT: Although saying this, I get a 500 server error from your new version so I’ve reverted to the one from @wodev again which works a treat. Strangely there’s no logs showing why I’m getting 500 from php-fpm. I’ll have to do some investigation another day.
@xtaz There was no original Github repo, so I’m not sure what repository you’re referring to. I originally posted this as a zip file several years ago on the tt-rss forums, and there have been various forks since. The original forums stopped emailing me after a couple of replies, so I never saw the thread reach several pages of replies.
Currently using what ever I have commited into Git with Reeder for iOS. So if you can narrow down and report which client is working, I’m sure there’s a simple fix. Seems to work OK with php 7.1.
OK. This is odd. There is a setting in php.ini called display_errors. If it’s set to Off then I get a 500 server error from php-fpm with no log entries at all to say that something has gone wrong. Usually errors still log to the error log with this set to Off. If I change that to On then the fever plugin works fine and returns 200 OK. What’s going on there then? If I use the version from @wodev it works with display_errors set to Off.
As for the “original repo”. Sorry I now realise you’re not the original repo. I was referring to GitHub - dasmurphy/tinytinyrss-fever-plugin: TinyTiny RSS Fever API Plugin
EDIT OK. Noticed that actually even though it’s returning 200 OK now it’s still not syncing. Thought I would try and delete the account and create it again (in the Reeder app). It now refuses to login saying login failed, check password etc. Again if I put the other version back then it logs in straight away. Something really screwed up going on with this version.
EDIT2 Have tried to do some more debugging. Have tcpdump’d the traffic between nginx and php-fpm. Can see Reeder posting to the API, it has the correct password hash in it which matches the one in the database. But it just gets back a single HTTP header which is Content-type: text/html. There is no other content at all returned from the API. If I switch back to @wodev then I see application/json returned.
check tt-rss error log in preferences, that’s where the errors probably are
plugin runs within tt-rss context so it should log errors via tt-rss
Nothing in that log either except for old errors. I’ve tested PHP error logging by making an intentional error in another website and that works fine. I’m at a loss really. I was hoping somebody else might be seeing the same issue but it may just be something specific to my setup. I’ve gone back to older versions of the script to before PDO and the same problem occurs. Any other versions of the script from the various github forks work fine. It’s literally just this digitaldj version that’s doing this. Weird if I’m the only one that is seeing this.
@xtaz
I am seeing the same problem that you are. However, I am seeing warnings in the log in preferences:
E_WARNING (2) plugins/fever/fever_api.php:58 unserialize() expects exactly 1 parameter, 2 given
1. plugins/fever/fever_api.php(58): unserialize(a:1:{s:8:"password";s:32:"PASSWORD_HASH";}, Array)
2. plugins/fever/fever_api.php(119): setUser()
3. plugins/fever/index.php(57): before()
It appears that the plugin requires PHP7. Since I could not get TTRSS to work with PHP7 (something about PDO not working because a driver could not be found), I changed the plugin:
fever_api.php:58
$obj = unserialize($line["content"], array("allowed_classes" => FALSE));
to
$obj = unserialize($line["content"]);
I’ll have a look at my broken PHP7 setup when I have more time …
@conflux thanks for the post. I had to make the change. After the recommended change I’m up and working @ line 58.
I’m on a old Ubuntu install with PHP 5.4.45. Pdo-test.php from the pdo thread passed but I got the same error as you.
I’m up and working so I’m happy.
That change doesn’t help me. I still get the same text/html empty content with no log output. I’m actually using PHP 7.2.0, though I had exactly the same problem when I was using PHP 7.1.x. Now that Xmas is over I need to take a look to see if I can work out the diff between the DigitalDJ version and the dasmurphy version and subsequent forks.
OK. I’ve at least confirmed the commit which breaks things for me. It’s Take back my plugin - fix a bunch of bugs which counters not updating, · DigitalDJ/tinytinyrss-fever-plugin@6d26584 · GitHub
Unfortunately that’s a massive change and makes it difficult to work out why that particular commit breaks it.
For what it is worth, I am not (and have not been) getting any log output from the plugin either.
I did see the issue with an empty text/html content when trying PHP 7. That was fixed by installing a missing package - it could have been php7.0-json, but I’m not sure (hard to keep notes late at night, sorry 
).
You’re welcome. I’m glad it’s working for you. 
It could indeed be a missing extension. Though you would expect the logs to state that fact wouldn’t you. There’s obviously something which is intercepting the logs I guess and not displaying them properly. My extensions are these… anything stand out as missing? JSON is there.
php72-7.2.0_1 PHP Scripting Language
php72-ctype-7.2.0_1 The ctype shared extension for php
php72-curl-7.2.0_1 The curl shared extension for php
php72-dom-7.2.0_1 The dom shared extension for php
php72-exif-7.2.0_1 The exif shared extension for php
php72-fileinfo-7.2.0_1 The fileinfo shared extension for php
php72-gd-7.2.0_1 The gd shared extension for php
php72-hash-7.2.0_1 The hash shared extension for php
php72-json-7.2.0_1 The json shared extension for php
php72-mbstring-7.2.0_1 The mbstring shared extension for php
php72-opcache-7.2.0_1 The opcache shared extension for php
php72-pcntl-7.2.0_1 The pcntl shared extension for php
php72-pdo-7.2.0_1 The pdo shared extension for php
php72-pdo_pgsql-7.2.0_1 The pdo_pgsql shared extension for php
php72-pgsql-7.2.0_1 The pgsql shared extension for php
php72-posix-7.2.0_1 The posix shared extension for php
php72-session-7.2.0_1 The session shared extension for php
php72-simplexml-7.2.0_1 The simplexml shared extension for php
Sorry for no replies. I set Discourse to Tracking, instead of Watching which apparently doesn’t email on replies.
What you can try is set display_errors to On then tcpdump the traffic. This might give you a better idea of what’s going on.
The 500 is usually because information PHP sends to Apache is invalid…usually this means errors are being put in the output stream, before the set of HTTP headers.
What OS, Apache version is this?
I would also double check your Apache errors log
I’ve tried all of these things. It doesn’t log anything. It’s nginx and php-fpm. I’ve set all of the logging options to on, tcpdump’d the traffic between nginx and php-fpm. All that happens is it sends 200 OK and Content-Type: text/html with no additional content. It gives a 200 with display_errors On and 500 with it Off.
I suspect it’s because ttrss takes over the logging itself for showing logs in the preferences panel but for some reason logs from this plugin just go missing. Other errors from ttrss are logged in the panel as expected, and errors from any other PHP script are logged either to the display, or to the syslog file as you would expect.
I wonder if there’s an easy way to stop ttrss taking over the logs so that errors are handled by PHP normally? That might help.
Change the log setting in config.php. It’s near the bottom of the file.
I am genuinely trying to recreate your issue.
I setup a VM setup as follows:
FreeBSD 11.1-RELEASE #0 r321309: Fri Jul 21 02:08:28 UTC 2017
nginx/1.12.2
PHP 7.2.1 (cli) (built: Jan 13 2018 01:10:44) ( NTS )
php72-ctype-7.2.1
php72-curl-7.2.1
php72-dom-7.2.1
php72-exif-7.2.1
php72-fileinfo-7.2.1
php72-gd-7.2.1
php72-hash-7.2.1
php72-iconv-7.2.1
php72-intl-7.2.1
php72-json-7.2.1
php72-mbstring-7.2.1
php72-opcache-7.2.1
php72-pcntl-7.2.1
php72-pdo-7.2.1
php72-pdo_pgsql-7.2.1
php72-pgsql-7.2.1
php72-posix-7.2.1
php72-session-7.2.1
php72-simplexml-7.2.1
postgres (PostgreSQL) 9.5.10
Upon installing tt-rss, the install procedure recommended php72-iconv-7.2.1 and php72-intl-7.2.1, which you don’t appear to have. I don’t see this making a difference, but just an FYI.
I would recommend the following:
Edit your /usr/local/etc/php.ini with the following directives:
error_reporting = E_ALL
display_errors = On
display_startup_errors = On
log_errors = On
error_log = php_errors.log
Edit your /usr/local/etc/php-fpm.conf to include directives:
error_log = log/php-fpm.log
Then, create php_errors.log in the root tt-rss folder e.g.:
touch /usr/local/www/nginx/tt-rss/php_errors.log
chmod 0777 /usr/local/www/nginx/tt-rss/php_errors.log
Restart php-fpm and check:
/var/log/php-fpm.log
/usr/local/www/nginx/tt-rss/php_errors.log
PHP errors really should appear in the System area of Preferences in tt-rss though, no matter how severe.
If that doesn’t work…
Can you provide your nginx, php-fpm, php confs?
Does this happen on a fresh tt-rss user?
I’ve tried installing the two missing extensions and that hasn’t made any difference. Changing the logging option in config.php hasn’t helped. I’ve previously tried all of the log settings that you mention in your post and they don’t help. Here are my files: Dropbox - Error
The php config is relatively normal. The nginx config possibly isn’t. It maps the API to /ttrss/fever/ rather than the normal location. But this works fine on every fork of the code except for your version. I guess I can try changing this so it uses the more standard path?
Same thing happens on a fresh user.
What gets me is with display_errors = Off it shows 500 error, but with display_errors = On it shows 200 OK with content_type text/html rather than json. This makes me think the reason I’m not seeing any errors logged is because there arn’t any errors, just that the plugin isn’t working and returning blank content. But I don’t understand why it decides to send error 500.
I really don’t know what to say. The files you provide work perfectly fine on my install.
I fully replaced my php-fpm configs and php.ini. I created a /usr/home/xtaz/www/ttrss. Moved my tt-rss instance into it and git cloned my fever plugin into the plugins.local folder. I created a dummy user for basic authentication which you have in your nginx config.
When I browse to your alias /ttrss/fever, I get the usual “{“api_version”:3,“auth”:0,“error”:“NOT_LOGGED_IN”}” and no PHP errors. iOS clients like Reeder seem to work OK.
What endpoint are you using to test this?
Can you provide your full nginx config? I assume there is some missing because with the snippets you gave, you don’t have index.php set as an index file. I am using the stock config with additional lines in the server scope as follows:
index index.html index.htm index.php;
include ttrss.conf;
Have you modified fastcgi_params - this could be a source of problems ?
What exact version of FreeBSD, nginx and postgres are you using?
I can only assume something is funky with the full nginx config or a specific version that we don’t have in common.
The only other thing I can think of is something Postgres specific or wrong file/directory permissions. Have you done anything specific with Postgres? Perhaps share config files from /usr/local/pgsql/data/*.conf ?
EDIT: I was just reading this SO thread nginx - PHP FPM returns HTTP 500 for all PHP errors - Stack Overflow
So, does “php_flag[display_errors] = on” in your php-fpm.conf make a difference?
php_flag[display_errors] = on also doesn’t make a difference.
I’ve uploaded the entire nginx config here now: Dropbox - Error , the only difference being I’ve excluded the users file with my passwords in it.
I’m also completely at a loss. It’s not like I don’t know what I’m doing as I do this as a job and I’ve done everything that I can think of. Logging works fine outside of the API, ttrss logs stuff itself fine, other PHP scripts all log errors fine.
The only thing left to me may be to try and go through the script line by line adding debug lines to see if I can find where it fails. It’s a shame that the changes between the git commit that broke it and where it worked is so huge or else I could probably easily figure this out.
Postgres is pretty much out of the box. The postgresql.conf isn’t touched at all, the pg_hba.conf has this in it to lock the ttrss user into only being able to access the ttrss database:
local ttrss ttrss scram-sha-256