News:

SMF 2.1.4 has been released! Take it for a spin! Read more.

Main Menu

Can't change thread alert settings in 2.1rc2

Started by m4z, September 01, 2019, 08:32:53 AM

Previous topic - Next topic

m4z

Hi (hope this isn't a duplicate)!

In my private installation, when I view a thread and want to change the notification settings by clicking on the top or bottom "No alerts or emails" button and choose any of the four available options, I see a huge "Loading..." banner at the top of the page and nothing further happens (when reloading after a while, the setting hasn't changed). Subscribing to boards works fine.

My admin log contains the following two errors:
First:

  • Type of error: Critical
  • The database value you're trying to insert does not exist: 0
    Function: TopicNotify
  • https://[my-forum]/index.php?action=notifytopic;topic=38;mode=3;[hexstring]=[hexstring];xml
  • /home/[smf-user]/public_html/Sources/Notify.php (Line 145)

Second:

  • Type of error: General
  • The database value you're trying to insert does not exist: 0
  • https://[my-forum]/index.php?action=notifytopic;topic=38;mode=3;[hexstring]=[hexstring];xml

The code section mentioned in the first error is this:

   138: $smcFunc['db_insert']($insert ? 'insert' : 'replace',
   139: '{db_prefix}log_topics',
   140: array(
   141: 'id_member' => 'int', 'id_topic' => 'int', 'id_msg' => 'int', 'unwatched' => 'int',
   142: ),
   143: $log,
   144: array('id_member', 'id_topic')
==>145: );



When I inspect my action in Chromium, I see a XHR with a response of 500:

Request headers:

GET /index.php?action=notifytopic;topic=38;mode=3;[hexstring]=[hexstring];xml HTTP/1.1
Host: [my-forum]
Connection: keep-alive
Accept: */*
DNT: 1
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.132 Safari/537.36
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Referer: https://[my-forum]/index.php?topic=38.msg125;boardseen
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9,de-DE;q=0.8,de;q=0.7,es-ES;q=0.6,es;q=0.5,ru-RU;q=0.4,ru;q=0.3
Cookie: SMFCookie[number]=[stuff1][my-forum][morestuff1]; PHPSESSID=[evenmorestuff1]; SMFCookie[number]=[stuff2][another-forum-on-another-subdomain][morestuff2]; PHPSESSID=[evenmorestuff2]


Response (invisible to the user):

<div id="fatal_error">
<div class="cat_bar">
<h3 class="catbg">
An error has occurred
</h3>
</div>
<div class="windowbg">
<div class="padding">
The database value you're trying to insert does not exist: 0
</div>
</div>
</div>
<div class="centertext">
<a class="button" href="javascript:document.location=document.referrer">Back</a>
</div>
"Faith is what you have in things that don't exist."
--Homer Simpson

Es gibt hier im Forum ein deutsches Support-Board!

d3vcho

I couldn't replicate the error. Are you using RC2 or latest GitHub build?
"Greeting Death as an old friend, they departed this life as equals"

m4z

RC2 (plus some manual bugfixes in one of the two installations I tested this in). Will try to get a full picture, maybe update (most likely no today)...
"Faith is what you have in things that don't exist."
--Homer Simpson

Es gibt hier im Forum ein deutsches Support-Board!

d3vcho

You should use latest GitHub build. RC2 was released a few months ago and there has been a lot of work done in 2.1.
"Greeting Death as an old friend, they departed this life as equals"

m4z

Yeah, haven't had time yet to look into release/update management (or even to set up backups) for my staging and production forums. Are there any docs on best practices, or should I just put my staging and prod forum dirs into different git branches?
"Faith is what you have in things that don't exist."
--Homer Simpson

Es gibt hier im Forum ein deutsches Support-Board!

d3vcho

There are no docs for that. We just recommend not to use SMF 2.1 on production sites because as it's an under-development version, you may encounter errors and bugs. Although some people decide to run it, it depends on your skills in general. There are some people that maintain their production sites up to the latest GitHub build, some others up to the latest release (RC2 in our case)... It just depends on what do you want and what how much are you willing to risk based on your skills.

If you have 2 sites and one of them is in production, I would recommend sticking with RC2 in the production one and keep the other one updated with latest GitHub build as a playground.
"Greeting Death as an old friend, they departed this life as equals"

m4z

Quote from: d3vcho(); on September 01, 2019, 03:02:30 PM
We just recommend not to use SMF 2.1 on production sites because as it's an under-development version, you may encounter errors and bugs. Although some people decide to run it, it depends on your skills in general. There are some people that maintain their production sites up to the latest GitHub build, some others up to the latest release (RC2 in our case)... It just depends on what do you want and what how much are you willing to risk based on your skills.

Yeah, I think I know what I'm doing (and have seen and reported my share of bugs), although I'm not strong and PHP and always short on time. ;)
My small user group was involved in the decision and preferred being beta testers. (Also, "production" in my case just means "a bunch of friends needed a private forum for a hobby", no SLAs or anything, just unpaid volunteer work.)


Quote from: d3vcho(); on September 01, 2019, 03:02:30 PM
If you have 2 sites and one of them is in production, I would recommend sticking with RC2 in the production one and keep the other one updated with latest GitHub build as a playground.

The point of the staging or "beta" forum is to be exactly the same as the production site, only with less users and no (precious) content, to test any small to major change before touching the production forum.
I'll try to update my third, previously unmentioned, throw-away "alpha" forum to HEAD once I've figured out a way to manage my changes (I will probably just put the forum dirs into different git branches later this month, to be able to cherry-pick file changes across them, and because I have no better idea right now).
"Faith is what you have in things that don't exist."
--Homer Simpson

Es gibt hier im Forum ein deutsches Support-Board!

m4z

My problem persists in the current Github ("release-2.1" branch) HEAD (6ba1e53c0b65edb202fa17b9dc0088f610fdbfd8, 2019-09-01).
"Faith is what you have in things that don't exist."
--Homer Simpson

Es gibt hier im Forum ein deutsches Support-Board!

shawnb61

I cannot replicate this - either under RC2 or the current github, in my WAMP or Linux environments. 

Could you copy the support info from under Admin | Main | Support & Credits?  That would provide the mysql & php versions. 

Do you have any mods installed?

Was RC2 your initial install?  Or did you install 2.1 prior to RC2?

When upgrading to the current github, did you run the upgrader, or just overwrite the files? 
Address the process rather than the outcome.  Then, the outcome becomes more likely.   - Fripp

m4z

Quote from: shawnb61 on September 08, 2019, 11:37:38 AM
I cannot replicate this - either under RC2 or the current github, in my WAMP or Linux environments. 

Could you copy the support info from under Admin | Main | Support & Credits?  That would provide the mysql & php versions. 

Yeah, later today. A mod uninstall just broke my playground install, will have to reinstall.


Quote from: shawnb61 on September 08, 2019, 11:37:38 AM
Do you have any mods installed?

None that should matter:


Quote from: shawnb61 on September 08, 2019, 11:37:38 AM
Was RC2 your initial install?  Or did you install 2.1 prior to RC2?

Initial install.


Quote from: shawnb61 on September 08, 2019, 11:37:38 AM
When upgrading to the current github, did you run the upgrader, or just overwrite the files?

I dropped the database, then copied over the files from a current git checkout with the following script, then ran the installer. I hope this gives me a fresh install.

# cat /root/git/smf-alpha-deploy.bash
#!/bin/bash

set -e

GITCO="/root/git/SMF2.1"
TARGET="/home/alpha-smf/public_html"

# TODO only works once per day
mv ${TARGET}{,.$(date +%F)}
mkdir ${TARGET}
cp -r ${GITCO}/* ${TARGET}/

# some files aren't where they're supposed to be
rm -rf ${TARGET}/other
cp ${GITCO}/other/{install*,Settings.php,readme.html} ${TARGET}/

chown -R alpha-smf.www-data ${TARGET}/
chmod -R 775 ${TARGET}/
"Faith is what you have in things that don't exist."
--Homer Simpson

Es gibt hier im Forum ein deutsches Support-Board!

Arantor

May be relevant to note that this is Postgres (judging by comments in other threads) which means it might not work properly and probably has never been tested in PGSQL before now.

m4z

Quote from: m4z on September 08, 2019, 11:49:47 AM
Quote from: shawnb61 on September 08, 2019, 11:37:38 AM
I cannot replicate this - either under RC2 or the current github, in my WAMP or Linux environments. 

Could you copy the support info from under Admin | Main | Support & Credits?  That would provide the mysql & php versions. 

Yeah, later today. A mod uninstall just broke my playground install, will have to reinstall.

Support Information:
Quote
Version Information:
Forum version: SMF 2.1 RC2
Current SMF version: SMF 2.1 RC2
GD version: 2.1.1-dev
PostgreSQL engine: PostgreSQL
PostgreSQL version: 9.4.22
PHP: 5.6.40-0+deb8u4
Server version: lighttpd

I haven't installed the mods again, the problem exists without them, too.


Quote from: Arantor on September 08, 2019, 01:59:05 PM
May be relevant to note that this is Postgres (judging by comments in other threads) which means it might not work properly and probably has never been tested in PGSQL before now.

Yeah I figured this would be visible in the support info (and I was in a hurry). I also can't judge if the DB type has any influence on Notification behavior. From your comment I assume it does?
"Faith is what you have in things that don't exist."
--Homer Simpson

Es gibt hier im Forum ein deutsches Support-Board!

Arantor

I'm just suggesting that it might be a PGSQL-specific bug because that stuff has never, ever been thoroughly tested on PGSQL.

I don't think it misbehaves on MySQL but it's been a long time since I checked.

albertlast

Can you please check the postgres log in you data directy of postgres?
Ther should be listen query from smf which created errors.

Based on the error message you mention,
the error don't sound like a postgres issue.

Please had in mind that gdpr helper is not working on postgres,
as fare i know.

m4z

Quote from: albertlast on September 08, 2019, 04:23:04 PM
Can you please check the postgres log in you data directy of postgres?
Ther should be listen query from smf which created errors.

Based on the error message you mention,
the error don't sound like a postgres issue.

This is all I have for the last install:
Quote
2019-09-08 19:37:50 UTC [14086-1] alpha-smf@alpha-smf ERROR:  relation "alphasmf_settings" does not exist at character 36
2019-09-08 19:37:50 UTC [14086-2] alpha-smf@alpha-smf STATEMENT:
                                SELECT variable, value
                                FROM alphasmf_settings
2019-09-08 19:37:50 UTC [14080-1] alpha-smf@alpha-smf ERROR:  relation "alphasmf_settings" does not exist at character 34
2019-09-08 19:37:50 UTC [14080-2] alpha-smf@alpha-smf STATEMENT:
                        SELECT variable, value
                        FROM alphasmf_settings

The error about char 36 is in the logs 14 times, the last one about char 34 only once. IIRC, I had errors like this on every install, right when the DB tables are created the first time. I always assumed this was some code testing for pre-existing tables.


Quote from: albertlast on September 08, 2019, 04:23:04 PM
Please had in mind that gdpr helper is not working on postgres,
as fare i know.

I have it working and been using it for a few months (I can install and use it without problems, just not uninstall it ;D). But as I stated above, the problem persists whether I install any mods or not.
"Faith is what you have in things that don't exist."
--Homer Simpson

Es gibt hier im Forum ein deutsches Support-Board!

albertlast

But the table alphasmf_settings exists now?

You gdpr fix looks very wrong,
the mod author or you should use the smf db_insert api like mention below.

m4z

Quote from: albertlast on September 08, 2019, 04:53:35 PM
But the table alphasmf_settings exists now?

Quotealpha-smf=> select * from alphasmf_settings;
[...]
(212 rows)

I guess I'd have more than my 2 errors (mentioned in the first post) in the error log if that table was missing.



Quote from: albertlast on September 08, 2019, 04:53:35 PM
You gdpr fix looks very wrong,
the mod author or you should use the smf db_insert api like mention below.

I'm not surprised, I only have a very basic understanding of SMF and GDPRHelper code, and haven't had time to look into the db_* functions yet. I'll keep it in mind, but it's totally OT here. ;)
"Faith is what you have in things that don't exist."
--Homer Simpson

Es gibt hier im Forum ein deutsches Support-Board!

albertlast

Tested with the nightly version of today,
with
pg 11
php 7.3

no error message appears by changing the notify type,
when clicken on the top right of a thread and choose one mode.

m4z

Thanks for testing, I'll see how the nightly behaves on my server (sometime later this week).
"Faith is what you have in things that don't exist."
--Homer Simpson

Es gibt hier im Forum ein deutsches Support-Board!

m4z

I'm having the same problem with the nightly from an hour ago. :-\

Any way to make the logs more verbose?
"Faith is what you have in things that don't exist."
--Homer Simpson

Es gibt hier im Forum ein deutsches Support-Board!

Advertisement: