.search-box input.text { width: 120px; } 

A css module on the nav:side page with that in it should work if you don't have a page for your site-wide CSS.

I think [[module Search mini="true"]] should get you closer to the result you're looking for. Your side bar is pretty narrow, so there may be some other CSS tweaks needed to make it fit nicely.

2. Here's one How-To: Use a logo within your site. Or try these search results in the community forums. This is a frequently asked and discussed topic around here: search "header logo"

3. Add this to your custom CSS to slide the #login-status to the left so your "home" and "edit" links are not getting stepped on:

 #login-status{ right: 250px; /* adjust to taste */ } 

Gene R is now a new MA of scp-ru.

Good luck.

"The SCP Foundation" Russian wiki ( this link or this one) is evolving with three administrators (user names Ged_Malburg, Gene R and Resure), but we cannot contact the master administrator (scp-ru) for a long time. We'd like to have master administrator rights in order to control ads. Hope you can help us in this matter.

Sincerely,
SCP Foundation Russian user community.

… no way to gain access to the administrator account…

We had some similar cases here on Wikidot where the admins and site creator has deleted their account and were gone.
As I know the team of Wikidot has helped here and moved some other members to admins and Master Admins liek site cfreator.

And: the change/move/transfer of an Master Admin (role) to another existing admin is a standard Site manager menu point.

How well will wikidot respond to our attempts to move here?

The only reason why Wikido will not respond well to your attempts moving here is the breaking of the "ToS".
There are some (free) wikis with great traffic and bandwith, with lot pf pages..
if you use a "pro" account than you have rights to use your wiki for SEO-technic too.
Otherwise your wiki will be deleted automatically soon if you are using it for spam of foreign links only.
If you have a lot of collaboration and menus and changes and.. why should Wikidot have sonething against this behaviour?

The main difficulty lies in our already-existing content. Articles, at least, can probably be moved by hand, but the process would be exhausting. Any service which offered a streamlined answer to this problem would be a tremendous draw for us.

There are 2 points for this issue:
1. There is an API existent ( python, java, javascript, php a.s.o) which can be used to load pages ( not yet attached files i think) and to tag them or do parenting. look at the "here APP's for Wikidot" created by some old users
The official docuimentation is here:
http://www.wikidot.com/doc:api
http://www.wikidot.com/doc:api-methods
http://developer.wikidot.com/

2. There is a "little" try from a user to create a page for "translate" media wiki source into Wikidot source , which works very well, but has to be done manually…

http://community.wikidot.com/howto:convert-mediawiki-syntax-to-wikidot

But the problem will exist in the future too if you have only one admin or do not make on a regular basis some backup ( Handbook - Site manager- backup) : http://handbook.wikidot.com/en:site-manager-backup ) of your pages&files and save it to your local disks..
Wikidot has great advantages in comparison with other wiki-languages and services.
I for myself came from mediawiki years ago..
And the community is great here - you will get answers and help very quickly over all the 24 hours.

Has anyone else dealt with this problem before? How well will wikidot respond to our attempts to move here?

Thanks,

Mike

Q: Using user:password@address is not working!
A: Again, first check the hts-log.txt and hts-err.txt error log files - this can give you precious information
The site may have a different authentication scheme - form based authentication, for example. In this case, use the URL capture features of HTTrack, it might work.
Note: If your username and/or password contains a '@' character, you may have to replace all '@' occurences by '%40' so that it can work, such as in user%40domain.com:moc.oof.www|raboof#moc.oof.www|raboof/auth/. You may have to do the same for all "special" characters like spaces (%20), quotes (%22)..

Q: Some sites are captured very well, other aren't. Why?
A: There are several reasons (and solutions) for a mirror to fail. Reading the log files (ans this FAQ!) is generally a VERY good idea to figure out what occured.
Links within the site refers to external links, or links located in another (or upper) directories, not captured by default - the use of filters is generally THE solution, as this is one of the powerful option in HTTrack. See the above questions/answers.
Website 'robots.txt' rules forbide access to several website parts - you can disable them, but only with great care!
HTTrack is filtered (by its default User-agent IDentity) - you can change the Browser User-Agent identity to an anonymous one (MSIE, Netscape..) - here again, use this option with care, as this measure might have been put to avoid some bandwidth abuse (see also the abuse faq!)
There are cases, however, that can not be (yet) handled:
Flash sites - no full support
Intensive Java/Javascript sites - might be bogus/incomplete
Complex CGI with built-in redirect, and other tricks - very complicated to handle, and therefore might cause problems
Parsing problem in the HTML code (cases where the engine is fooled, for example by a false comment (<!) which has no closing comment (>) detected. Rare cases, but might occur. A bug report is then generally good!
Note: For some sites, setting "Force old HTTP/1.0 requests" option can be useful, as this option uses more basic requests (no HEAD request for example). This will cause a performance loss, but will increase the compatibility with some cgi-based sites.

Q: Only the first page is caught. What's wrong?
A: First, check the hts-log.txt file (and/or hts-err.txt error log file) - this can give you precious information.
The problem can be a website that redirects you to another site (for example, www.someweb.com to public.someweb.com) : in this case, use filters to accept this site
This can be, also, a problem in the HTTrack options (link depth too low, for example)

Could be this does not help..

Conclusion:

It seems to me easier to make the site for some minutes "closed" for such download….

far as I recall you can't pass Wikidot usernames and passwords into HTTTrack

That's been my experience too. HTTrack should work great on any publicly visible pages on your site. Rob's solution to temporarily make your site public is the only solution I can think of.