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.

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. 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.

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.

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.

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

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. 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: