Return of the Wiki
#1
After a few days off, the AssaultCube Wiki is back to life. There are still a few minor issues to iron-out, but it seems to working smoothly. Let me know if you spot any problems that are less than obvious.
Sorry for the delay.
Thanks given by:
#2
Thanks given by:
#3
I'm surprised that there isn't more people telling jamz how sexy he is.
Thanks given by:
#4
Does it really need to be verbalized?
Thanks given by:
#5
Yes, yes it does.
Thanks given by:
#6
It's nice that people have these feelings towards me, but the truth is I still don't have a clue what I'm doing. XRD has pointed out the errors on the main page alone, and I am at a loss how to correct them. If there are any MediaWiki experts willing to help, please drop me a line.
In this masterful artwork drawn by him:
  • Languages 'B' should be aligned across the page under tabs 'A'.
  • The three [edit] links 'C' should be in position 'D'.
  • Section 'E' should be a footer running across the bottom of the page
Thanks given by:
#7
Two stylesheets and two scripts don't load because they're declared with two forward slashes at the beginning of the URL, which browsers can't handle:
http://wiki.cubers.net/:13  GET http://load.php/?debug=false&lang=en&modules=mediawiki.legacy.commonPrint%2Cshared&only=styles&skin=monobook&*
http://wiki.cubers.net/:18  GET http://load.php/?debug=false&lang=en&modules=site&only=styles&skin=monobook&*
http://wiki.cubers.net/:174 GET http://load.php/?debug=false&lang=en&modules=startup&only=scripts&skin=monobook&*
http://wiki.cubers.net/:174 GET http://load.php/?debug=false&lang=en&modules=site&only=scripts&skin=monobook&*
If you remove those double slashes, the stylesheets load and the page looks fine.
Also, there's an imported stylesheet which doesn't seem to exist on the server.
@import ./style_for_Main_Page.css;
Thanks given by:
#8
(22 Apr 12, 02:24PM)tempest Wrote: Two stylesheets and two scripts don't load because they're declared with two forward slashes at the beginning of the URL...
If you remove those double slashes, the stylesheets load and the page looks fine.
That's all well and good, but it's just a load of php files and I have no idea where those calls are made.
Quote:Also, there's an imported stylesheet which doesn't seem to exist on the server.
@import ./style_for_Main_Page.css;
This file doesn't exist, which might seem obvious, but it's not even in the files from the old wiki folder. And when I grep the files in the wiki folder, the file isn't mentioned, which means the reference is in the wiki DB, on the page, ie. it was there on the old wiki. This is just crazy.
When I google this file name, the only hits are this forum, so it's unique to our wiki.
* jamz cries.
Thanks given by:
#9
(22 Apr 12, 03:43PM)jamz Wrote: That's all well and good, but it's just a load of php files and I have no idea where those calls are made.
It's most likely just some configuration setting. wgLoadScript maybe, or wgScriptPath. Or something else, there's lots of them.

(22 Apr 12, 03:43PM)jamz Wrote: This file doesn't exist, which might seem obvious, but it's not even in the files from the old wiki folder. [...]
In that case, I guess you can just remove the CSS part from the main page (using the regular editing functionality).
Thanks given by:
#10
(22 Apr 12, 04:16PM)tempest Wrote: It's most likely just some configuration setting. wgLoadScript maybe...
This one isn't in the LocalSettings.php file :/
Quote:...or wgScriptPath.
$wgScriptPath       = "";
...
$wgScriptPath        = '/';
It's unlikely to be this, since wgScriptPath is used all over LocalSettings.php, and most things are working.
Quote:Or something else...
That's what's silly. When I moved the wiki I realised it was grossly out of date, so I wanted to update it to the latest version. This clearly wasn't happening; I just got nowhere. So I decided to try the next newest version instead. That's what we have now. Anyway, part of the update process is to copy LocalSettings.php from the old folder to the new one. It's exactly what was in place before.
(22 Apr 12, 03:43PM)jamz Wrote: ...you can just remove the CSS part from the main page...
Makes sense, but then why would it be there at all?
Thanks given by:
#11
(22 Apr 12, 06:33PM)jamz Wrote:
(22 Apr 12, 04:16PM)tempest Wrote: It's most likely just some configuration setting. wgLoadScript maybe...
This one isn't in the LocalSettings.php file :/
Quote:...or wgScriptPath.
$wgScriptPath       = "";
...
$wgScriptPath        = '/';
It's unlikely to be this, since wgScriptPath is used all over LocalSettings.php, and most things are working.
See, there's the issue.
http://www.mediawiki.org/wiki/Manual:%24wgLoadScript Wrote:Defaults to "{$wgScriptPath}/load{$wgScriptExtension}".
So you currently get "//load.php?blah" in those URLs. In a default install of MediaWiki, this works fine, since $wgScriptPath is "/wiki" by default, so that would give you "/wiki/load.php?blah", which is fine. The obvious solution here is to add either
$wgLoadScript = "/load{$wgScriptExtension}"
or
$wgLoadScript = "{$wgScriptPath}load{$wgScriptExtension}"
to LocalSettings.php.

(22 Apr 12, 03:43PM)jamz Wrote: Makes sense, but then why would it be there at all?
Probably some old stuff used way back before the big crash.
Thanks given by:
#12
(22 Apr 12, 06:54PM)tempest Wrote: The obvious solution here is to add ...
$wgLoadScript = "{$wgScriptPath}load{$wgScriptExtension}"
to LocalSettings.php.
It would have been better if you'd remembered to add the semicolon at the end of the line, which panicked me for a second, but otherwise the immediate response is perfection. Thank you, sir.
Thanks given by:
#13
(22 Apr 12, 08:35PM)jamz Wrote: It would have been better if you'd remembered to add the semicolon at the end of the line
Oops, sorry for that. Cubescript, C++, Python, Perl and now PHP - I'm getting a little confused about which need semicolons :P
Thanks given by:
#14
Well, as far as I know (I dont know Perl), you can add semicolons on the end of all of them and they wont care.
Thanks given by:
#15
In Perl? You have to (except if a closing brace comes right after the statement, and even then it's considered bad style).
Python is where it doesn't matter.
Thanks given by:
#16
For the line in question, I think all of the languages wouldn't have cared if it wasn't required.

Your still a great person.
Thanks given by:
#17
(23 Apr 12, 12:04AM)Ronald_Reagan Wrote: Your still a great person.
:D
And I didn't even call you out on the "your". Oh wait.
Thanks given by:
#18
I know. I realized I made that mistake right after I hit the reply button. I even left it in.


I am not a great person |:D
Thanks given by:
#19
(18 Apr 12, 02:03PM)jamz Wrote: After a few days off, the AssaultCube Wiki is back to life. There are still a few minor issues to iron-out, but it seems to working smoothly. Let me know if you spot any problems that are less than obvious.
Sorry for the delay.

Thank you for your work, its really appreciated.
I have had issues registering a username on the Wiki over the past few days (including just now); upon registering, I receive the following message:

Quote:Database error
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 "User::addToDatabase". Database returned error "1054: Unknown column 'user_options' in 'field list' (localhost)".

Any ideas? Thanks in advance!
Thanks given by:
#20
OK. Well there's another new problem for me tempest to fix.

@RR It's php, and when I tried it copypasta style, I got a blank screen on refresh. Then I noticed the lack of semicolon compared to the other lines and hey presto!

Looks like I've sort-of fixed the problem. I created an account for you, JohnnyFivestar. I'll PM you the details.
Thanks given by:
#21
(22 Apr 12, 06:33PM)jamz Wrote: When I moved the wiki I realised it was grossly out of date, so I wanted to update it to the latest version. This clearly wasn't happening; I just got nowhere. So I decided to try the next newest version instead.
This, I guess: https://bugzilla.wikimedia.org/show_bug.cgi?id=32377
Right?
Thanks given by:
#22
Yes, it was. I didn't think I'd tried any version other than the stable 1.18, but when I got home the 1.19b2 link was purple :(
Bastards.
The reason I said "sort-of" is because after I'd inserted the missing table, I got the generic MediaWiki error that I should uncomment
$wgShowExceptionDetails = true;
to investigate further. When I uncommented that line, the error disappeared completely. I'll put it back when I've got more time to see what happens.
Thanks given by: