I have possibly found a bug in this addon. Although it could be related to Widget Framework.
Undefined property: XenForo_ControllerResponse_Redirect::$params
XenForo_Application::handlePhpError() in ForceStyleOnPrefix/ControllerPublic/Thread.php at line 9
ForceStyleOnPrefix_ControllerPublic_Thread->actionIndex() in XenForo/FrontController.php at line 310
XenForo_FrontController->dispatch() in XenForo/FrontController.php at line 132
XenForo_FrontController->run() in C:/Winginx/home/xen/index.php at line 13
This error occured as follows:
I have the recent threads widget of widget framework. It shows recent X threads. One of the threads has a prefix. I moved this thread to a forum with no prefixes. Thread has been moved successfully and of course the prefix disappeared. But now the thread is displayed twice in the recent threads widget. The first is the thread from the original location and the second is the thread moved to a different location. The second link works with no issues. The first however brings me to the above error message. If I disable the Force Style on Prefix addon, the first link works. I enable it and again the error message above occurs if I click the first link.
So actually there are two issues. Duplicated threads in the recent thread widget if a thread is moved and the above error message. I have forwarded xfrocks to this post for the duplicated thread issue.
Edit: oops, I missed a line from the error message. Have added it now.
Yeah, the duplicated thread issue occurs when a redirect is created. Redirects are created as new threads with their own thread ID so the recent threads block shouldn't pull these. It's either that or the widget cache. I'm sure xfrocks will fix this up.
I will do some testing with regards to this add-on and thread redirects, though.
While this is true, the Node's override style is ignored even if the Thread Prefix does not have an override style selected. This means that the member will see the thread in whichever style they have selected instead of the style we want them to see in that particular Node. Any threads without prefixes are displayed with the Node's override style so that's not the issue. It appears that adding a prefix switches off the Node's override style without checking whether the prefix will force one or not.
If I switch off the add-on everything works as expected.