It doesn't specifically require any updates or maintenance.Can someone from XF can give some details why this is suddenly Unmaintained without any announcements? Seeing it is from XF itself, I see this as an official add-on.
The problem is the friendly-URL nginx code snippet shown in the manual:
Code:location /xf/ { try_files $uri $uri/ /xf/index.php?$uri&$args; index index.php index.html; } location /xf/install/data/ { internal; } location /xf/install/templates/ { internal; } location /xf/internal_data/ { internal; } location /xf/library/ { internal; } location ~ \.php$ { try_files $uri =404; fastcgi_pass 127.0.0.1:9000; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; }
The problematic part is the try_files in the php-location. It serves as a security precaution to only send existing .php-files to the backend. But in our redirection-scenario files like showthread.php do not exist...
The remedy is to also redirect to index.php in this section like this:
Code:try_files $uri /xf/index.php?$uri&$args;
This is safe because XF's route controller will check the passed arguments and XF301VB routes accordingly.
location ~ \.php$ {
try_files $uri /index.php?$uri&$args;
#try_files $uri =404;
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
location = /showthread.php {
return 301 /threads/$arg_t/;
}
location = /member.php {
return 301 /members/$arg_u/;
}
Have issues on nginx as well, though for showthread.php and member.php links (from old vBulletin), I used the following nginx rewrite:
NGINX:location = /showthread.php { return 301 /threads/$arg_t/; } location = /member.php { return 301 /members/$arg_u/; }
Which appears to work perfectly for non-friendly vBulletin URL's.
So technically as long the thread ID remains the same, it should work on XenForo. Just from what I can see, basic URL's that include for example showthread.php won't properly forward giving a 404.
public function actionAttachment(ParameterBag $params)
{
if ($params->filedataid)
{
return $this->redirectContent($params, 'attachment_filedata', 'XF:Attachment', 'attachments',
$params->filedata_id);
}
else
{
return $this->redirectContent($params, 'attachment', 'XF:Attachment', 'attachments');
}
}
$params->filedataid
is set and then uses $params->filedata_id
. From what I can tell it would never go into the then-clause.try_files $uri /index.php?$uri&$args;
index index.php index.html;
location ~ \.php$ {
try_files $uri /index.php =404;
fastcgi_pass php:9000;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
I do no redirects at all on the nginx-site. All is done within the addon.This does not work for me it redirecs to "domain.com/threads//" hmmm
Nothing redirects using this addon on nginx, that is the experience of myself and a couple others. The other possibility is me and the others all have another common factor screwing up the redirects besides simply using nginx.
The problem is the friendly-URL nginx code snippet shown in the manual:
Code:location /xf/ { try_files $uri $uri/ /xf/index.php?$uri&$args; index index.php index.html; } location /xf/install/data/ { internal; } location /xf/install/templates/ { internal; } location /xf/internal_data/ { internal; } location /xf/library/ { internal; } location ~ \.php$ { try_files $uri =404; fastcgi_pass 127.0.0.1:9000; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; }
The problematic part is the try_files in the php-location. It serves as a security precaution to only send existing .php-files to the backend. But in our redirection-scenario files like showthread.php do not exist...
The remedy is to also redirect to index.php in this section like this:
Code:try_files $uri /xf/index.php?$uri&$args;
This is safe because XF's route controller will check the passed arguments and XF301VB routes accordingly.
HTH,
-Markus
open() ""/public/threads/ThreadName.123/styles/default/xenforo/reactions/emojione/sprite_sheet_emojione.png" failed (2: No such file or directory)
The second one allows me to hit "Save" but nothing visible happens or changes.
We use essential cookies to make this site work, and optional cookies to enhance your experience.