This happened to me on upgrade as well. I did intentionally turn on error display for trouble shooting some other modules.
Although it is correct that turning off errors will "fix" the problem, it seems like the correct solution would be to have line 87 of /engine/lib/languages.php changed to:
if ((!$language) && (isset($CONFIG->language)) && ($CONFIG->language))
This would eliminate the generation of the notice and the isset() call would be consistant with other lines of code in the same file. For example line 31 and 114.
Just my two cents worth...
Exactly, Dustin.
It says something is wrong, or not good at least. Turning the notifications off is a workaround like plugging your ears or turning on the radio when your car makes strange sounds.
I think that the better way is to chage the script in "/engine/lib/languages.php".
Line 87
From
if ((!$language) && (isset($CONFIG->language)) && ($CONFIG->language))
To
if ((!$language) && (isset($CONFIG->language)) && ($CONFIG->language))
According to the PHP documentation "The + operator appends elements of remaining keys from the right handed array to the left handed, whereas duplicated keys are NOT overwritten." Both + and += map to the same function add_function() which calls a hash merge function with the override parameter set to off.
If language file loading is a significant part of the page load time, it would seem that caching the results would be very useful.
Just found this description of the problem, in which the issue is traced to an ambiguity in the HTML spec rather than a definite Firefox bug:
http://weblog.200ok.com.au/2008/01/dashing-into-trouble-why-html-comments.html
I do think that the Elgg source needs to be careful to delete HTML code that may contain user generated content rather than simply commenting it out.
After all, the content *could* have contained the string "-->" which then would have broken the layout in any browser.
This happened to me on upgrade as well. I did intentionally turn on error display for trouble shooting some other modules.
Although it is correct that turning off errors will "fix" the problem, it seems like the correct solution would be to have line 87 of /engine/lib/languages.php changed to:
if ((!$language) && (isset($CONFIG->language)) && ($CONFIG->language))
This would eliminate the generation of the notice and the isset() call would be consistant with other lines of code in the same file. For example line 31 and 114.
Just my two cents worth...
Exactly, Dustin.
It says something is wrong, or not good at least. Turning the notifications off is a workaround like plugging your ears or turning on the radio when your car makes strange sounds.
I think that the better way is to chage the script in "/engine/lib/languages.php".
Line 87
From
if ((!$language) && (isset($CONFIG->language)) && ($CONFIG->language))
To
if ((!$language) && (isset($CONFIG->language)) && ($CONFIG->language))
This happened to me on upgrade as well. I did intentionally turn on error display for trouble shooting some other modules.
Although it is correct that turning off errors will "fix" the problem, it seems like the correct solution would be to have line 87 of /engine/lib/languages.php changed to:
if ((!$language) && (isset($CONFIG->language)) && ($CONFIG->language))
This would eliminate the generation of the notice and the isset() call would be consistant with other lines of code in the same file. For example line 31 and 114.
Just my two cents worth...
Exactly, Dustin.
It says something is wrong, or not good at least. Turning the notifications off is a workaround like plugging your ears or turning on the radio when your car makes strange sounds.
I think that the better way is to chage the script in "/engine/lib/languages.php".
Line 87
From
if ((!$language) && (isset($CONFIG->language)) && ($CONFIG->language))
To
if ((!$language) && (isset($CONFIG->language)) && ($CONFIG->language))
Just found this description of the problem, in which the issue is traced to an ambiguity in the HTML spec rather than a definite Firefox bug:
http://weblog.200ok.com.au/2008/01/dashing-into-trouble-why-html-comments.html
I do think that the Elgg source needs to be careful to delete HTML code that may contain user generated content rather than simply commenting it out.
After all, the content *could* have contained the string "-->" which then would have broken the layout in any browser.
@ Chalkiex
I've found mention of a different solution here:
http://priit.pudisoo.com/2009/03/elgg-15-and-missing-message-board/
However, I still can't reduce the size of the input box even with that suggestion.
Let me know if you find a solution
Thanks,
Ugo
Hi Ugo! How did you squeeze the message box back into the right space?
Thanks!
Sean
Just found this description of the problem, in which the issue is traced to an ambiguity in the HTML spec rather than a definite Firefox bug:
http://weblog.200ok.com.au/2008/01/dashing-into-trouble-why-html-comments.html
I do think that the Elgg source needs to be careful to delete HTML code that may contain user generated content rather than simply commenting it out.
After all, the content *could* have contained the string "-->" which then would have broken the layout in any browser.
info@elgg.org
Security issues should be reported to security@elgg.org!
©2014 the Elgg Foundation
Elgg is a registered trademark of Thematic Networks.
Cover image by Raül Utrera is used under Creative Commons license.
Icons by Flaticon and FontAwesome.