Issues with the Wiki
This page is a provisorium. It's a list of things that are going wrong after the update to help Akw track and fix them.
Contents
- 1 Suggestions and requests
- 2 Troubles encountered
- 2.1 Problems with Language.php
- 2.2 Problem with cmdroot
- 2.3 Can not open page to edit without introducing modifications
- 2.4 Uploading SVG files
- 2.5 SpamBlackList not working
- 2.6 Multiline cmdresult template
- 2.7 Server time out-of-sync
- 2.8 Missing imagemagick on server
- 2.9 Your signature with timestamp button
- 2.10 Problem with the feeds (RSS and Atom)
- 2.11 Search is broken
- 3 Problems fixed
Suggestions and requests
Enable users to cite references
Thinkwiki would look cleaner and neater if an article were able to cite its references and track them in one place, rather than having external links strewn throughout the article.
Enabling the <ref> and <references> tag, provided by the Cite Mediawiki extension would allow users to cite their references. Estimated amount of work to include this plugin: < 1 hour.
Enabling user Javascript and CSS for MediaWiki
Could ThinkWiki's MediaWiki installation get these options enabled (typically set in LocalSettings.php):
These options allow users to have their own custom Javascript and CSS. I (and others) like to have our own custom themes and Javascript when working with MediaWiki-powered websites.
--SamatJain 22:04, 28 July 2007 (UTC)
This is a great security risk. What is it good for?
--Thinker 00:14, 29 July 2007 (UTC)
It allowers users to set their own customizations via Javascript and CSS. It's a minor security risk which is why MediaWiki ships with it off, but Wikipedia and other popular websites using MediaWiki ship with it on.
--SamatJain 20:49, 29 July 2007 (UTC)
There is nothing minor about it. The web security model is site-wise when dealing with MediaWiki, there is no easy (read: manageable) way for an user, even one that uses NoScript+Firefox or something else equally powerful, to really filter out trusted from untrusted content when you start allowing people to write JavaScript into a Wiki.
CSS is less of a problem, but it could still hork the site if one is not careful, and MediaWiki already allows us to change the pages well enough. If you need to change thinkwiki CSS for your own viewing pleasure, any browser worth its bytes lets you layer your own CSS on top of a site's. I would not be strongly against enabling CSS, but I don't see any reason to do it, either.
JavaScript submissions, OTOH, is something that must remain disabled. IMO, if you really can't survive without tacking different JavaScript code than what thinkwiki already has, you can use greasemonkey or some other such system to do it in your own browser.
If thinkwiki starts allowing users to set javascript on their pages, I would have to block javascript completely on my side, for example. At that time, it is likely I will just go away. Other contributors might feel the same. It is not that I have anything against JavaScript. It is the fact that I cannot *trust* user-submitted JavaScript.
--hmh 12:26, 30 July 2007 (UTC)
These options only enable Javascript and CSS for user pages, i.e. for User:User/Monobook.css and User/Monobook.js, specifically not for other pages. Disabling these options was done by default as a precaution against XSS vulnerabilies long since been fixed. Unfortunately, while I agree with you about disabling user Javascript as a precaution, I do not think the wgAllowUserCss option has any effect unless the wgAllowUserJs option is enabled as well.
--SamatJain 18:52, 30 July 2007 (UTC)
I don't get the point ether. Why you want to use css/javascript on user pages? You always say why you think its no problem, but not what you want to do. If you need some funky looking stuff or buttons there you should use something like myspace. This Wikis (and almost all other) purpose is collecting the main - Thinkpad - content, not something cool/funky/special on userpages
As Hmh, I would block js immediately and may leave the site, even if its only on userpages, because I don't want to mind clicking "the false links"
--BDKMPSS, 30 July 2007
Wikipedia's section on MediaWiki customization describes some of the extensions and addons available. For example, wikiEd is a WYSIWYG editor such that instead of having to remember MediaWiki's markup, they use an editor that's only enabled for use them. This kind of extending is difficult to do with Stylish or Greasemonkey.
I'll repeat, since I've not been apparently misunderstood:
- Users won't be able to add Javascript or CSS to arbitrary pages, only those under their user profile (these are called "user pages")
- Only those users logged in will see these their own changes, no other users will.
Given these things, I don't understand why people need to threaten they're going to stop contributing to ThinkWiki? There isn't a way you're going to turn ThinkWiki into MySpace. If you don't use specifically use any CSS or Javascript through these features, it will not effect you at all.
What I personally want to do, I want to use a MediaWiki modification I wrote, Nullbook. I feel as if I am much more efficient with this theme.
--SamatJain 21:58, 30 July 2007 (UTC)
I don't understand what exactly $wgAllowUserJs is supposed to do, and its documentation is worthless. The crux of the matter is this: if those features are enabled, is there any way you can cause me to execute JavaScript (or apply CSS) that you wrote, in any page on ThinkWiki? If not, why?
--Thinker 22:17, 30 July 2007 (UTC)
User styles on the MediaWiki site describes a bit more how these options work and what is provided to any modification that depends upon them. Unless there exist security-related bugs (which is the reason these features are tagged possible security risks, and why they are proactively disabled by default), by design, no, there is no way that I can cause you to execute Javascript or apply CSS that I had put into one of my own "user pages" (i.e. those under User:SamatJain).
--SamatJain 22:53, 30 July 2007 (UTC)
If and only if such javascript and css changes are limited so that the user who made them is the only one who gets them, then I have nothing against it.
That said, I'd prefer if the relevant mediawiki code was audited a bit before it is enabled.
PS: Whomever is doing it, please stop screwing around with the formatting: there must be one empty line before and after signatures, it makes the dialog a lot more readable.
--hmh 02:53, 1 August 2007 (UTC)
Troubles encountered
Problems with Language.php
Some pages are not happy with mediawiki 1.11.0, and return:
Warning: array_slice() [function.array-slice]: The first argument should be an array in /home/thinkwiki/htdocs/mediawiki-1.11.0/languages/Language.php on line 1153
For an example, see: Akw's user page
--hmh 01:14, 20 October 2007 (UTC)
Problem with cmdroot
Following String is not handled correct by template cmdroot: "fakeroot make-kpkg --initrd --revision=thinkpad.1.0 kernel_image"
see here:
# {{{1}}}
Can not open page to edit without introducing modifications
If I open the X31 model page and without touching anything I hit preview, the div token is decomposed and appears in the preview page, and of course, the photo is not in the right place.
--Ungoliant 19:24, 20 February 2007 (CET)
Uploading SVG files
Can not upload SVG
I get the upload warning: ".svg" is not a recommended image file format.
--Matt 14:02, 3 December 2006 (CET)
SpamBlackList not working
- ThinkWiki:SpamBlackList does not appear to work anymore
--Tonko 03:40, 11 March 2006 (CET)
Multiline cmdresult template
You can't (easliy do a multiline cmdresult
, can you? See:
foo
bar
baz
or
foo
bar (after whitespace)
baz (after whitespace)
This works (but is not so nice)
foo
bar (after empty line)
baz (after empty line)
Any suggestions?
--Paul Bolle 10:27, 24 January 2006 (CET)
I think the best way is to use single cmdresult calls for each line and prefix them with a colon. Like so:
:{{cmdresult|foo}} :{{cmdresult|bar}} :{{cmdresult|baz}}
, which results in
foo
bar
baz
Alternatively, you can use <br /> at the ende of each line within one call, like this: {{cmdresult|foo<br /> bar<br /> baz}} , which will result in
foo
bar
baz
--Wyrfel 12:13, 24 January 2006 (CET)
Server time out-of-sync
The server time would appear to be off a lot, is it possible to setup ntpd, or to run ntpdate every hour or so using cron?
--Tonko 05:11, 22 February 2006 (CET)
Missing imagemagick on server
Error creating thumbnail: /home/thinkwiki/htdocs/mediawiki-1.10.0/bin/ulimit4.sh: line 4: /usr/bin/convert: No such file or directory
I think the computer this wiki is running on is missing the imagemagick software tools especially convert to create thumbnails of images
--Markusw 10:21, 26 August 2007 (UTC)
Your signature with timestamp button
This Button simply doesn't work, it adds --~~~~
I think its a bunch on javascript so I may add:
I use Firefox (branded as Icewasel) on Debian Testing
Preferences:
Raw signatures (without automatic link) OFF
Show edit toolbar (JavaScript) ON
(Oh... Yes its javascript)
EDIT: Even in my Windows XP SP2 Virtual Machine it don't work in Internet Explorer 7.0
--BDKMPSS 29 July 2007
I have been using this button for quite a while now, and it seems to work just fine. It does insert --~~~, but upon submitting previews or saving the page, it gets converted into my signature.
--hmh 01:27, 20 October 2007 (UTC)
hm... (wow a nice joke...)
lets try this
--BDKMPSS 00:30, 21 October 2007 (UTC)
OK, its all fine... I'm sorry but this seems to be extremely non-intuitive...
--BDKMPSS 00:32, 21 October 2007 (UTC)
Yeah, intuitive it ain't...
--hmh 00:43, 22 October 2007 (UTC)
Problem with the feeds (RSS and Atom)
The feed does not validate, and thus not load in Firefox or Liferea.
The problem is, that there is a trailing newline before <?xml version="1.0" encoding="utf-8"?> which is not allowed
--Zhenech 12:14, 11 December 2007 (UTC)
Search is broken
The search feature is completely borked: every query I try returns zero results.
--RichardNeill 02:16, 13 January 2008 (CET)
They work just fine here, through Google (the search box launches a Google search, and returns it in a ThinkWiki-style page).
Check your browser "defense" settings, you may be blocking too much.
--hmh 04:23, 13 January 2008 (CET)
Problems fixed
- List emptied, since everything in it was more than one year old