Update to latest upstream version.

[zenhack]

...as a reminder to myself -- I gave this a whack just now, but it's a bit non-trivial in that apparently we now need php >=7.2, which the debian package isn't...

[ocdtrekkie]

It's not actually that bad, I think, just some busywork. The Debian Buster stack covers this, we just need to merge your custom changes to the stack scripts with the newer stack scripts.

If you want, I can probably submit it as a PR.

[zenhack]

Yeah, I imagine it isn't a huge deal. A PR would be welcome.

[ocdtrekkie]

Consider it on my to-do list. :)

[ocdtrekkie]

PR #27 is essentially me merging the changes from vagrant-spk's upgraded stacks into the customized files in this repo. It should work, but isn't tested.

[zenhack]

I finally got around to giving this another whack; I have the latest upstream merged on the branch update-jun-21, and shook out a couple issues, but am getting an error when trying to start the server:

Exception while creating PDO object:could not find driver

However, I can confirm that the pdo_mysql module is loaded, and if I add the relevant extensions explicitly to php.ini I just get warnings about the extension being loaded more than once. I'm a little stumped, may fuss with it more later, but wouldn't mind a second pair of eyes.

[ocdtrekkie]

I can definitely replicate your issue, and I'm a bit baffled. It seems like it's an issue others on the TTRSS community have reported... but in true TTRSS fashion, people asking tend to get snide remarks and insults instead of actionable ideas on how to troubleshoot it. :| There are a few PDO-related commits that are pretty recent which seem to either cause or try to address issues loading the PDO driver. I will try to keep looking this weekend.

[ocdtrekkie]

So, even though it doesn't seem directly related, this thread about the error: https://community.tt-rss.org/t/exception-while-creating-pdo-object-could-not-find-driver/4540 specifically points out that config.php is no longer supported: https://community.tt-rss.org/t/rip-config-php-hello-classes-config-php/4337

And the parent says their issue was fixed when they fixed the new way of doing config options.

[zenhack]

That does seem to be the source of the problem. Got past that, messing around with some new issues re: schema updates, but going to put it down for the night.

[zenhack]

Decided to try this again. Got past the schema update issue I was seeing. Boots up, but new grains seem to have problems subscribing to feeds (haven't tried existing ones); after the initial add it fails to actually fetch, and if you do "edit feed," the URL field is just "0". Fixing it manually works, but that is obviously a blocker.

[ocdtrekkie]

Anything interesting in maybe the TTRSS log in the UI?

[zenhack]

No, the grain log is distressingly quiet; it is just the logging from powerbox-http-proxy, which looks fine.

Interestingly, when I try to add a second feed (a different one), it errors telling me I am already subscribed to that feed.

[ocdtrekkie]

@zenhack I was curious about TTRSS's log, as opposed to the grain log.

[zenhack]

Nothing. Just messages about php-fpm starting up. nginx's error log is an empty file, mysql's has nothing interesting in it either.

[ocdtrekkie]

Even here, with severity set to Everything? (Your blog feed timed out for me earlier, it seems!)

[ocdtrekkie]

I poked around the commits on the branch from upstream. I saw some changes to a function for rewriting relative URLs, but I don't know if I see anything that particularly stands out as "definitely what broke this".

[zenhack]

There are some things in the event log; I'd been digging around in the filesystem. Is there an easy way to export that as text? In any case, here's the awkwardly formatted copy & paste version:

Error | Filename | Message | User | Date
-- | -- | -- | -- | --
E_USER_NOTICE (1024) | :0 | Update process for feed 2 ([Unknown], owner UID: 1) failed with exit code: 100 (Requested URL failed extended validation.). |   | 16:08
E_WARNING (2) | classes/feedparser.php:20 | DOMDocument::loadXML(): Empty string supplied as input 1. classes/feedparser.php(20): loadXML() 2. classes/rssutils.php(302): __construct() 3. classes/rssutils.php(364): update_basic_info(2) 4. update.php(235): update_rss_feed(2, 1) |   | 16:08
E_USER_NOTICE (1024) | :0 | Update process for feed 2 ([Unknown], owner UID: 1) failed with exit code: 100 (Requested URL failed extended validation.). |   | 15:38
E_WARNING (2) | classes/feedparser.php:20 | DOMDocument::loadXML(): Empty string supplied as input 1. classes/feedparser.php(20): loadXML() 2. classes/rssutils.php(302): __construct() 3. classes/rssutils.php(364): update_basic_info(2) 4. update.php(235): update_rss_feed(2, 1) |   | 15:38
E_NOTICE (8) | classes/feeds.php:475 | Undefined index: last_login_update 1. classes/feeds.php(475): ttrss_error_handler(8, Undefined index: last_login_update, classes/feeds.php, 475, [{"feed":-3,"method":"","view_mode":"adaptive","cat_view":false,"next_unread_feed":0,"offset":0,"order_by":"default","check_first_id":0,"sth":false}) 2. backend.php(133): view()  Forwarded Protocol: http Remote IP: 127.0.0.1 Request URI: /backend.php User agent: Mozilla/5.0 (X11; Linux x86_64; rv:94.0) Gecko/20100101 Firefox/94.0 | admin | 15:36
E_WARNING (2) | classes/feedparser.php:20 | DOMDocument::loadXML(): Empty string supplied as input 1. classes/feedparser.php(20): loadXML() 2. classes/rssutils.php(302): __construct() 3. classes/rssutils.php(364): update_basic_info(2) 4. classes/feeds.php(681): update_rss_feed(2, 1) 5. backend.php(133): updatedebugger()  Forwarded Protocol: http Remote IP: 127.0.0.1 Request URI: /backend.php User agent: Mozilla/5.0 (X11; Linux x86_64; rv:94.0) Gecko/20100101 Firefox/94.0 | admin | 15:06
E_WARNING (2) | classes/feedparser.php:20 | DOMDocument::loadXML(): Empty string supplied as input 1. classes/feedparser.php(20): loadXML() 2. classes/rssutils.php(302): __construct() 3. classes/feeds.php(1049): update_basic_info(2) 4. classes/feeds.php(971): _subscribe(0, 0, , ) 5. backend.php(133): add()  Forwarded Protocol: http Remote IP: 127.0.0.1 Request URI: /backend.php User agent: Mozilla/5.0 (X11; Linux x86_64; rv:94.0) Gecko/20100101 Firefox/94.0 | admin | 15:06
E_NOTICE (8) | classes/feeds.php:475 | Undefined index: last_login_update 1. classes/feeds.php(475): ttrss_error_handler(8, Undefined index: last_login_update, classes/feeds.php, 475, [{"feed":-3,"method":"","view_mode":"adaptive","cat_view":false,"next_unread_feed":0,"offset":0,"order_by":"default","check_first_id":0,"sth":false}) 2. backend.php(133): view()  Forwarded Protocol: http Remote IP: 127.0.0.1 Request URI: /backend.php User agent: Mozilla/5.0 (X11; Linux x86_64; rv:94.0) Gecko/20100101 Firefox/94.0 | admin | 15:05
E_USER_NOTICE (1024) | :0 | Migrated preferences of user 1 (profile 0)  Forwarded Protocol: http Remote IP: 127.0.0.1 Request URI: / User agent: Mozilla/5.0 (X11; Linux x86_64; rv:94.0) Gecko/20100101 Firefox/94.0 | admin | 15:05
E_USER_NOTICE (1024) | :0 | Applied migration to version 0 for ttrss_version

[ocdtrekkie]

So the errors there only seem to talk about getting an empty feed URL input, so my guess is the issue is when adding the feed to begin with... It looks like TTRSS rearchitected a bunch of crud, including some URL validation features which includes something with rewriting relative URLs (which I believe refers to embeds from the feed URL that are relative to it, not the self url of the server), and basically replacing the entire database interaction method from pretty ordinary PDO prepares to some other thing, example here: https://github.com/zenhack/ttrss-sandstorm/commit/7cf12233d7e24b0d745486e378a3351ef7cc67e4

[ocdtrekkie]

Search results on the TTRSS community both possibly useful and likely not useful reports around "Empty string supplied as input 1". The maintainer was rude to all of them, so I am not sure if there is a fix or not. I am going to keep looking.

[ocdtrekkie]

I'm inclined to suggest grabbing from master again, perhaps? There's a pretty decent number of updates to all of the related chunks of code. I am not sure if any particular problem is fixed, but it is claimed that git master is stable (this issue suggests otherwise, but I digress), and at best we probably shouldn't be trying to debug old code.

[zenhack]

Yeah, it probably doesn't make sense to try to debug the old version. I'm getting the same exact problem on after pulling in the latest master from upstream though (now on the branch update-dec-21).

[zenhack]

Hm, just saw the same behavior on my prod grain when adding a new feed for the first time in a while. I was able to reproduce it on a fresh grain with the current release, but it only crops up if I try to enter the main domain and have it discover the exact feed url via <link rel=alternate tags, rather than just giving it the url myself; the latter still works.

So it seems like this broke and nobody noticed :(

[ocdtrekkie]

Interesting. I want to say I added some feeds in the last couple weeks though, and I want to say at least once I added via main domain because I couldn't find the specific XML link...

[zenhack]

Can you try testing to see if it still works for you?

[ocdtrekkie]

Created a new grain of current release:

I added https://www.engadget.com/ and it got https://www.engadget.com/rss.xml

I added https://www.arstechnica.com/ and it got http://feeds.arstechnica.com/arstechnica/index/

[zenhack]

Hm, I can confirm that those work as expected, as does https://sandstorm.io. However, https://capnproto.org does not.

In the next day or two I will see if I can reproduce the successes on the WIP update; I don't remember what sites I tried, and it seems like this is a function of the site itself.

[zenhack]

I can confirm that ars & engadget both work on my test grain. So I'm going to assume this is unrelated to the update (probably the cloudflare thing?) and proceed. I'll pull in changes from master again since its been a couple weeks, and assuming that doesn't trigger any new issues, submit to the app market.

[zenhack]

Ug, it works, but now that I'm going to actually package it I'm noticing that pulling in mysql 5.5 via nix is failing:

error: anonymous function at /home/vagrant/nixpkgs/pkgs/top-level/default.nix:20:1 called with unexpected argument 'inNixShell'

       at /home/vagrant/nixpkgs/pkgs/top-level/impure.nix:84:1:

           83|
           84| import ./. (builtins.removeAttrs args [ "system" "platform" ] // {
             | ^
           85|   inherit config overlays crossSystem crossOverlays;

I suspect this is because of some changes in nix mainline, such that this no longer works; I suppose we could pin the version of nix we're using too, rather than just nixpkgs.

I'd hazard a guess this is related to nix flakes support?

[zenhack]

Ok, got past that by pinning nix to 2.3

...but now I'm blocked by https://github.com/sandstorm-io/sandstorm/issues/3535

[zenhack]

Ok, worked around that issue and submitted.

[ocdtrekkie]

Can close this one, I think.