Why Wikidot Rulez

04 Aug 2008 14:39

Have you ever wondered why Wikidot rulez?

You could say, "hey, there is much more other wiki hosts out there, why should I use Wikidot?"

Wetpaint look quite nice, but has anoying Google Ads everywhere. (I've read, they have $40 million capital).

Wikia has the strange permission thing — if you post anything, it becomes their property.

PbWiki didn't allowed me to upload HTML file like this:

abc bac

It claimed, that this is a spam and disabled file upload for 15 minutes for all pbwiki sites!

In the contrary Wikidot has many friendly features1 and have a totally different ads policy. Actually, they let YOU earn with their service. If you wish to display ads on your wiki, you get as much as 80% of what Google pays for them.

Wikidot rules, and has everyday-growing community, with their masterpiece wiki at http://community.wikidot.com/.

Comments: 0

A Lot!

01 Aug 2008 23:10

- How much do you hate IE?
- A lot!
- That's enough, welcome in our team.

With the news about new team member, new themes and major software improvement it seems, that here, at Wikidot, we work hard. And as a matter of fact, we do.

I've recently created two nice themes for Wikidot:

  • Bloo — especially for bloggers and a variant of this Bloo - no sidebar
  • Not-yet-named (codename booze) — the one that is used on the http://themes.wikidot.com/

The latter was designed with much help from SquarkSquark — the new team member.

Other interesting facts from the behind of scenes, with the server software upgrade, we've fixed some bugs, including:

  • browsing by tags now allows special characters like + in tags
  • printer-friendly version of forum was fixed (actually it seems that this had never worked before)

Moreover, we've injected more magic to Wikidot. The greatest improvements are:

  • serving user-uploaded files. PHP checks whether you have right to see the file and then instructs the Lighttpd web server to serve the file to the user. We're using X-LIGHTTPD-sendfile for this purpose. Moreover we're now using a totally different domain for this: *.wdfiles.com, which prevents from JavaScripts attacks.
  • direct access to any code block inside wikis. Just append /code to the URL
Example codeblock, that is accessible with a custom URL:

Moreover if you set the type of the code to html or css, Wikidot will serve the file with the proper MIME type which makes the codes usable as external style sheets or iframe destinations!

See the following codes:

        <title>Wikidot extracts codes from wiki pages!</title>
        <link rel="stylesheet" type="text/css" href="http://piotr.gabryjeluk.pl/dev:a-lot/code/3"/>
        <p>HTML live-extracted from page's code with attached live-extracted style!</p>
p {
    border: dashed #f00 1px;
    background: #ffa;
    color: #f00;
    font-weight: bold;
    font-size: 40px;

Now the trick. To access the second (and any other) code block, just supply the URL of the page following by /code/<number>

for example


will point you to the second code block in the http://piotr.gabryjeluk.pl/dev:a-lot page.

Now the Live demo:

Cool, huh? No file uploads needed, just save the code at Wikidot page and… access it!

Comments: 2

Wikidot Rulez

21 Jul 2008 11:55

Hi there,

Did you know that…


Comments: 0

New Way Of Dealing With Uploaded Files

06 Jul 2008 09:41

Unfortunately, it seems that our last approach (described here) to finally get the uploaded files right was not exactly possible. As authorization in Wikidot is based on cookies and sessions, they will not pass through cross-domain solution.

Allowing to read session_id from cookie in user uploaded HTMLs in not a good idea because of possible session spoofing.

So we designed an authorization mechanism that allows owner of a particular session browsing files from a certain wiki.

When a request to restricted user uploaded file (on the *.wdupload.wikidotsyndication.com domain) is performed, we will check if the cookie is set, then if it points to a valid session and if the user bound to the session is granted a permission to view the file.

If the auth cookie is not set, we'll redirect the browser to the *.wikidot.com site (which can read the original session-cookies) that will generate a unique key and redirect back to the original domain appending the unique key to the GET request. The original domain will then set the cookie and the access will be granted (or not).

Comments: 2

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License