As of DBSEO1.1.3 I have an issue in that notifications go to the front of the user's profile page, not the mentions tab of the DBTech Advanced User Tagging extension, nor the Thanks/Likes tab of the DBTech Thanks/Like extension. This was a problem with VBSEO, but a workaround was posted involving inserting a line in .htaccess but that no longer seems to work as of DBSEO v1.1.3.
Bug Notification links not going to DBTech user tagging and thanks/like profile tabs
- Status
Actually, I misunderstood the issue. I'm unable to replicate this issue.
Could you please create and PM me with a temporary FTP and AdminCP account?
For security reasons, we recommend you create a new FTP account only for DBTech support, then disable or delete it after we have both confirmed the issue has been solved and there are no further issues.
The same applies to AdminCP accounts; they should ideally be temporary accounts created for us only. If we have created an account on your site already, you can optionally boost that account to Administrator and then de-admin this account once the issue has been solved.
If you use a .htaccess password protection for your AdminCP directory, it is recommended that you create a new authorised user for DBTech and remove this user once the issue has been solved.
Please test any temporary accounts you create to ensure that the FTP account has access to the forum files, and that the AdminCP account can access the administrative controls for the product we are assisting you with.
Ensuring this is all in order before submitting the information will significantly speed up the process of assisting you. We will alert you via PM if there's any issues with the login information you have provided.
When sending the PM, for your security you should also un-tick the "Save a copy in my Sent Items folder" checkbox. When the access details have been received, we will delete the PM from our inbox. Ensuring you have not kept a copy of the PM reduces the risk of security breaches.
Thank you for helping us debug our products and allowing us to assist you, we appreciate it
Could you please create and PM me with a temporary FTP and AdminCP account?
For security reasons, we recommend you create a new FTP account only for DBTech support, then disable or delete it after we have both confirmed the issue has been solved and there are no further issues.
The same applies to AdminCP accounts; they should ideally be temporary accounts created for us only. If we have created an account on your site already, you can optionally boost that account to Administrator and then de-admin this account once the issue has been solved.
If you use a .htaccess password protection for your AdminCP directory, it is recommended that you create a new authorised user for DBTech and remove this user once the issue has been solved.
Please test any temporary accounts you create to ensure that the FTP account has access to the forum files, and that the AdminCP account can access the administrative controls for the product we are assisting you with.
Ensuring this is all in order before submitting the information will significantly speed up the process of assisting you. We will alert you via PM if there's any issues with the login information you have provided.
When sending the PM, for your security you should also un-tick the "Save a copy in my Sent Items folder" checkbox. When the access details have been received, we will delete the PM from our inbox. Ensuring you have not kept a copy of the PM reduces the risk of security breaches.
Thank you for helping us debug our products and allowing us to assist you, we appreciate it
No I do not have php-fpm installed. I run Litespeed web server which normally behaves the same as Apache but in this case apparently not. Any ideas how to fix this please? It is causing a lot of complaints amongst my forum's users. Thank you for any help you can give.
It seems as if Litespeed does not pass PHP files to dbseo.php much in the same way php-fpm does.
Can you try disabling the DBSEO plugin that runs on init_startup and see if that resolves it for you? If so, I will make that code optional so that systems such as yours can choose not to use it
Can you try disabling the DBSEO plugin that runs on init_startup and see if that resolves it for you? If so, I will make that code optional so that systems such as yours can choose not to use it
Yes! That worked. Can I leave that plugin ("Environment Validation") inactive on my live site?
Definitely, it's only used to enforce Canonical URLs before much of vBulletin's code has been ran (to save on performance).
In normal situations, this would be okay. If DBSEO had been allowed to handle .php files' URLs before vBulletin, the URL would have been redirected sooner, and the "tab" param would have been preserved.
Certain configurations, such as PHP-FPM and (evidently) Litespeed, do not support this. The reason why these configurations do not support this, is because they assume that it's okay to pass all URL files directly to the PHP processor, effectively bypassing all configuration options such as .htaccess files.
This is great for performance, as it means your web server doesn't have to examine "index.php" and run through all the steps before finally deciding "yup, that's a PHP file."
Then again, it means that you effectively bypass password protection on AdminCP folders and such things, so it's not ubiquitously a good thing.
In either case, I'll make it so that it runs the full redirect suite rather than simply checking for canonical URL, bypassing this problem entirely. Once the next version has been installed, you should re-enable the plugin for a slight boost in performance. If you choose to leave it disabled, that's fine too, it won't impact the functionality of the mod
In normal situations, this would be okay. If DBSEO had been allowed to handle .php files' URLs before vBulletin, the URL would have been redirected sooner, and the "tab" param would have been preserved.
Certain configurations, such as PHP-FPM and (evidently) Litespeed, do not support this. The reason why these configurations do not support this, is because they assume that it's okay to pass all URL files directly to the PHP processor, effectively bypassing all configuration options such as .htaccess files.
This is great for performance, as it means your web server doesn't have to examine "index.php" and run through all the steps before finally deciding "yup, that's a PHP file."
Then again, it means that you effectively bypass password protection on AdminCP folders and such things, so it's not ubiquitously a good thing.
In either case, I'll make it so that it runs the full redirect suite rather than simply checking for canonical URL, bypassing this problem entirely. Once the next version has been installed, you should re-enable the plugin for a slight boost in performance. If you choose to leave it disabled, that's fine too, it won't impact the functionality of the mod
- Status
Similar threads
- Locked
- Support ticket
- Locked
- Support ticket
- Locked
- Support ticket
- Locked
- Support ticket