Hello,
recently I’ve discovered this issue: when I go in preferences and I’m using the default profile of any user (admin, my regular user, a new user created for test), the preferences don’t show any option:
If I create an additional profile for the user, that profile has normal visible options.
Switching back to default profile while the additional profile is in place, still no visible options.
I don’t know when the issue has started because I don’t go into prefs frequently, but of course in the past it was all ok.
I tried different browsers and anonymous browsing options, they made no difference.
tt-rss version (including git commit id):
19.2-234-g9aab6ec87
Platform (i.e. Linux distro, PHP, PostgreSQL, etc) versions:
Slackware Linux, PHP 7.2.19, MariaDB 10.4.6
fox
2
if there’s no logged errors you can try dumping your database and PMing it to me, i’ll take a look.
I didn’t see any error that sounds like related.
Thanks, when the platform allows me to send PM I will send a dump.
I’ve updated your profile. Try sending fox a PM now.
Same issue here. Maybe a result of data migration? Are you interested in another dump?
fox
6
gonna post an update here not just PM: i’ve imported the dump on my test mariadb instance but was unable to replicate the issue.
Anything special that I could execute on my installation to provide debug info?
fox
8
(e: start reading with third paragraph)
you can try cranking up mariadb query debugging somehow, other than that i’m afraid the only way is tinkering with stuff manually.
main query that collects user preferences to display is at classes/pref/prefs.php:515 if you’re on latest trunk, you can try poking at it. run it manually in sql console or something.
now that i think about it it’s possible that profile session variable is stuck in some kind of invalid state, you can try adding var_dump($profile); right after $profile = ... at line 503
it should be NULL for default profile but it probably isn’t.
I just get a NULL with my main profile, which is not the admin user
fox
10
well looks like this isn’t going to be easy then.
you can try checking that some data is actually received like this (it’s a bit further down)
$listed_boolean_prefs = [];
while ($line = $sth->fetch()) {
var_dump($line); <-- add this
The thing is that the query already returns no rows if executed in mysql client. If I replace the variables in the query executed at line 513 it should be something like:
SELECT DISTINCT
ttrss_user_prefs.pref_name,value,type_name,
ttrss_prefs_sections.order_id,
def_value,section_id,owner_uid
FROM ttrss_prefs,ttrss_prefs_types,ttrss_prefs_sections,ttrss_user_prefs
WHERE type_id = ttrss_prefs_types.id AND
(profile = NULL OR (NULL IS NULL AND profile IS NULL)) AND
section_id = ttrss_prefs_sections.id AND
ttrss_user_prefs.pref_name = ttrss_prefs.pref_name AND
owner_uid = 2
ORDER BY ttrss_prefs_sections.order_id,pref_name;
I’ve added owner_uid to the output for debugging. This doesn’t return anything. But if I remove some of the where clauses I get something that looks reasonable to me and I don’t understand why the full set of clauses doesn’t work. With this query:
SELECT DISTINCT
ttrss_user_prefs.pref_name,value,type_name,
ttrss_prefs_sections.order_id,
def_value,section_id,owner_uid
FROM ttrss_prefs,ttrss_prefs_types,ttrss_prefs_sections,ttrss_user_prefs
WHERE type_id = ttrss_prefs_types.id AND
(profile = NULL OR (NULL IS NULL AND profile IS NULL)) AND
section_id = ttrss_prefs_sections.id AND
ttrss_user_prefs.pref_name = ttrss_prefs.pref_name
ORDER BY ttrss_prefs_sections.order_id,pref_name;
I get a lot of results such as:
+-----------------------------+-------------------------------------------------------------------+-----------+----------+-------------------------------------------------------------------+------------+-----------+
| pref_name | value | type_name | order_id | def_value | section_id | owner_uid |
+-----------------------------+-------------------------------------------------------------------+-----------+----------+-------------------------------------------------------------------+------------+-----------+
| ALLOW_DUPLICATE_POSTS | false | bool | 0 | false | 1 | 1 |
| ALLOW_DUPLICATE_POSTS | false | bool | 0 | false | 1 | 2 |
| ALLOW_DUPLICATE_POSTS | false | bool | 0 | false | 1 | 3 |
| DEFAULT_UPDATE_INTERVAL | 30 | integer | 0 | 30 | 1 | 1 |
| DEFAULT_UPDATE_INTERVAL | 30 | integer | 0 | 30 | 1 | 2 |
| DEFAULT_UPDATE_INTERVAL | 30 | integer | 0 | 30 | 1 | 3 |
| ENABLE_API_ACCESS | false | bool | 0 | false | 1 | 1 |
| ENABLE_API_ACCESS | true | bool | 0 | false | 1 | 2 |
| ENABLE_API_ACCESS | true | bool | 0 | false | 1 | 3 |
| PURGE_OLD_DAYS | 60 | integer | 0 | 60 | 1 | 1 |
| PURGE_OLD_DAYS | 300 | integer | 0 | 60 | 1 | 2 |
| PURGE_OLD_DAYS | 60 | integer | 0 | 60 | 1 | 3 |
| USER_TIMEZONE | Automatic | string | 0 | Automatic | 1 | 1 |
| USER_TIMEZONE | Automatic | string | 0 | Automatic | 1 | 2 |
| USER_TIMEZONE | Automatic | string | 0 | Automatic | 1 | 3 |
| _COLLAPSED_FEEDLIST | false | bool | 0 | false | 1 | 1 |
| _COLLAPSED_FEEDLIST | false | bool | 0 | false | 1 | 2 |
| _COLLAPSED_FEEDLIST | false | bool | 0 | false | 1 | 3 |
| _COLLAPSED_LABELS | false | bool | 0 | false | 1 | 1 |
| _COLLAPSED_LABELS | false | bool | 0 | false | 1 | 2 |
| _COLLAPSED_LABELS | false | bool | 0 | false | 1 | 3 |
| _COLLAPSED_SPECIAL | false | bool | 0 | false | 1 | 1 |
| _COLLAPSED_SPECIAL | false | bool | 0 | false | 1 | 2 |
| _COLLAPSED_SPECIAL | false | bool | 0 | false | 1 | 3 |
| _COLLAPSED_UNCAT | false | bool | 0 | false | 1 | 1 |
| _COLLAPSED_UNCAT | false | bool | 0 | false | 1 | 2 |
fox
12
that is returning data for all users though (including uid 2), can you add back missing clauses one by one to see which one breaks it? start with owner_uid = 2.
this is quite curious.
e: oh owner_uid one is the only one removed? try replacing it with ttrss_user_prefs.owner_uid = 2.
It’s the user ID that breaks it. That is effectively the only one that I have removed.
fox
14
does this work?
select * from ttrss_user_prefs where owner_uid = 2 and profile is NULL;
The issue with the missing updates looks exactly the same.
Your select clause works. Must somehow be related to the join.
fox
17
i’m gonna state one more time that i should have never added support for mysql and its disfunctional derivatives.
Btw. my docker container here is running 10.4.6-MariaDB-1:10.4.6+maria~bionic, maybe this helps to debug this on your side?
fox
19
i’m using 10.1.38 (debian stretch) and the aforementioned query works as expected.
maybe something syntax-related has changed / got broken in newer versions. in all honesty i’m not sure if i want to jump through more mysql-related hoops.
Let me check my backups what version of mariadb was running last week when things still worked. Maybe that gives a clue.
