Hard Light Productions Forums
Site Management => Site Support / Feedback => Topic started by: Yarn on January 16, 2012, 06:07:28 pm
-
As the title says, the sidebar appears at the bottom of the page instead of the top when I view the wiki in Firefox 9. This does not happen in Internet Explorer 9. I have not tested it with other browsers.
Also, visited links in the wiki have the same color as the regular text, making it impossible to tell them apart. I suggest changing the color of visited links so they're distinguished from normal text.
-
I have the sidebar issue as well, since upgrading to FF9. Not sure if it's a bug in FF or something that needs to be fixed Wiki-side.
And yeah, the visited links being indiscernible are a minor annoyance as well, that's been around for a long time.
-
As the title says, the sidebar appears at the bottom of the page instead of the top when I view the wiki in Firefox 9. This does not happen in Internet Explorer 9. I have not tested it with other browsers.
you're not the only one. :(
Also, visited links in the wiki have the same color as the regular text, making it impossible to tell them apart. I suggest changing the color of visited links so they're distinguished from normal text.
is there any way to change this?
-
This is apparently a bug in Firefox (https://bugzilla.wikimedia.org/show_bug.cgi?id=31807).
There is a workaround on the mediawiki side, but it requires modifying a file on the backend and potentially breaking it for other browsers (potentially Konqueror).
Best workaround I've found is to use Adblock (or something that can block elements on a web page) to block */monobook/KHTMLFixes.css.
-
Best workaround I've found is to use Adblock (or something that can block elements on a web page) to block */monobook/KHTMLFixes.css.
That worked, but only after changing the filter to /KHTMLFixes.css.
I still believe the visited-link color should be something other than white. Yellow, maybe?
-
Doesn't the bug report say that upgrading mediawiki to version 1.16 (or greater?) will fix the issue - and that it was caused by some dodgey browser detection being done by mediawiki? We're running 1.15.5 (http://www.hard-light.net/wiki/config/index.php). Latest is 1.18.1 (http://www.mediawiki.org/wiki/Download) ;)
-
Doesn't the bug report say that upgrading mediawiki to version 1.16 (or greater?) will fix the issue - and that it was caused by some dodgey browser detection being done by mediawiki? We're running 1.15.5 (http://www.hard-light.net/wiki/config/index.php). Latest is 1.18.1 (http://www.mediawiki.org/wiki/Download) ;)
It does. However, manually upgrading isn't a simple case of drop it in and go. As things are now, if there are security patches and such, they are backported to the current package install. Doing a manual upgrade would entail a bit of work and then it would be one more thing to have to keep an eye on and maintain.
A backport repo might be around somewhere, but then we would have to be dependent on another group/party to maintain that package. It's a nasty circle, it is.
-
ah yes, the curse of linux package management, I'm very familiar with this particular conundrum :) At work when in this situation we tend to build our own RPMs from source (with a borrowed spec file), but you don't want to have to do that for a lot of packages, and even less so when it's your own time!