Wikidot OpenSource Changes In Trunk

16 May 2009 11:38

I decided to wait no more and share what I've kept at my local disk. I committed the changes I've been working on to the repository.

The biggest change is Wikidot is now single wiki engine by default (you need additional configuration for the wiki farm mode).

What demonstrates the change is the simplified installation process.

Now it's as simple as installing any other software or service:

  1. install the dependencies
    • for Ubuntu: sudo aptitude install lighttpd php5 php5-cli tetex-bin tetex-extra gs-gpl imagemagick libmagic1 subversion postgresql-8.3 php5-tidy php5-pgsql php5-gd zip make
  2. get the code
  3. if on Ubuntu: configure conf/wikidot.ini and set user at [db] section to your login name
  4. prepare database (create role and database)
    • as user postgres: make prepare_db
  5. build Wikidot: configure files and make initial dabatase
    • as you: make
    • this prints a secret URL at the end, you'll use it to configure Admin password
  6. start Wikidot
    • ./wikidotctl start
  7. set Admin password
    • use your browser and navigate to the secret URL make prints at the end

We would like to finally create Debian/Ubuntu packages for that (once it gets more stable and have some bug fixed). So keep tuned!

Comments: 0

Wikidot OpenSource Development Direction

11 May 2009 20:01

Today we though that we might completely change the direction for Wikidot OpenSource. This would deprecate the previous Wikidot 1.0 Roadmap. Also this solution deprecates wdLite (which was a big dirty hack).

Single wiki mode

The main difference is introducing a new Wikidot installation mode: "sigle wiki mode" and setting it as the default instead of "wiki farm mode".

What does it mean?

  • you don't have to bother about:
    • domains (DNS)
    • mail configuration
    • root access (you can start Wikidot on custom port — default 8080)
  • you get direct administration panel for managing users

But:

  • you get only ONE single wiki
  • you cannot create more wikis
  • every IP/DNS address pointing to the started server (and corresponding port) displays THE wiki
  • no mail invitations or password recovery
  • no HTTPS

Lighttpd

Our main webserver is now Lighttpd, we forget about Apache. We can do this, because now you can run your regular Apache server on :80 port and Lighttpd serving Wikidot on :8080 (or other). They don't overlap, so there's no need to keep the compatibility.

Wikidot is a full web service with its dedicated web server running on separate port. This is the philosophy.

Scripts

To make Wikidot easily installable, we're going to create a script (possibly a Makefile) that will simplify the whole process. It would be 4 steps:

  • install dependencies
  • setup the database
  • edit ini file (supply database credentials)
  • make

Dependencies are Lighttpd, PHP, PostgreSQL, ImageMagick and maybe a few other things. Each of them can be installed without root access, but with root access it would be just as easy as

  • aptitude install lighttpd php5-cgi postgresql-8.3 ImageMagick

(or so)

Running/stopping Wikidot:

  • ./wikidotctl start
  • ./wikidotctl stop

Next steps

Once all this is done (which isn't too much work BTW), we could make a *.deb package, that would take care of dependencies, database, creating a special user for wikidot, setting the root directory by convention and installing init script in proper place. Then you would just:

  • /etc/init.d/wikidot start/stop/restart

This should kill all Wikidot-is-to-hard-to-install issues.

… upgrade to wiki farm

Once you have your single-wiki Wikidot up and running you may want to upgrade to full featured wiki farm solution. The one-wiki would become the main wiki (as is www.wikidot.com for the Wikidot.com service), other wikis would be able to be created. On the other hand, as your getting more powerful, you need to configure your DNS (have a domain-class just for your wiki farm), mail service and move the service to the main HTTP port (80).

The hardest thing

Q: What is the hardest thing to do in that plan?
A: The hardest thing is to create a module to manage wiki users.

This should not be too hard, so in the overall, this should work!

I'm waiting for your opinions.

Comments: 8

Wymiatacz

09 May 2009 16:58

This guy rocks.

Comments: 1

API page.save

07 May 2009 20:32

The Wikidot API page.save method is one of the things we've been holding over for weeks, just because there were so many other important things to do.

But the API is also important, because it can enable developers (which are big fraction of our users) to create applications that use Wikidot.com as a service. This can be useful in many ways, the best example I can think of is creating an application, that get some photos from your disk, uploads them to Wikidot, creates a page for each of them and saves some metadata from them into it.

Today, I finally managed to start working on one of the most important API method which is page.save. This method obviously is for saving a page. The page saving mechanism in Wikidot is quite complex, because of advanced site permissions, various performance optimizations, caches and many scenarios of updating a page.

Also, we wanted to make page.save to be one method to update and create pages, which involves other permission checking, because in some cases you have permission to create a page, but not to edit. This is especially true if you have a site category with everybody-can-create-but-only-author-can-edit policy.

I started from dealing with updating already existing pages, so for now page.save can't yet create pages. We have more or less working page.save for the following activities:

code in Python syntax
set title page.save({ 'site': 'quake', 'page': 'dev:api-save', 'title': 'Other title' })
update page source page.save({ 'site': 'quake', 'page': 'dev:api-save', 'source': '+ Come back later' })
set tags page.save({ 'site': 'quake', 'page': 'dev:api-save', 'tags': ['wikidot', 'api'] })
all at once page.save({ 'site': 'quake', 'page': 'dev:api-save', 'title': 'Other title', 'source': '+ Come back later', 'tags': ['wikidot', 'api'] })

Notes:

  • the API service is XML-RPC based, so the syntax of calls is syntax of the programming language you use (Python used as an example syntax)
  • site: quake and page: dev:api-save means http://quake.wikidot.com/dev:api-save page
  • setting tags as a single string (comma- or space-separated) is also supported
  • setting of parent page is also supported in similar way to setting the title

Now we're going to review the code, ensure there is no more caching mechanism I forgot about and make final polishing. This includes generating notifications to be send to page-watchers and saving revision comments.

This method is crucial for the API. Once it gets fully working (including creating pages), applications will be able to:

  • create pages
  • read pages
  • modify pages

and this the core functionality we want to provide with the Wikidot API.

Check out the API methods to see if page.save is already out.

If you want to test the (beta) API, drop a comment at the Wikidot API page.

Comments: 5

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