Recently, I upgraded to 1.9.x, and also added the Semantic MediaWiki
Extension.
Now, I have all tables that were marked as sortable have two sets of sorting
buttons for each header cell.
Reference: http://simopedia.servopro.com/wiki/Template:TV_Channel_Reactions
I thought that it might be because there are now two sorttable.js scripts,
one for MediaWiki, and one for Semantic, but when I commented out all the
lines in the MediaWiki skins/common/sorttable.js, there were no buttons
left.
Can anyone help? Thanks.
Hi, I installed mediawiki 1.9.2 in debian with no errors during
setup. It works all fine, except that it's not displaying correctly
in firefox, I see no images at all, just text. But if I browse the
site with Opera or Explorer, I see it all fine.
I even tried all included skins and there are problems with all of
them, but again only with firefox(Linux, Mac, Windows).
Any idea about how to solve it?
Omar Armas
Oficina: +52 55 56044655
Movil: 04455 1867 8953
oarmas(a)mpsnet.net.mx
Hi,
I'm having some nasty trouble with charsets. Consider the wiki_categorylinks
table.
It's shown correctly in phpMyAdmin, which displays utf8 pages (at least all
german umlauts look well when I select utf8 in my browser). Mysqldumping this
works fine, I get an correct utf8 file. Importing this again works fine if I
select utf8 encoded file.
But the wiki keeps displaying screwed umlauts, like "ä" or "ä" instead
of "ä", depending on which encoding I chose in my browser, but no encoding
seems to work fine.
Setting $wgDBmysql5 to true in LocalSettings.php doesn't help.
I also noticed that the browser seems to reload the page when I change
encodings (both Iceweasel and konqueror do so). Does the wiki figure out
which encoding the browser expects and changes it accordingly (screws it in
my case)?
The funny thing is that I got a second version of this wiki on the same
server, in which all is displayed ok. I noticed the described behaviour as I
tried to backup the thing. In the working version, the umlauts look bad in
phpMyAdmin and in the dumps, but well in the wiki. If I import such a bad
looking dump, it starts looking bad in the wiki as well.
I can convert these dumps to valid uft-8 displaying umlauts correctly by doing
$ iconv -t latin1 -f utf-8 -c wiki_categorylinks.sql -o bar
$ file bar
bar: UTF-8 Unicode text
MediaWiki: 1.5.8 (I know it's too old)
PHP: 5.2.1 (cgi-fcgi)
MySQL: 5.0.27-max-log
working version: http://www.karba.ch/mowiki/Kategorie:Chinesisch
screwed version: http://www.heelhook.de/mowiki/Kategorie:Chinesisch
Any help is apreciated!
- Mo
Greets!
I'm hoping this is the correct list to post to.
I've installed the version 1.6x mediawiki through my cpanel, and
everything works great. I've gotten everything to work except for a couple
of nits.
I switched the skins to cologneblue and have modified what I was able to,
but the quickbar is beyond my understanding.
I do not want to display edit information to anonymous users.
I've set the code to do this and it works great except on the main page,
where a good deal of unwanted information displays.
If you try to log in, you will see how I want the information on the side
to be displayed ... very little... just a search bar.
I'd prefer to also have all special page information except new pages hidden.
http://www.primalfire.com/wiki/
Your aid is requested and greatly appreciated.
Thank you.
Primal
We have a mediawiki install of:
- MediaWiki <http://www.mediawiki.org/>: 1.8.2
- PHP <http://www.php.net/>: 5.1.4 (apache2handler)
- MySQL <http://www.mysql.com/>: 4.1.12
Our users get confused when accidentally clicking on an image in an article.
Is there a setting to turn off links to images within articles?
TIA.
Andy
Hello all,
I'm struggling with an odd CSS issue (MonoBook skin) that I can neither
understand nor solve (and neither could some CSS guys I've asked, as
they weren't familiar enough with MonoBook).
This CSS rule set (stripped of irrelevant color declarations*):
.editsection {
position: relative;
top: 1em;
padding: 0.1em 0.2em 0.1em 0.2em;
}
leads to the following result:
http://tinyurl.com/25esk3 (sorry for TinyURL, but the original URL
was too long: http://www.onlinestuffs.com/pictureupload/bild14/od6mx
3rs00vzyg8w2cb7.png)
While I understand that relative positioning can create unexpected
results sometimes, the positioning here should simply be relative to the
respective heading's position!? So I don't see what could possibly cause
this inconsistency...
Does anyone happen to have an idea?
Thanks,
Frederik
* those were:
border: 1px solid #AAAAAA;
background-color: #E7E7E7;
Hi,
I want to add an additional window below the toolbox which should include a
few external links. It should be visible an all pages.
How can this be done on Mediawiki 1.9.2?
Thanks, zaydo
--
View this message in context: http://www.nabble.com/Window-in-Sidebar-below-Toolbox-tf3245059.html#a90206…
Sent from the WikiMedia General mailing list archive at Nabble.com.
Wikipedia has hundreds of wonderful portals on every imaginable topic.
These are perhaps one of the most underexposed treasures on the site.
It would be lovely if people could subscribe to a portal feed, or
individual "boxes" (typical portal arrangement is into rectangles with
different content). Example:
http://en.wikipedia.org/wiki/Portal:Free_software
How could this be achieved? One way would be to support an RSS
extension that would operate as follows:
1) You put something like
<makefeed>
title=Selected article on free software
addto=freesoftware.xml
addto=freesoftware-sel.xml
</makefeed>
<feedicon>
feed=freesoftware-sel.xml
</feedicon>
inside a template, or indeed any page.
2) When a user edits a page, the extension checks for the presence of
<makefeed> in the wikitext. If it is present, it adds a
( ) Add as new item to RSS feed
( ) Update most recent RSS feed item for this page
(x) no change
selection to the page, below where the minor edit checkbox is. This
selection should only be available to users with a definable
permission level (e.g. autoconfirmed).
3) The feeds could be directly updated/written on the disk, in the
images/ directory. In any case, the <feedicon> tag would generate a
pretty link to a feed with a given name.
The feed content would be the action=render output for the page where
the <makefeed> instruction is found (ideally sans noinclude). It could
also include the edit summary.
Given that a feed could be accessed from multiple pages, you could
build aggregated feeds (in the above example, freesoftware.xml would
be a feed for the whole free software portal) and individual ones
(freesoftware-sel.xml would only be the selected article box). You'd
have to do some clever scanning of the file on disk to make safe
updates, but it shouldn't be too hard.
Any conceptual flaws? Any takers? I think this could really make a big
difference for content re-use, not just in the context of Wikipedia.
But the portals seem like a particularly attractive target application
to me.
--
Peace & Love,
Erik
DISCLAIMER: This message does not represent an official position of
the Wikimedia Foundation or its Board of Trustees.
"An old, rigid civilization is reluctantly dying. Something new, open,
free and exciting is waking up." -- Ming the Mechanic