ExiledVip3r

While I'm here, another issue I've been having trouble tracking down lately is this error message popping up frequently in the system logs:

I've been at a loss as to what could be causing it, but I've tried disabling the app the hook it's loading comes from, but the error still comes up frequently in the log, just without mentioning the loaded hook.

I figured it out, it was an incompatible "back to top" plugin. Disabling it and making sure the cache was cleared of any hooks and such from it were gone cleared up the site to work on PHP8.0. Previous attempts at disabling/enabling it must've left some data over somewhere leading me to incorrectly assume it wasn't the cause.

Thanks.

30 minutes ago, balazsp said:

What's your current version? 

v4.7.3, which is as far as I know the last version to support PHP 7.4. Haven't been able to upgrade past it since I can't get PHP 8.0+ working smoothly.

Been wanting to update my site for a while to the current version of IPB, however, whenever I switch to the required PHP 8.0 or above (I tried both 8.0 and 8.1) the site will work as typical for a bit but eventually will start giving error 500 on both the site and admin panel, this break happens immediately if I goto admin panel's support page and click clear the system cache. Switching back to PHP 7.4 fixes it right away.

I've tried disabling all 3rd party apps and plugins and switching the default theme. The same result happens soon as I switch to PHP 8.0+

I'm using nginx webserver and Redis for system caching.

The only output I got in the nginx error log after switching to php-fpm 8.0 for a few minutes just now is the 3 errors below. I'm unsure if they are related though, as I'd expect there to be a lot more errors as the site gets heavy traffic and should've logged a lot more errors in the few minutes it was down using php8.0.

Quote

 

2023/03/22 20:47:47 [error] 722588#722588: *82123275 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Cannot use "parent" when current class scope has no parent in /home/<snipped>/www/public/system/Theme/Theme.php(2703) : eval()'d code on line 37" while reading response header from upstream, client: <snipped>, server: www.<snipped>.com, request: "GET /files/category/203-<snipped>/page/46/?listResort=1&csrfKey=9425f6ca872103efc3e2c20e775fbe0e HTTP/1.1", upstream: "fastcgi://unix:/run/php/php8.0-fpm.sock:", host: "www.<snipped>.com", referrer: "https://www.<snipped>.com/files/category/203-<snipped>/page/46/"

2023/03/22 20:47:49 [error] 722583#722583: *82129716 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Cannot use "parent" when current class scope has no parent in /home/<snipped>/www/public/system/Theme/Theme.php(2703) : eval()'d code on line 37" while reading response header from upstream, client: <snipped>, server: www.<snipped>.com, request: "GET /admincp/?app=core&module=support&controller=support HTTP/1.1", upstream: "fastcgi://unix:/run/php/php8.0-fpm.sock:", host: "www.<snipped>.com", referrer: "https://www.<snipped>.com/admincp/?app=core&module=overview&controller=dashboard"

2023/03/22 20:48:47 [error] 722580#722580: *82131013 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Cannot use "parent" when current class scope has no parent in /home/<snipped>/www/public/system/Theme/Theme.php(2703) : eval()'d code on line 37" while reading response header from upstream, client: <snipped>, server: www.<snipped>.com, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/run/php/php8.0-fpm.sock:", host: "www.<snipped>.com", referrer: "https://www.google.com/"

 

Any help would be much appreciated, I've tried pretty much everything I can think of but haven't been able to make much progress on figuring it out.

Since updating to the newest version, my users are no longer able to change the sort order of the files in the parent category. For example... "?sortby=file_name&sortdirection=asc" no longer seems to have an effect while viewing the parent category.

Small request... Could you swap the sort direction of the deletion requests in the ModCP to descending order, or add an option for it? That way older requests are displayed first.

I run a very large forum and get ~100 delete requests a day, and I prefer to process the older requests first as I usually get lazy with approving them and tend to be a week or two behind on the requests I'm approving.

I usually end up editing the source code after every update to swap the queries ASC to a DESC, would be nice to stop doing that though.

22 hours ago, Nathan Explosion said:

Happy to submit a request for a refund for you, if you wish?

Nah, it's my mistake. I've already paid for this plugin as well. I annoyingly just can't install or download it.

I'll just hold out and wait for this to hopefully be updated. Thanks though, keep up the awesome work.

On 6/22/2021 at 9:24 AM, Nathan Explosion said:

For reference...

I was asked by someone if my "(NE) Collapse pinned topics" plugin was compatible with IPS 4.6.x

As it works alongside this plugin, I have tested "(NB40) Separate Pinned Topics" with IPS 4.6.x and can confirm that it does work as expected. However, there is the caveat that you must have "(NB40) Separate Pinned Topics" installed prior to upgrading to IPS 4.6.x as the plugin cannot be installed new on IPS 4.6.x as it is not currently marked as compatible.

I bought your plugin not realizing it required this one. Entirely my own fault for not reading the info first, you pretty clearly say in it to not get it without having this plugin first.

Stuck waiting for this to update to 4.6 now so I can use it.

@Adriano Faria My task queue has immediately become overwhelmed and behind by a ton after the update. I only mass deleted about 8 pages of delete requests after the update, I normally have 70+ pages...

Did you limit the number of deletions done per task run? If not, that is likely bogging the task queue down as a result...

This is a few hours after updating, and only half of the current task queue, just what I could fit into a screenshot.

On 2/9/2021 at 3:01 AM, Adriano Faria said:

Ok. I’ll update the app in a few days to run the requests on a background task. 

On 2/10/2021 at 2:49 AM, Adriano Faria said:

My bad. This notification is the one when someone requests to delete the account. I guess you’re talking about the one when you process the request (approving or denying it)? If so, I have submitted a new version with two new settings so admins can choose if an email will be sent to the user. New version also makes the mass actions (delete all accounts and cancel all requests) to run on a background task.

Thanks so much for the changes! They are a big help to me!

7 minutes ago, Adriano Faria said:

1,668 requests is too much indeed. 😱

I get about 4000 new registrations a day, so 1500-ish deletion requests over 6 weeks seems pretty small to me? A lot of users/leechers register just to download a few things and then delete their account it seems.

Quote

I’m not sure which email. See if it shows up in the ACP Members Notifications. If it does, you can disable it there for all members. 

It does. Never noticed that before as I rarely have a reason to look at the notification defaults, but I've switched it to disabled now. 

Been using this mod for a few years, thanks! It is a much needed essential functionality.

However... I get a lot of delete requests. After 6 weeks of ignoring my delete request queue I have 84 pages (1,668 Requests, going by my current queue...)

While I usually prefer to go through them page by page so I can see if anybody has a specific reason listed I should take note of, or a major user is  requesting deletion that I should contact for confirmation first... I even wrote a javascript hack to mass delete all requests on the current page with a single click so I could speed through it.

But, sometimes I'm lazy (or just really really behind on requests) and would prefer the "Delete All Accounts" button actually did what it suggests. But it never has. Clicking the button always results in a time out and only a handful of accounts ending up deleted.

Could you fix it so the mass deletion is more reliable? Perhaps instead of performing the deletion at request it should just mark accounts for deletion and be done overtime in a task?

Would also appreciate an option to disable confirmation emails, as they feel like a pointless drain to my monthly transactional email limit.

Ah! Working perfectly now. Thanks for the help!

Suppose I should've actually read the changelog. 

Plugin settings are correct. It's set to enabled and Nginx for webserver.

Using the sendfile_test works fine as well.

It seemed to work fine when I was using an older version of the plugin on IPB 4.5. Errors started when I updated the plugin to the current version.

Nothings changed in the server config that I can remember changing. But here's my nginx config file for it:

server {
        listen 80;
        listen [::]:80;
        server_name <snip>.com;
        rewrite ^ http://www.<snip>.com$request_uri permanent;
}

server {
        listen 80;
        listen [::]:80;

        listen 443 ssl http2;
        listen [::]:443 ssl http2;

        ssl_certificate /etc/nginx/ssl/<snip>.2020.chained.crt;
        ssl_certificate_key /etc/nginx/ssl/<snip>.2020.key;
        ssl_dhparam  /etc/nginx/ssl/dhparam.pem;

        server_name www.<snip>.com static.<snip>.com dl.<snip>.com srv1.<snip>.com;

        root /home/<snip>/www/public;

        index index.php index.html;

        client_max_body_size 1024M;

        access_log /var/log/nginx/<snip>.access.log main buffer=32k flush=5m;
        error_log /var/log/nginx/<snip>.error.log;
        #access_log off;
        #error_log on;

        rewrite ^/privacypolicy$ /privacy permanent;

        location ~ ^/uploads/screenshots/(.*){ return 301 https://www.<snip>.com/screenshots/$1; }


        location ~* \.(?:ico|js|css|png|jpeg|jpg|gif|xml|bmp)$ {
                expires max;
                add_header Pragma public;
                add_header Cache-Control "public, must-revalidate, proxy-revalidate";
                log_not_found off;
                access_log off;
                #limit_req zone=two burst=10;
        }

        #location ~* (?:/public/style_|/cache/|/hooks/|/uploads/).*\.(?:php|cgi|pl|php3|php4|php5|php6|phtml|shtml)$ { deny all; }
        location ~ /\.ht { access_log off; log_not_found off; deny all; }
        location = /robots.txt  { access_log off; log_not_found off; }
        location = /favicon.ico { access_log off; log_not_found off; }

        location / {
                #include admin;
                #try_files $uri $uri/ /index.php?$is_args$args;
                try_files $uri $uri/ /index.php?$query_string;
                #return 503;
        }

        error_page 503 @maintenance;
        location @maintenance {
                rewrite ^(.*)$ /error503.html break;
        }

        location ~ ^/(uploads|datastore|system|plugins)/.*\.(?:php\d*|phtml)$ {
                allow 127.0.0.1;
                deny all;
        }

        location ~ \.php$ {
                include fastcgi_params;
                try_files $uri =404;

                fastcgi_send_timeout 60;
                fastcgi_read_timeout 60;
                fastcgi_buffers 128 8k;
                fastcgi_pass unix:/run/php/php7.4-fpm.sock;
                fastcgi_index index.php;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_param PHP_VALUE open_basedir="/home/<snip>/www:/usr/share:/home/<snip>/tmp:/tmp";

        }

}

This plugin worked fine for me on IPB 4.4, however after updating to 4.5 it's started to cause all downloads to error out. 

Nginx error logs show the following:

Quote

2021/01/09 19:14:12 [error] 795161#795161: *1188 rewrite or internal redirection cycle while internally redirecting to "/index.php", client: <snip>, server: www.<snip>.com, request: "GET /files/file/13459-<snip>/?do=download&r=816033&confirm=1&t=1&csrfKey=10a1f5ccf53d7fab9ed2f2e39fa9c35f HTTP/1.1", upstream: "fastcgi://unix:/run/php/php7.4-fpm.sock", host: "www.<snip>.com"