Live Update 4.0.1

[Paul B]

That's kind of annoying.

Why?

 

[markku]

Why?

Preface: During writing this post, I found the problem and it was a conflict with another add-on... read on.

Well so far more than a few members have wondered to me why the loading icon pops up at the top right continually when they're posting a new thread. It is indeed visible only for less than a second every 7 seconds (with my update interval of 7 seconds), but the human eye takes note of it regardless.

I don't think it would be necessary to show that loading icon when Live Update polls the server every x seconds. I don't see the value of that, only the possibility of causing confusion.

Besides, why does it only show when creating new threads? But it doesn't show when creating / replying to conversations?
Or when replying using the Quick Reply editor?

Actually, I need to make a little correction here.

The loading icon does not show when I reply to a thread using the More Options... function.

OK! I found the problem.

It's @AndyB's "Similar Threads".

If I go create a new thread, and start writing the content before writing the title, the loading icon does not pop up every 7 sconds.

However, the moment (even if I've already started writing content) I go into the Title field and type in a title (and suggestions for Similar Threads come up), and then go back into the content field, the loading icon starts popping up every 7 seconds.

I'll try disabling Similar Threads and see if I can reproduce this again.

Nope, I can't!

It was enough that I disabled this feature from Similar Threads (after unchecking this, the loading icon does not show up every 7 seconds):


I am sorry for this report @Chris D. Not exactly Live Update's fault. But maybe this helps others who use both Similar Threads and Live Update and have been wondering about the loading icon...

 

[Bonta-kun]

Hello,
I have a problem when I try to uninstall the addon comes the error -

Access denied by security policy
Your request is blocked by a security policy rule.
Please contact the support team, and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
Please provide the following information to our support team: afbe-clan.at | 194.96.113.93 | 22.01.2015 19:28:41

But there is no message in the error log!

 

[Chris D]

That would be some sort of security software on the server side, and not something I can provide support with, unfortunately.

 

[Bonta-kun]

That would be some sort of security software on the server side, and not something I can provide support with, unfortunately.

OK, thanks for info

 

[jeffwidman]

I'm having a weird problem where whenever this addon is active, my Nginx logs are filled with errors of unable to find the favicon:

2015/01/27 13:28:56 [error] 28802#0: *5869 open() "/home/nginx/domains/domain.com/public/forum/threads/thread_title102161/favicon.ico" failed (2: No such file or directory), client: 000.145.107.100, server: domain.com, request: "GET /forum/threads/thread_title.102161/favicon.ico HTTP/1.1", host: "domain.com"

So the client is looking for the favicon at the same url they're visiting... I viewed source, and sure enough, all pages have a favicon reference to "favicon.ico", so that makes sense why the client is just appending favicon.ico to the current url.

So I tried hardcoding the path in the options to "/favicon.ico", which updates the templates to show "/favicon.ico" but my Xenforo install is in /forum/ so that sends clients to domain.com/forum/favicon.ico.

I've got a proper favicon sitting in domain.com/favicon.ico, and the docs say the addon default is to look in the server root.

I thought maybe somehow my themes are screwed up, so I uninstalled and reinstalled the addon to force a template rebuild, and I left the favicon setting as the default. Once again, the html source of all pages shows "favicon.ico" causing clients to look in the relative path for the favicon rather than at the server root.

Is this a bug or am I still missing something?

 

[HWS]

all pages have a favicon reference to "favicon.ico"

If they really have a reference to just "favicon.ico" this error is expected. The reference should be to "/favicon.ico".

 

[Chris D]

That's rather an unusual behaviour.

It's not a bug in the add-on; I've just tested this and cannot reproduce it.

Also, if this relates to your own site, I've just checked and I can't reproduce that there either.

The point to note is the base tag, which correctly states your forum root, vs the favicon which would be relative to your forum root, e.g:

<base href="http://yoursite.com/forum" />
<link rel="shortcut icon" href="favicon.ico" />

Because of the base tag, favicon.ico should resolve to http://yoursite.com/forum/favicon.ico regardless of page URL. And, from what I can see on your site, that is happening.

The only exception, I guess, is if some of your visitors are using a browser that is for some reason ignoring the base tag. though I wouldn't have thought that would be an issue. But, I would say, in any case, it can be safely ignored because it is working as expected.

 

[HWS]

We found the base tag to be VERY unreliable and had (and have) several issues with it since we use XenForo (js/css/etc.).
We even made a suggestion to remove it from XenForo.

It is best to specify the whole path to favicon.ico and your error will be gone.

Drupal 2 years ago decided to move away from using it.
https://www.drupal.org/node/13148

 

[jeffwidman]

I wasn't aware of the base tag, so now I understand why "favicon.ico" should point to /forum/favicon.ico.

There's a couple of funky things going on here:
1) The errors are still appearing in my Nginx logs. I have default Xenforo style and default settings for this addon.
2) The errors disappear whenever this addon is disabled.
3) Enabling this addon adds "favicon.ico" to the html source, but only for registered users. That appears to be the only change that affects favicons.
4) All the IP addresses that cause the favicon 404s are tied to registered users on my forum, likely confirming there's something funky in how this hardcoded "favicon.ico" html link is handled.
5) Not all my active users trigger this error, only some of them.
6) When I change the favicon path in this addon from the blank default to "/forum/favicon.ico", then I stop seeing the errors.

It's a bit difficult to isolate because of all the moving parts here, but I suspect it's a browser bug somewhere that only triggers when there's a hardcoded reference to "favicon.ico" in the html source and then doesn't handle the paths quite right...

When I migrated to Xenforo, I also moved from www.domain.com to domain.com, so there's a small chance my Nginx rewrite rules stripping the "www" from all urls may cause issies if an old browser is specifically requesting www.domain.com/favicon.ico

Perhaps if the admin hasn't specified a custom favicon link, then this addon shouldn't add a specific favicon link to the html source? Might be a workaround.

Or could just ignore this unless someone else reports issues. The "/forum/favicon.ico" path is working for me.

 

[Xon]

The only exception, I guess, is if some of your visitors are using a browser that is for some reason ignoring the base tag. though I wouldn't have thought that would be an issue. But, I would say, in any case, it can be safely ignored because it is working as expected.

I've noticed some versions of Opera are particularly bad with ignoring the base tag.

 

[giorgino]

I'm having a weird problem
The live notification don't appear to administrators ONLY
All the other users receive the live notification normally.

I'm using Firefox, Chrome, Opera and Safari all last versions

What's wrong?
What can I check to debug this?

 

[Mouth]

OK! I found the problem.
It's @AndyB's "Similar Threads".
If I go create a new thread, and start writing the content before writing the title, the loading icon does not pop up every 7 sconds.

I'm using Similar Threads, and also his Tab Alerts add-on, and not experiencing the same issue.

 

[Chris D]

If you can send me login details for an admin account I'll check it out.

 

[giorgino]

If you can send me login details for an admin account I'll check it out.

Thank you again @Chris D for supporting me, as you know my issue was the option template modification disabled.
I disabled it to "clean" and simplify the user preferences (my users aren't web or forum geeks).

What happened to my account with the option template modification disables is that changing one preference in preferences page, the live update display option is reset to "Disable".

But I've the same setting it in other four boards, without this behavior.

In your opinion was a single combination or it's a normal behavior and in this case, why this behavior don't appear in the other boards? (same addon, preferences, etc)?

 

[Marcus]

I got this in acp> error log

Zend_Db_Adapter_Mysqli_Exception: php_network_getaddresses: getaddrinfo failed: Name or service not known - library/Zend/Db/Adapter/Mysqli.php:333


#0 library/Zend/Db/Adapter/Abstract.php(315): Zend_Db_Adapter_Mysqli->_connect()
#1 library/XenForo/Application.php(727): Zend_Db_Adapter_Abstract->getConnection()
#2 [internal function]: XenForo_Application->loadDb(Object(Zend_Config))
#3 library/XenForo/Application.php(970): call_user_func_array(Array, Array)
#4 library/XenForo/Application.php(1001): XenForo_Application->lazyLoad('db', NULL)
#5 library/XenForo/Application.php(1571): XenForo_Application::get('db')
#6 library/XenForo/Session.php(236): XenForo_Application::getDb()
#7 library/XenForo/Session.php(323): XenForo_Session->__construct()
#8 library/XenForo/Session.php(257): XenForo_Session::getPublicSession(Object(Zend_Controller_Request_Http))
#9 library/XenForo/Controller.php(291): XenForo_Session::startPublicSession(Object(Zend_Controller_Request_Http))
#10 library/XenForo/Controller.php(304): XenForo_Controller->_setupSession('Index')
#11 library/XenForo/FrontController.php(346): XenForo_Controller->preDispatch('Index', 'LiveUpdate_Cont...')
#12 library/XenForo/FrontController.php(134): XenForo_FrontController->dispatch(Object(XenForo_RouteMatch))
#13 index.php(13): XenForo_FrontController->run()
#14 {main}

array(3) {
["url"] => string(49) "http://domain.com/index.php?liveupdate"
["_GET"] => array(1) {
["liveupdate"] => string(0) ""
}
["_POST"] => array(4) {
["_xfRequestUri"] => string(1) "/"
["_xfNoRedirect"] => string(1) "1"
["_xfToken"] => string(8) "********"
["_xfResponseType"] => string(4) "json"
}
}

 

[Chris D]

Probably not directly related to my add-on.

It's failing on some code that my add-on doesn't even run, itself.

 

[Marcus]

Thanks for your quick reply!

 

[Xon]

@Marcus That is XenForo failing to connect to MySQL due to DNS failure.

 

[Marcus]

Thanks for your explanation, this is such a nice community.