I'm using Firefox Mobile on Android. The site is in mobile mode.

When I select a tag to view, view the items, and then click "mark all as read" I will generally proceed to read another tag. I'll make my way through "news" and on to "funnies" for example.

I move to another tag by tapping the cog, yes. I have enough tags that I need to scroll to view some of the tags. When I try to scroll, the screen interprets that as a pull to refresh most of the time.

I'm not sure any screenshots would be useful. It's also not helpful that it's inconsistent, I think dependent upon the number of items marked as read?

I will try to capture it in a screen recording - when I have more items built up to read.

I tried the following on Firefox for Android but did not manage to reproduce it:

1. 2.

• Tap the cog wheel/settings button to open the menu
  
• Drag finger up until desired tag is on screen, then tap it to load it
  
• Tap cog wheel
  
• Tap mark as read button
  
• Tap cog wheel
  
• Drag finger up to scroll to tag list
  
• Tap another tag

It is not clear to me from your instructions what you are doing and what the issue actually is:

return to view tags

Do you mean tapping the cog/settings button to open the menu?

pulling down refreshes the page

Do you mean dragging the finger across the screen to scroll?

Also what browser and operating system do you use?

On mobile, if I'm viewing a tag and I mark all as read, return to view tags, pulling down refreshes the page. It seems to be this combination of actions which trigger it: I have to have marked all as read, not just moved between tags.

I'm using the latest version (installed maybe 15-Jan-2026).

In any event, that change seems to have made it function.

It's entirely possible I botched something along the way?

Sorry for the late reply, by the way - apparently my ISP's spam filtering wasn't catching these emails, but my local Outlook was, which is very unexpected (as I don't check the local spam folder very frequently at all).

It was getting hung up on my username and password, I believe - I have them as part of my bookmark URL and the new config file didn't have them, initially. I added them to the config and it didn't like that. I took them out of both and things seem to be in good order.

Hmm, that is weird.

Do you mean that you had something like https://selfoss.example.com/?user=davimack&password=CorrectHorseBatteryStaple as the bookmark? Or was there some other path? When I try this on my server, I just get redirected to /sign/in

Do you have selfoss installed in a subdirectory rather than a subdomain? That is not as well tested so I might have introduced a bug.

Could you please share your config (with sensitive fields censored), the precise version of selfoss and the web server?

It was getting hung up on my username and password, I believe - I have them as part of my bookmark URL and the new config file didn't have them, initially. I added them to the config and it didn't like that. I took them out of both and things seem to be in good order.

I unfortunately didn't keep the F12 window open, so can't say definitively what was happening, though.

Thank you for your helpful suggestion!

Selfoss stopped working, so I figured it was time to upgrade. I'd been on 2.17. I followed the steps, and got a 403. So I blew away the whole thing** and got "selfoss is still loading, please wait." So I downloaded the latest build, repeated the process, same story. This is the fully out of the box, not my data directory, install.

Any ideas on how to troubleshoot, please?

Since you are stuck on the middle error of client bootstrap, it sounds like something is wrong with the JavaScript file the server returned but the browser does not think the file failed to load.

Because it is just a static file, possibly something is misconfigured on the web server.

For troubleshooting, you can try the following:

1. Open the web browser’s development tools (usually F12 key)
2. Navigate to your selfoss instance.
3. In the Console tab of devtools, check if there are any errors.
4. In the Network tab of devtools, verify that there is a GET request to a URI like https://your.selfoss.website/index.60251538.js (the number might be different). It should look something like the following:
5. Open the URL, the content of the file should be the same as the contents of the file of the same name in /selfoss/public directory in the zip file.

If you use Apache, you will need to enable .htaccess and mod_rewrite, which is what typically redirects the requests to the public directory. Oops, looks like the requirements are not anywhere near the README.

My hosted website had been referencing PHP 7.2.34, which I just updated to 8.*

*(by changing an A record in DNS, so it's not like I'm really in control of this)

I do not see how changing a DNS record affects PHP version other than changing it to a server with a different version installed.

Selfoss stopped working, so I figured it was time to upgrade. I'd been on 2.17. I followed the steps, and got a 403. So I blew away the whole thing** and got "selfoss is still loading, please wait." So I downloaded the latest build, repeated the process, same story. This is the fully out of the box, not my data directory, install.

Any ideas on how to troubleshoot, please?

*(by changing an A record in DNS, so it's not like I'm really in control of this)
**(I saved my data directory of course)

If you can only trigger HTTP requests, you will need to specify username and password. Preferably as POST parameters but GET (query string) parameters will work too (just note that your web server might include GET parameters in logs).

I have activated login/pass in Selfoss but unhappy it blocks the cron to run as it gets an authorisation denied from Selfoss.
Is there a way to workaround that ? or to whitelist an IP address for Selfoss so cron script can execute properly ?

Thanks

Vincèn

If it started happening suddenly, that sounds like the database got corrupted or gotten to inconsistent state somehow. But selfoss only really modifies triggers when it is updated to a new version, and it stores the info that it performed a migration step in the database itself, so I am baffled how it could happen.

[2024-05-18T19:33:42.850580+00:00] selfoss.ERROR: SQLSTATE[HY000]: General error: 1360 Trigger does not exist {"exception":"[object] (PDOException(code: HY000): SQLSTATE[HY000]: General error: 1360 Trigger does not exist at /usr/local/www/nginx/mywebsite.com/src/helpers/DatabaseConnection.php:140)

Actually, you are not the first person experiencing this. It was reported on GitHub.

You should be able to work around it by replacing DROP TRIGGER with DROP TRIGGER IF EXISTS on the the following lines:

https://github.com/fossar/selfoss/blob/d45cba4a8013e0c50cdd583da9ca8e0aa5516d75/src/daos/mysql/Database.php#L241-L242

Also, are you sure SQLite complains about the trigger not existing? We are not even touching the existing trigger in SQLite – instead we create a new table from scratch.

I was using sqlite so I switched to mysql to test things and got the same error, yet when I check mysql from the shell the database connection did in fact work and tables got created in a fresh new database, despite seeing the above error.

If you are willing to debug this, I would appreciate the following info:

• Can you check what the version table contains. That will tell us how far along it got in the database schema migration step.
  
• Could you also share the lines in the log below [stacktrace] of the original error?
  
• What version of MySQL server are you running?
  
• Adding debug=1 and logger_level=DEBUG to your config in latest selfoss and trying with a clean database might be also helpful.

[2024-05-18T19:33:42.850580+00:00] selfoss.ERROR: SQLSTATE[HY000]: General error: 1360 Trigger does not exist {"exception":"[object] (PDOException(code: HY000): SQLSTATE[HY000]: General error: 1360 Trigger does not exist at /usr/local/www/nginx/mywebsite.com/src/helpers/DatabaseConnection.php:140)

I was using sqlite so I switched to mysql to test things and got the same error, yet when I check mysql from the shell the database connection did in fact work and tables got created in a fresh new database, despite seeing the above error.

My main setup is Nginx with PHP-FPM but I've also tested it with Apache24 and mod_php and got the same error, both are running php 8.2.18 now. I also tested both sqlite and mysql on the two different systems with the same result. I read through the PHP changelog and didn't find much of interest with any sqlite updates, just a few changes to PDO since 8.2.0 came out.

My Nginx system runs about two dozen websites, most use mysql with php-fpm and they all work fine. I can connect through sockets or over IP.

I've tried the latest Selfoss builds on Github as well as older Github builds from late 2023. Thought I'd ask here before abandoning the software and trying something else.

Maybe I'm just losing my mind. Happy to switch to another version of PHP to get it working again.

If you follow the basic installation instructions, it should be accessible under the /selfoss/ path on your web server. For example, if you are running it locally on your computer, it might be http://localhost/selfoss/. Or if you are using a web server associated with a domain, it might be something like https://www.example.com/selfoss/.

Item retention is controlled by items_lifetime option (30 days by default). But note that items will not be removed while they are still available in the feed (since they would just be re-added on next update).

Hier ein Auszug aus der Ini:
salt=
public=
html_title=selfoss
rss_title=selfoss feed
rss_max_items=5000
rss_mark_as_read=0
homepage=newest
language=de
auto_mark_as_read=0
auto_collapse=0
auto_stream_more=1
anonymizer=
use_system_font=
readability=
share=gtfprde
wallabag=
wallabag_version=1
allow_public_update_access=
unread_order=
load_images_on_mobile=1
auto_hide_read_on_mobile=0
env_prefix=selfoss_
camo_domain=
camo_key=
scroll_to_article_header=1

Lieben Dank im Voraus für Tipps!

Wally