Issues with the Wiki

From ThinkWiki
Revision as of 02:14, 20 October 2007 by Hmh (Talk | contribs) (Borkage in Language.php)
Jump to: navigation, search

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.

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)

JavaScript and CSS

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

/usr/bin/convert

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)


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)

Can not upload SVG

I get the upload warning:
".svg" is not a recommended image file format.
Matt 14:02, 3 December 2006 (CET)

Is there a way to contact a registered user, for example to confirm information. I have found that AdamZ claims that the X20 is bootable via USB. My information indicates the contrary. Isn't there a way to contact a registered user through MediaWiki? --Rolf 00:30, 9 September 2006 (CEST)

php error encountered when attempting to update Bios Upgrade page:

Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 133781 bytes) in /home/akw/htdocs/thinkwiki.org/mediawiki-1.5.6/includes/MagicWord.php on line 250

--roadends 02:30, 20 March 2006 (EDT)


--Tonko 03:40, 11 March 2006 (CET)


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)


I have just got a MySQL problem when I edited a page, a query was not to its liking. It is quite easy to reproduce, just edit any page ;-)

History did get updated, and the page was also updated, so I have no idea what broke when that query failed.

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:
(SQL query hidden)
from within function "SearchMySQL4::update". MySQL returned error "1062: Duplicate entry ' ' for key 3 (localhost)".

hmh 2006-02-17, 20:12 UTC


More database problems, this time the search function:

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:
(SQL query hidden)
from within function "". MySQL returned error "145: Table './thinkwiki/searchindex' is marked as crashed and should be repaired (localhost)".

hmh 2006-02-21, 15:07 UTC


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)


Search still seems broken, searching for DVI brings up nothing. --Jumpfroggy 00:03, 17 March 2006 (CET)


Error creating thumbnail: /home/thinkwiki/htdocs/mediawiki-1.10.0/bin/ulimit4.sh: line 4: /usr/bin/convert: No such file or directory


"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


Confirmation E-mail

It just don't work. It neither is in my spam dir nor works with any other address. Tried multiple times, waited hours, days, weeks... gave up and wrote this here...

--BDKMPSS 29 July 2007

The E-Mail confirmation feature works now

--BDKMPSS 10 October 2007


Troubles confirmed

(update 2007-03-24: this page is not listed in the special pages category anymore, so the bug is now worked around).

Fixed problems

  • http://thinkwiki.org/ reverted again to the default MediaWiki theme. Cannot reproduce this one (15.01.06, akw)
  • File upload is disabled - Argh. Fixed (15.01.06, akw)
  • URL contains index.php(/) before the actual page name - This has been fixed (28.05.05, akw)
  • The categories page doesn't link to Category:ThinkWiki - Fixed (29.05.05, akw)
  • http://thinkwiki.org/ is broken (no www prefix), this was working before - Fixed (29.05.05, akw)
  • On logging in a requester pops up asking to confirm a password change - seems like it's implicitly been fixed (29.05.2005, wyrfel)
  • In Navigation bar, "&lt;download&gt;" leads to [1] - fixed (30.06.2005)
  • direct link to Category:Models missing in Navigation Fixed (10.07.05, akw)
  • It seems the Wiki has trouble updating the edit history, i'm getting mysql query errors on saving pages. The pages get saved, however. Fixed (12.05.2005)