Live Content

Live Content [Paid] 1.2.3

No permission to buy ($25.00)
Error when visiting a thread on XF 2.2.0 Beta 3.

Code:
Error: Call to a member function toArray() on array src/addons/UW/FCS/Extend/Pub/Controller/Thread.php:70
Generated by: Admin Aug 18, 2020 at 1:35 AM
Stack trace
#0 src/addons/XenConcept/HideBBCode/XF/Pub/Controller/Thread.php(21): UW\FCS\Extend\Pub\Controller\Thread->actionIndex()
#1 src/addons/XFMG/XF/Pub/Controller/Thread.php(11): XenConcept\HideBBCode\XF\Pub\Controller\Thread->actionIndex()
#2 src/addons/SV/LiveContent/XF/Pub/Controller/Thread.php(37): XFMG\XF\Pub\Controller\Thread->actionIndex()
#3 src/XF/Mvc/Dispatcher.php(350): SV\LiveContent\XF\Pub\Controller\Thread->actionIndex()
#4 src/XF/Mvc/Dispatcher.php(257): XF\Mvc\Dispatcher->dispatchClass()
#5 src/XF/Mvc/Dispatcher.php(113): XF\Mvc\Dispatcher->dispatchFromMatch()
#6 src/XF/Mvc/Dispatcher.php(55): XF\Mvc\Dispatcher->dispatchLoop()
#7 src/XF/App.php(2298): XF\Mvc\Dispatcher->run()
#8 src/XF.php(459): XF\App->run()
#9 index.php(20): XF::runApp()
#10 {main}
 
@rdn that is actually an add-on compatibility issue by UW/FCS or XenConcept/HideBBCode, not this add-on.

This add-on doesn't replace any of the existing fields that is outputted by XenForo.
 
  • Love
Reactions: rdn
+1 for waiting for fix to move 2.2.1. Users have expressed their appreciation for this add-on so I'll continue to wait.
 
unclear -- can this be toggled on a per-thread basis? i.e., not a global setting across all threads

Also waiting for clarification on this.

Yes it does work and yes it does
If I remember right there is an SQL run you have to do to activate the single live thread feature but yes that is the option

There's a feature release that makes reference to 'Enable per-thread live status for all forums' here by an SQL...

But I don't quite understand. We'd only want selected stickied threads to be 'live'
 
Temporary hacky workaround for anyone else who doesn't like that scrolling when an update comes in and is willing to "void their warranty", so to speak - an edit to js/sv/livecontent/discussion.min.js will remove it. In version 1.1, this is what needs to be removed:
JavaScript:
b=c[0].getBoundingClientRect().top;f>=b&&(b=c.outerHeight(),f&&b&&a(e).scrollTop(f+
b));
Yes, the newline in the above code snippet is deliberate; that's how it appears in the file. Be very very careful and make a backup of the file first, 'cause mistakes will break your add-on. And it should go without saying that seeking official support from @Xon after attempting this edit would be in extraordinarily poor taste. ;) If you have any doubts at all, I strongly recommend leaving it be. (I just happen to do some minor Javascript development on the side, so I felt up to it.)

In the meantime, I'm hoping Xon will soon have the opportunity to make turning that off an officially supported option. (And while I'm here - thanks a ton for providing this add-on in the first place!)
Hack workaround for v1.2.2 (yes, we're still getting this issue on my forum) - remove the following:
JavaScript:
b=a[0].getBoundingClientRect().top;f>=b&&(b=a.outerHeight(),
f&&b&&d(k).scrollTop(f+b));
See quoted post in re: disclaimers w/r/t caution and not harassing @Xon if you try this and it breaks.

(Speaking of harassment... hey, Xon, could this possibly be a preference flag controlled thing? I've gotten the impression from my users that the scrolling behavior is considered entirely unwelcome even if it was working as intended.)
 
Top Bottom