Brickwiki:Technical Issues/Archive 2

From Brickwiki
Jump to: navigation, search

Contents

Old issues

  • The stats page and the admins page don't seem to agree on the number of admins. Is it 3 or 4? ROSCO 00:50, 4 April 2007 (EDT) Found 'im! ROSCO 00:54, 4 April 2007 (EDT)
  • Favicon is back, more stuff to follow. -vs
  • Thumbnails only work for jpg images with size of 200px. Is this how it's supposed to work?
    • No, and that sounds strange. I'll look into it right now. --Venkatesh 11:46, 14 April 2007 (EDT)
      • Thanks, I put some examples in the sandbox ROSCO 23:01, 15 April 2007 (EDT)
        • Images seem to be buggered in general see eg. SNOT techniques Tim 19:27, 18 April 2007 (EDT)
  • The "Article doesn't exist" page contains a link "Search for xxxx in Brickwiki", but when I click that link, I get "Object not found" error. (Try it by typing "Fred" in the seach box.) ROSCO 23:01, 15 April 2007 (EDT)
  • Three times today I have logged in to make edits, only to be kicked out when I click the Save button. One edit was successful. Every time I have still been logged in when I preview the edit, only to be kicked when I save. It seems to take much longer to load the edited page after I click save too. This has only started happening today. I'll see if it happens again with this edit. Preview OK. ROSCO 21:04, 16 April 2007 (EDT)
    • Saved OK this time. ROSCO 21:05, 16 April 2007 (EDT)

Upload image

I receive the following error message when I try to upload an image:

Internal error: Could not copy file "/tmp/phpfowP3b" to "/home/me/public_html/brickwiki.org/images/temp/20070520064719!IMGP1210_1.JPG".

Is there anything I can do? -Howarthe 02:50, 20 May 2007 (EDT)

URLs

Brickwiki is currently accessible at brickwiki.org, www.brickwiki.org, www2.brickwiki.org, and brickwiki.zapto.org. The brickwiki.org names are registered through Verio and have been registered for a period of one year. Verio and Endeavour Networks both host DNS servers and the ones under our control run BIND 9.

I notice it's using the ?title=xxxx format for URLs, is this a server limitation? The index.php/xxxx format seems to be more common. 58.178.233.218 19:35, 25 February 2007 (EST)
It is a configuration limitation (PHP running via CGI) but one that is being looked at. .htaccess should be able to solve this problem. Venkatesh 14:49, 10 April 2007 (EDT)

Mailing Lists

On Jan 31th, 2006 Astronouth contacted Dan of peeron fame and got us a mailing list, brickwiki-l. The mailman page for brickwiki-l can be reached here: http://mail.peeron.com/mailman/listinfo/brickwiki-l, if you are interested in registering.

SVN

The source code to things we have developed here to provide features and support Brickwiki is located in the Subversion system. The repository is accessible via the web at http://brickwiki.zapto.org/svn/ [1]. Currently, the source to the LDraw extensions is located there.

This no longer appears to be working. ROSCO 00:56, 4 April 2007 (EDT)
We're working on this. (As soon as we can find the repo again...) --Astronouth7303 13:55, 6 April 2007 (EDT)


VEC

The Visual Element Catalog contains an LDGlite render of every part in the LDraw database. It works just like images but using "vec:" instead of "Image:"; ie the syntax is [[vec:Ldraw_part_number.png]]. The whole catalog can be seen at http://www.brickwiki.org/vec/parts/. Images of parts can also be included by just typing the full path to the image file.

For example: 4593.png

All images in the Visual Element Catalog are available in two sizes, full and half. To access the full image, use path to the image and the image name. To access the half-sized one, prefix the file name with "half-". For example, 4593.png's dimunitive twin would be half-4593.png.

half-4593.png

The [[vec:3001.png]] syntax is broken. vs and I are working to fix that. --Astronouth7303 14:03, 6 April 2007 (EDT)

Current Interwikis

Part 
http://peeron.com/inv/parts/$1
Firstwiki
http://www.firstwiki.org/$1

As per Sandbox#Interwiki_test, Part and Firstwiki seem to work OK, Meta re-directs OK but there doesn't seem to be anything there, and Vec doesn't seem to generate a link at all. ROSCO 20:19, 26 February 2007 (EST)

VEC is currently broken. We're working on fixing it. (EDIT: It's not a true interwiki) --Astronouth7303 12:53, 6 April 2007 (EDT)

Extensions

ldraw 
highlight LDraw code.
ldraw color 
manage color tables
Dynamic Page List 
automatically lists pages in a category
DynamicPageList2 
same as above, just with new syntax
Templates 
list of all templates
This seems to have disappeared. ROSCO 19:39, 25 February 2007 (EST)
calendar 
automatically generate wiki-fied calendars (in testing)
Edit count 
count edits per user
This seems to have disappeared. ROSCO 19:39, 25 February 2007 (EST)
XMLSyn 
highlights XML code to improve readability

DB Dumps

Templates

A list of all available user templates is accessible at BrickWiki:All_templates.

sub pages

I think the sub-pages feature is not working right or is not actually turned on. Brickwiki:Requested_articles/completed is not a sub-page but an independent page using the / character. Tedward 22:14, 25 May 2012 (CDT)

You're right. We're using the MediaWiki defaults which has subpages for all talk namespace plus the user namespace. I just asked Jeramy to update the LocalSettings.php file to allow subpages on the Project (Brickwiki) namespace. (We tightened security and I can't update LocalSettings.php anymore.)
I don't think we want subpages on the main namespace, do we?
Do we want to add an extension for displaying subpages?

--ALittleSlow 22:43, 26 May 2012 (CDT)

I think it would be useful all over. I would much rather make Rock Raiders characters into Rock Raiders/characters than create a whole new category for articles about Rock Raiders. Tedward 11:56, 27 May 2012 (CDT)
Jeramy has subpages working for the project (BrickWiki) namespace. Based on my tests, any project articles with a slash in the title should now appear as subpages. I was getting ready to give him the changes for the rest of the namespaces yesterday, but I had some problems with shell access. --ALittleSlow 10:43, 30 May 2012 (CDT)
Awesome, thanks for taking care of this. Tedward 11:25, 30 May 2012 (CDT)

Future Work

Internationalization

While discussing the idea of a Lego Wiki on the lugnet.general, we heard that people were interested in having a multilingual setup. For anybody who is interested in having a language added, please write a little request in this section and it will be placed on the list of things to add.

BrickWiki Portal

Extensions

Proposed

ftx Parser 
Parse LUGNET FTX Code

Updates

  • Brickwiki should just have gotten a lot faster for everybody; if there are any problems, please note them below. Thanks! --Venkatesh 21:24, 3 February 2008 (EST)
  • ConfirmAccount extension installed due to too many, probably human, spammers posting nonsense. --ALittleSlow 22:35, 24 May 2012 (CDT)
  • Subpages are now enabled for all non-special namespaces. --ALittleSlow 23:14, 4 June 2012 (CDT)
  • Embedded images are now enabled for www.brickwiki.org, www.brickshelf.com, and media.peeron.com. --ALittleSlow 23:14, 4 June 2012 (CDT)
  • Embedded external images are now allowed for Brickset. The list of sites to allow external images from is now maintained at Mediawiki:External image whitelist. --ALittleSlow 16:28, 27 June 2012 (CDT)
  • CSS was modified to prevent pre-formatted ("<pre>") text from overflowing its bounding box. Not extensively tested, so post in Technical Issues if this breaks something. --ALittleSlow 16:28, 27 June 2012 (CDT)
  • The "Go" button now does a search if no exact match is found. Before it would attempt to go to the page creation screen if no exact match was found. --ALittleSlow 20:11, 10 July 2012 (CDT)
  • Text now flows around the right side of tables of contents instead of following after them. --ALittleSlow 20:11, 10 July 2012 (CDT)
  • Our host, Siteorchard.com, upgraded servers yesterday. We're now even faster! ALITTLESlow: t/c 14:06, 3 March 2013 (UTC)

Image Files

In the 2012 rebirth we lost a lot of image files and a lot of external images have been deleted or moved. I know we used to use a lot of external links but with the new server there any worry about starting to upload new images and perhaps more than before or should I try to find external images to save space? Tedward 16:35, 29 May 2012 (CDT)

I don't remember the exact number, but we have tens of gigabytes of space available and unlimited bandwidth. I'll check Ven's tarball and see if there are any images on there still to be restored. --ALittleSlow 06:08, 30 May 2012 (CDT)
All the image files available on the backup were restored. If it's missing, it's missing for good. --ALittleSlow 10:36, 30 May 2012 (CDT)
Related problem. Many missing images are a result of Template:PartImageInline no longer working. Any chance this can be restored? Tedward 21:03, 1 June 2012 (CDT)
{{PartImageInline|3001}} becomes half-3001.png ... hmm. I wonder if there is something turned off in our config, like not allowing direct html embeds??? ++Lar: t/c 08:14, 2 June 2012 (CDT)
Exactly right. Probably a change due to the MediaWiki version upgrade. I've asked Jeramy to put in this change: $wgAllowExternalImagesFrom = array( 'http://www.brickwiki.org', 'http://www.brickshelf.com', 'http://media.peeron.com'); which will allow URLs for images from the listed sites to automatically be rendered. I didn't want to open it up to every site mostly for security reasons, but also because we shouldn't be stealing bandwidth from other sites without permission. Did I miss any sites? --ALittleSlow 19:48, 2 June 2012 (CDT)
Lugnet doesn't allow direct embeds to ANYONE. But BrickSet might allow it which would be another source of set images besides Peeron. Have to ask Huw. BTW thanks for the speedy fix. ++Lar: t/c 00:28, 3 June 2012 (CDT)
That's implemented, but I'll leave this thread open if you want to check with Brickset/Huw, and/or if there are other solvable image issues. --ALittleSlow 23:16, 4 June 2012 (CDT)
Mail sent, inviting his participation. ++Lar: t/c 10:57, 5 June 2012 (CDT)
I am happy for you to deep link, assuming that the intention is not to replicate Brickset in its entirety and you attribute the source --Huw
007.jpg_thumb.jpg
Battle in progress at Gen Con 2003, taken by Frank Filz.
image gallery

gallery owner (ffilz)

From Brickshelf Copyright held by Brickshelf user ffilz.
Replicating Brickset is not the intent of BrickWiki, see BrickWiki:What BrickWiki is not :) The part that is now showing up above is a locally hosted image but isn't attributed (maybe a template for inline images could put attribution in the hover text????)... Would something like what we did for Brickshelf do? (see box at right... we don't need quite as many parms and the wording needs tweaking, but you get the idea) ++Lar: t/c 13:40, 5 June 2012 (CDT)
That looks perfectly acceptable, thanks --Huw
I have tried to make a template based on the Peeron template but it does not work. Could it be because the images are actually hosted on 1000steine.de? Tedward 16:55, 25 June 2012 (CDT)
That is very likely. You need to know the pattern of image URLs and it needs to be consistent. ++Lar: t/c 06:08, 26 June 2012 (CDT)
I'll have to add 1000steine.de to the list of allowed sites to deep link to. --ALittleSlow 10:31, 26 June 2012 (CDT)
Do we need to get permission from them as well or is Huw's OK enough since it they are "his" images? Tedward 11:18, 26 June 2012 (CDT)
To be safe, from them, since they may have images from other people there. Although our INTENT is to only do Brickset ones and use that pattern... ++Lar: t/c 14:36, 26 June 2012 (CDT)
Used a different filter method: MediaWiki:External_image_whitelist. Able to filter URLs using regular expressions (thus limiting to Brickset images specifically), AND can be edited as needed. ImageBoxBrickset is now working. --ALittleSlow 22:34, 26 June 2012 (CDT)

Deleting pages that cannot exist???

User:Tedward points out there are three pages in Special:DoubleRedirects that have Set:xxxx as the title. Set: is aliased to peeron.com. Perhaps these were redirects created before the aliasing was implemented? Cleaning the entries from the database may be the quickest fix, but that will take me some exploration. --ALittleSlow 10:07, 5 June 2012 (CDT)

Alternatively, maybe try temporarily disabling the extension, deleting these pages the normal way, and then turning it back on??? Else DB fix may be the only way. Think of it as a learning experience! (you had no idea what you were signing up for, did you... LOL) ++Lar: t/c 10:32, 5 June 2012 (CDT)
The problem was exactly as we suspected. I stumbled across three documented solutions, of which Lar's first suggested fix was also their first. I used the maintenance script, namespaceDupes.php. It worked like a charm, replacing the colon with a dash. Then I was able to view and delete them. Ted, you will be happy to know there are now zero double redirects. --ALittleSlow 20:05, 10 July 2012 (CDT)
whoooo hooooo! Tedward 23:52, 10 July 2012 (CDT)

ConfirmAccount and who to approve

I think we may need a bit of discussion on this, not sure where... may be more of a policy matter. As of this writing there are 4 requests pending (I moved one to the hold queue, it looks spammy to me). Take a look at them if you have the authority... Two of them express interest in MegaBlocks. Do we approve those? Thoughts? ++Lar: t/c 10:44, 5 June 2012 (CDT)

I have no idea where to look and no clue if I have authority to approve account requests. I can block so I would think I do. Tedward 12:59, 5 June 2012 (CDT)
Take a look at the top right corner of the screen, right now I see "1 open e-mail-confirmed account request pending" up there, and that link is clickable... that's how. I think it goes away if there are none currently pending... I thought any admin could do this, but maybe it's restricted to 'crats ... in which case we need more 'crats :) ++Lar: t/c 13:58, 5 June 2012 (CDT)
We should give admins permission to approve. The only reason it's restricted at all is to keep out spammers. Anyone else should be allowed in, regardless of their POV. Anyone know how to modify role permissions, or should I look into it? Chances are good it will be a 'crat who has to make to change. --ALittleSlow 14:35, 5 June 2012 (CDT)
Answering my own questions: changing group user rights is documented at Assigning Permissions, and cornfirmaccount is the permission that needs added to the admin group. And you need to be a 'crat to do it.
I think you have to modify a permissions array. What permissions array to modify is probably in the doc for the extension. Chances are it will be someone with shell access (just like you and Jeramy changed an array to add an additional "external" site for images) but I could be confused... (try looking at http://www.mediawiki.org/wiki/Extension:ConfirmAccount#Configuration and at the .php file it references for configuration settings) ++Lar: t/c 14:52, 5 June 2012 (CDT)
By the way, this fella speaks as if it's Admins that have the power, but on our wiki, as of now, Special:ListGroupRights shows it's 'crats alone... I think we should consider changing it. ++Lar: t/c 14:59, 5 June 2012 (CDT)
I'm sure we can change it that way, but I think the array is already populated to the point where a crat can make the change through the wiki interface. Lar, can you check Special:UserRights and see? --ALittleSlow 18:52, 5 June 2012 (CDT)
I did already. It isn't. I can make you a 'crat and you can check for yourself, if you want. :) On the Big Wikis, Stewards had this ability (to manipulate which user groups had which rights) but it was a special extension, not out of the box MW functionality... out of the box the control of which groups have which rights is in the arrays. (I used to be a Steward so I certainly wish we had that extension here... I don't even know the name of it any more) ++Lar: t/c 23:05, 5 June 2012 (CDT)
I hacked ConfirmAccount.php to allow admins to confirm. Note to self: fix it the right way soon. I approved the megablocker, but as to the one Lar put on hold: I would not reject for being off-charter, but I would reject is for obvious intent to abuse the site, i.e. vandalism and spam. This looks suspiciously like spam. I Googled "Philadelphia University Jordan and aha! She wants to spamlink on her user page: http://en.wikipedia.org/wiki/User:Philadelphia_Jo. Spamblock her, I say. Lar, I also got the reject notice for ALS Test Reject, and your comment did appear. Will forward that to the list at some point--the language in the message could be tweaked. --ALittleSlow 10:48, 7 June 2012 (CDT)
This extension is working well. The issue is closed. ALITTLESlow: t/c 22:33, 1 March 2013 (CST)

Error in Database?

I have been editing some pages that are now not displaying the correct categories. Moonbase_module has been assigned to four categories but is displaying seven categories (including SPACE twice) and a non-category that I fixed. Tedward 12:32, 18 June 2012 (CDT)

OK, took some time AFK and sort of fixed it. I had a wrong category in cat:moonbase and fixed that. I also see that sub-categories resolve a little messy as they propagate to the articles in that category (including stub) but without placing the articles in that category. A little confusing to me but not a big deal to most people I am sure. Tedward 15:11, 18 June 2012 (CDT)
A little research on MediaWiki categories and I'm no closer to knowing if this is a MediaWiki bug or problem with our site. Will take more research. Like you said, confusing, but not high priority. --ALittleSlow 11:01, 19 June 2012 (CDT)
A lot of research later, I'm convinced it's a bug in the experimental, but long-standing Category Browser, and I have added my two cents to the existing MediaWiki Bug 33614. I took category:themes off category:moonbase, because it's included in themes by virtue of being in both category:space and category:fan created themes. This eliminated one of the duplicates. --ALittleSlow 14:39, 20 June 2012 (CDT)
Except I have to reinstate cat:themes because it is a theme and we decided that subthemes can have their own category so they must be listed in all three places. Tedward 10:06, 21 June 2012 (CDT)
Meant to add that I have inferred what is going on, and it is predictable. I documented the current behavior at http://www.mediawiki.org/wiki/Help:Categories#Adding_a_page_to_a_category --ALittleSlow 14:39, 20 June 2012 (CDT)
Can we not simply turn-off the auto inclusion in articles and only display those categories used in an article? Tedward 11:26, 21 June 2012 (CDT)
Not sure I understand. You mean turn off the list in the bottom half of the Categories box? Sure. I kinda like it though because it shows how categories are associated. Not a big deal to me either way, though. Or do you mean, for example, that the Moonbase article shouldn't list "Menu > Building with bricks > Themes" because the Themes category isn't used in the article? In this case, that is the bug I was referring to. I think instead of
Menu > Building with bricks > Themes > Fan created themes
Menu > Building with bricks > Themes > Fan created themes
Menu > Building with bricks > Themes > Moonbase
Menu > Building with bricks > Themes > Space
Menu > Building with bricks > Themes > Space

it should be displaying

Menu > Building with bricks > Themes > Fan created themes
Menu > Building with bricks > Themes > Fan created themes > Moonbase
Menu > Building with bricks > Themes > Moonbase
Menu > Building with bricks > Themes > Space
Menu > Building with bricks > Themes > Space > Moonbase

Since Moonbase belongs to three categories, it is listed three times, one for each path from the top-level category. The bug is that for all but one of the paths, "> Moonbase" is truncated, making the list appear to have duplicates. --ALittleSlow 20:06, 21 June 2012 (CDT)

I just thought we might be able to turn off the categories that are not explicitly attached to an article. Moonbase module has only four categories in the article but the server adds two extras in displaying the page. I assume they are there because they are being inherited from the higher level category. Anyway, like I said, most people probably don't care. To me it just looks messy so if it was up to me I'd just turn off the expanded pathways. But I can see how people might find them instructive so I'm not really gonna complain. Don't worry about it.Tedward 23:51, 21 June 2012 (CDT)

History merge botched by me, or not working?

Per the instructions given here (and working from memory, as I've done it a fair few times, a while ago) Wikipedia:How_to_fix_cut-and-paste_moves I tried to merge the history of Talk:Parts Functionality Studies and Talk:Parts functionality studies ... I figured I'd start there. Well either the DB is slow or something's not quite right because the deleted revisions are not back. I will wait a while (or check the job queue) to see if they came back. But right now things are weird. Or maybe I botched it. ++Lar: t/c 16:18, 21 June 2012 (CDT)

I was impatient, all the revisions are there, I just had to wait. I'm used to WP speed where thousands of entries on the job queue get processed a second... I restored all the content with one more edit. ++Lar: t/c 16:22, 21 June 2012 (CDT)

Administrative Mailing Lists

We need to set up an E-mail account or mailing list to distribute account request notifications. Plus we need at least one mailing list to serve as an out-of-band discussion group when needed (such as for discussing things with the web service provider, Jeramy, who doesn't watch BrickWiki). Since nobody wanted to host a mail server, Jeramy recommended using Google Apps (the free version). I've checked into it, and it should work for us. We'll have to update the MX DNS record at some point. Since V's been quiet, and if no one objects, I'll set myself up as the primary contact for Google Apps. We can always change it later. I've already set up the primary account, "Sysop", for administering the Google Apps account. Following Larry's suggestions, I propose the following e-mail addresses/mailing lists (these would all be at the brickwiki.org domain):

  • "accounts" for wiki account support/administration. Subscribers to this list (admins and 'crats) would get notified when an account needs approved.
  • "copyvio" for handling copyright violations
  • "administrators" for administrators, to replace what we've had to do by individual E-mail up to now. All admins and trustees would be subscribed to it.
  • what about "webmaster" to serve as the technical point of contact for the wiki? Perhaps subscribe myself and Jeramy to that?

At this point, I don't think we need a separate trustees or 'crat list.

Sound okay? --ALittleSlow 23:43, 2 July 2012 (CDT)

Sounds like a good plan to me. Tedward 23:52, 2 July 2012 (CDT)
Me too. Thanks for taking the initiative. ++Lar: t/c 10:49, 3 July 2012 (CDT)
In process, just waiting on the MX records to be changed. --ALittleSlow 20:07, 10 July 2012 (CDT)
Out of excuses. I guess I should get on this... ALITTLESlow: t/c 23:03, 6 December 2012 (CST)
Google Apps is no longer free. Jeramy and I are working on alternatives. --21:18, 19 December 2012 (CST)

These E-mail addresses are set up. Currently,

  • accounts@brickwiki.info will forward to the E-mail addresses of the active 'crats and admins: Lar, Tedward and myself.
  • copyvio@brickwiki.info forwards to the active admins, who happen to be the same people.
  • administrators@brickwiki.info forwards to the active admins and trustees, who happen to be the same people plus Claude. I don't have Claude's E-mail address.
  • webmaster@brickwiki.info forwards to Jedspurg and myself.

Currently only I can change this, which isn't good. Is E-mail forwarding sufficient for the administrators group? I had envisioned some kind of private forum. What's left is to fine tune this based on the preferences of the people involved, and to start using these E-mail address in the configuration and in appropriate articles. ALITTLESlow: t/c 19:08, 12 February 2013 (CST)

Good place to start. Thanks for getting that set up. Tedward 23:39, 12 February 2013 (CST)

reCAPTCHA broken

CrazyLEGOMan reports:

I tried adding an external link, but the site doesn't allow it. I get the following error message:

Your edit includes new external links. To help protect against automated spam, please type the two words you see in the box below:
Input error: Invalid referer

I'll have to have Jeramy get a new token from the reCAPTCHA server. --ALITTLESlow: t/c 23:03, 6 December 2012 (CST)

Fixed. ALITTLESlow: t/c 19:09, 12 February 2013 (CST)
Excellent. That was a little annoying. Now to move that we eliminate it.... Tedward 23:39, 12 February 2013 (CST)
Given a choice, I prefer to retain requiring preregistration for contributors, and removing the captcha rather than retaining the captcha and removing the preregistration requirement. I don't think we need both, but if we remove prereg we have to restrict things in other ways as well. ++Lar: t/c 11:13, 14 February 2013 (CST)
I concur wholeheartedly. Tedward 10:26, 15 February 2013 (CST)
Onions got layers! and so does BrickWiki's anti-spam protections. I'm in favor of removing the captcha for URLs, but think removing it for registrations will be one layer too few. I dunno, though. Let's try it. ALITTLESlow: t/c 11:04, 28 February 2013 (CST)
ConfirmEdit and reCaptcha extensions have been disabled. Let's see what happens.... ALITTLESlow: t/c 11:18, 28 February 2013 (CST)

Landing page out of date

If you go to the landing page while not logged in http://www.brickwiki.info/ it still has the "new faster server" message on it. ++Lar: t/c 18:28, 3 April 2013 (UTC)

Man, I nearly pulled my hair out on this one. I could not find that text anywhere. It was overriding the MediaWiki:Anonnotice on main and talk pages for anonymous users. Thinking it may be a leftover artifact, I tried setting $wgSitenotice in LocalSettings.php, to see if that would force it to clear--and it did! Only I mis-typed $wgSitenotice, so that wasn't what fixed it. I can only assume that "touching" LocalSettings.php forced a re-read of that file, which cleared it. ALITTLESlow: t/c 03:42, 4 April 2013 (UTC)
It happened again. I had an Anonnotice set up regarding Email not working. With that fixed, I deleted Anonnotice via BW, but the notice didn't disappear from the landing page. I did a "touch LocalSettings.php" from the Linux prompt, and then it went away. Lesson: never say never. :) ALITTLESlow: t/c 02:25, 16 April 2013 (UTC)

Thumbnails Broken

Just notices thumbnails are broken, at least when invoked from ImageBoxBrickshelf, and probably the other ImageBoxes. Anyone else seeing this, and know when it started? ALITTLESlow: t/c 16:55, 25 August 2014 (UTC)

No, it's just that Brickshelf is down.
Personal tools