Wikidot Dev Site

Syntax highlighting would be nice feature for any FLOSS projects - especialy those which are some sort of library or have plug-in facilities. As probable (ie. I look through sources) wikidot is on php it could use GeSHi as it on GNU GPL (and wikidot is on GNU AGPL).

On the page entitled Debian QuickStart (which to a novice does not sound like it should be very useful when trying to run a virtual Ubuntu machine), I found the following:

sudo su -

Do you suppose this is what I need to use with the virtual machine? I would have tried it already but I'm trying to download the VM again (6th try!) hoping to get a clean copy.

If you are using Windows, then you may try "[[www.rarlab.com/download.htm WinRAR]]"

See if that helps….

-gmhelper

P.S. I am also interested on how to work the Virtual Version coz I have installed it on my PC.

I'm hoping to have a chance to try out the virtual machine package of the wikidot server, but I'm not having any luck.

I downloaded the VM as required, and got what I think is a clean copy, tho it took several tries

• wikidot-dev2-vm-20080220.tar.gz (603,068 KB, or 617,540,980 bytes)

I tried using PowerArchiver and TUGZip, but neither was able to decompress everything for some reason. Neither generated errors, tho. By merging the two uncompressed versions, I was able to get a VM that booted up, but apache failed during startup, and the /wikidot/…/wikidot1 and wikidot2 directories were empty.

When I tried to shut down the VM, I kept getting an error: "Must be root", but I do not know what the root password is. It isn't "wdadmin", as it is for the wdadmin account. I had to force a "power-failure" shutdown in WMWare Player just to turn the VM off.

Any help you can provide would be appreciated.

Thanks,

David.

Hi Michal,

It's been over two weeks since your reply and nothing has changed. (And a month since I originally provided the detail in bug reports.)

I would sign your contribution license and commit the fixes to wikidot v1 myself if I had any assurance that the changes would flow through to the wikidot.com website in a timely fashion. However, there's nothing published showing how the two connect with planned releases, etc.

First off; great! I shall test it as a intranet startpage for some students here.
How come the wikidot service is free? I wonder who pays the bills.. or does wikidot sell Pro-wiki's for corporations?

Perhaps the virtual-machine page could mention which VM version this was exported from;
I was not able to open it in VM-Player 1.0.4 or 1.0.5.

I'd rather not use the WM-Player 2.0 Beta because it might disturb other VM's on this hardware!

Thanks!

Can someone with subversion access update the open source version as well?

I am sorry for the delay, the fix will be incorporated in wikidot.com asap.

michal

With PHP it is simply enough to have some of the libraries (for V1 only pgsql and tidy) NOT as shared libraries, because this can introduce segmentation faults to your Apache instance. Quite odd. Right now we are moving to rpm-based server distros, but recompiling src deb works fine - you just need to change the rules file, locate the "configure" options and make the pgsql and tidy compile as not shared libs.

Everything else is described in the "debian quickstart".

m.

I've reported a couple of bugs over on community.wikidot.com that contain all the necessary information to fix the bug, e.g. I've referenced the actual files from Wikidot v1, included the lines of source code that need fixing, and provided IMHO easy to follow instructions that would fix them. The effort for anyone to take these bug reports and fix the code is minimal, but the bugs remain.

For the record here are the bug reports:
http://community.wikidot.com/forum/t-22246/module-newpage-doesn-t-honour-template-selection
http://community.wikidot.com/forum/t-46381/many-blank-templates-appear-in-template-list

So, I'm wondering if there is a better way to get bugs fixed. If source code changes are made on the open source Wikidot v1 repository, do the changes flow through to wikidot.com blogs? If not, can the relevant patches be sent through to another destination, e.g. email address? If so, what is the delay between changes to the repository here and the live wikidot.com wikis?

Thanks.

In the notes discussing Virtual Machine operation, one of the items listed was "PHP 5.2.4 recompiled to include required extensions and to solve some irritating bugs".

If I were to move V1 Wikidot to another hosting server that has PHP 5.2.x, are the bugs you fixed listed in one of the changelog? Were there workarounds in the code base for some or all of the PHP bugs?

I know V2 is taking lots of cycles and it may be that the bugs you refer to only show up in V2 Wikidot; only PHP bugs related to V1 are of current interest to me. Any pointers would be appreciated.

I'm going to try to create a "load_users.sql" file in an attempt to populate my production Wikidot server with an initial set of users. In looking through the "dump.sql" file in the Wikidot 1 distribution, it looks like all I need to replicate is the copy commands for the ozone_user and profile tables.

Are there any other tables that need records added or updated?

On a related note (for purely selfish reasons!), are there any plans in the works to allow wikidot.com users to create an export of their wiki sites that could be imported into an open source install? I realize that extra steps would be involved with file attachments, etc., but it would be a nice feature to make a full backup/restore of a site easier.

-Ed

Hi,

yes, we want to implement such functionality in WD2 and this could be done in at least 2 ways (btw: now it is a good time to discuss which is better):

1. Draft/unpublished mode

One could edit pages and save without publishing. This would mean that a page (or whole wiki) could have 2 versions: current and published. This would add extra structures to the site and myself I am not a big fan of this solution because I find it lacking flexibility.

2. Cloning & merging back

To keep a page/category/wiki in a consistent state one does not edit live pages, but instead "clones" a page/category/wiki and makes changes to the working copy. When changes are done (and reviewed), they can be merged back to the original source. Since the clone operation links the original and cloned content, merging back should be easy and straightforward.

The solution 2 is inspired by how distributed version control systems work (e.g. Mercurial or Baazar). If we can implement a nice merge tool, several people could easily work on the same document (different copies) and push the changes back to the original container.

IMHO it gives nice flexibility and could be adapted in various workflows. The clone-edit-review-publish would nicely work with the permission system.

We are not really planning this for the "alpha release" of WD2 (in the next few months) but this is a must eventually. Michal Bartoszewski (e1n) is working on adapting a 3-way XML merge tool (I think this one) to this scenario but any help from XML experts would be highly appreciated.

best,
Michal

Currently on Wikidot1, I have to edit the "live" pages, and if there are lots of interacting changes, sometimes it leaves the site in an inconsistent state for visitors. I'm used to having a staging server that holds the pre-production version, and when things on the staging server are working well, I throw the switch (well, actually someone pauses the server, copies the file paths from the staging server to the production server, and restarts the production server.)

Any thoughts on doing a similar operation on Wikidot, either 1 or 2? One site I know of uses port 8080 for staging and 80 for production, while another has two URLs, one for each type.

If there were a quick "restore from zip" mode, I could zip the staging WD server and restore the zip to the main WD server, after first clearing it (deleting it?). Something that doesn't involve requests to the WD admin so I can roll forward/roll back as needed.

Thoughts, suggestions. WD2 solution already in the works?

TIA

Michal,

Thank you for the quick reply and quick fix! I applied the new php file and "recompiled" the pages and everything is working well now. Hopefully, that will be the last hurdle.

Thanks again for all of your work on this project.

-Ed

Thanks for the info, it looks like the HTMLPurifier that we wanted to use instead of good old Tidy was… purifying too much and effectively removed a few important attributes from some tags.

Now Tidy is back and buttons and collapsible blocks should work. Already commited to svn.

thanks,
Michal

PS. I think you will have to "recompile" the affected pages, i.e. edit them (a bit) and save the top-nav.

Now that I have a real, mostly-working site, I'm starting to port pages from one of my Wikidot.com sites to my personal server. This server is my "proof of concept and functionality" before I go live with a Wikidot install at my workplace.

After porting just a couple of pages, I noticed some strange behavior with the [[button...]] and [[collapsible...]] functions. Rather than bore you with the details, I have set up a sandbox site so you can see firsthand what's happening.

Ed's Sandbox

I can't promise that this server will be up 24/7, or how long it will be available, but I would really appreciate it if some members of the development team would take just a minute to look. I have permissions pretty wide open, so no need to create an account or become a member to play in this sandbox.

This is all I have found so far with my stand-alone server. I will continue to update my sandbox page if I find other issues.

Thanks,
-Ed

I think I just found the problem. bin/config.php was not finding the apache.vhost.wikidot.conf file and couldn't update the variable names. I have fixed my script and am running another test install.

Sorry for being such a pest! I'm under some pressure at work to get a Wikidot install running on our internal network and have been testing like crazy at home to make sure it will work as well as your hosted site. I must be over 20 test installs now since you released Wikidot to the open source community.

-Ed

As far as I can see the configuration scripts in wikidot1/trunk have not been touched recently… http://svn.wikidot.org/svn

Michal,

Unless I made a mistake in my install script, it appears you made a change in the last day or two to the distributed apache.vhost.wikidot.conf file that causes the Apache server to fail upon startup.

Some of the new %{WIKIDOT:xxx} variables don't appear to be getting set properly somewhere. When I reverted back to the older version of the config file, things started working again.

Are there new steps that need to be added to the Debian/Ubuntu install guides?

Apologies if I made the mistake - my install scripts were working well 2 days ago and I only made minor changes that should not have caused this, but maybe I missed something.

Thanks,
Ed