Do you know about mindmaps? I think they're an addiction...once you try it, you can't live without it! Freemind is an excellent software for creating managing mindmaps, and it has an applet version which can be run inside a browser. WikkaWiki has already included this extension, why not do the same?
Gaggio
2. Open Bugs
2. 1. Installation Problems
Hello to everybody.
I do experiance a strange behaviour during installation procedure. After filling out the installation form and clicking on the continue-button a new page appears with the line "Testing Configuration" and then nothing happens. The script just hangs. It even does nothing after several minutes. It does not matter wheather the database is setup or not.
Any Idea?
Gregor Kaczor
Hi Gregor!
You should see something like
Testing MySQL connection settings... OK
Looking for database... OK
Actually I do not understand what's going on. If the database connection was properly configured it should just work. Could you please provide more info: which OS are you using (Linux/Windows/OSX)? PHP, Apache and MySQL versions?
Let me know please. AndreaRossato
Hi Andrea,
it seems to me that it was was a firewall problem as the database was running on another linux(suse 9.3) machine. Nevertheless there was no problem report on a failed connection to the database as you described.
My config:
server1: Apache/1.3.26, php4 (4.2.1), uniwakka (0.5.2) on Debian Sarge
server2: mySql 4.0.53 on Suse 9.3
client: FireFox? on Debian Sarge
I solved the problem by shifting the server 1 to server 2.
regards
Gregor
Hi Gregor, you are right indeed: the setup wizard is not reporting database connection problems. Will fix it for the next release. Thanks for pointing that out. AndreaRossato
Some one!
2. 2. MIME Type
Every know and then I hear people complaining about not being able to see the pages from IE. And also it seems like google is not intrested in indexing the uniwakka mathml pages. (like this search in google: site:uniwakka.sourceforge.net). Although I see some work arounds in actions/header.php, still it seems not working very well. I found this page in blog regarding this problem and it has sample php codes. Do you think it will solve this problem? PooyaKarimian
When I started developing UniWakka and decided to include MathML support I studied this problem and decided that standard compliance should be a MUST. According to the W3C, modularized xhtml-1.1 should be served as application/xhtml+xml. The problem is that the great majority of browsers do not deal with it. So I decided to serve it as text/xml, which MAY be done. Anyway, xhtml-1.1 plus mathml 2.0 should never be served as text/html, which is done by this page (try it with lynx, that only support text/html).
I now find out that some versions of google bot do accept application/xhtml-xml but not text/xml. So, I can check HTTP_ACCEPT and serve it as application/xhtml+xml, when accepted, and text/xml in other cases. But we should not going to serve it as text/html, since this would just break the standard. This approach should solve google indexing problems but not IE issues, I believe.
If mathml support is off, then UniWakka is served as text/html. This should not happen, but according to W3C, «the use of 'text/html' for XHTML SHOULD be limited for the purpose of rendering on existing HTML user agents, and SHOULD be limited to documents which follow the HTML Compatibility Guidelines.» I think that this could be the Uniwakka's case. AndreaRossato
Just commited to cvs a check for [HTTP_ACCEPT]: if user agents support it UniWakka wil be served as application/xhtml+xml, otherwise we switch back to text/xml. Hope this is going to fix the googlebot problem. AndreaRossato
2. 3. Stuck Installation
Help, I'm stuck with these errors:
Notice: Undefined index: wakka in C:\serva\uniwakka\wakka.php on line 1283
Notice: Undefined index: wakka in C:\serva\uniwakka\wakka.php on line 1283
Notice: Undefined index: wakka in C:\serva\uniwakka\wakka.php on line 1283
Notice: Undefined index: wakka in C:\serva\uniwakka\wakka.php on line 1283
Warning: session_start() [function.session-start]: Cannot send session cookie - headers already sent by (output started at C:\serva\uniwakka\wakka.php:1283) in C:\serva\uniwakka\wakka.php on line 1315
Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at C:\serva\uniwakka\wakka.php:1283) in C:\serva\uniwakka\wakka.php on line 1315
Notice: Undefined index: wakka in C:\serva\uniwakka\wakka.php on line 1318
Warning: Cannot modify header information - headers already sent by (output started at C:\serva\uniwakka\wakka.php:1283) in C:\serva\uniwakka\wakka.php on line 792
WinXP running with Apache 2.0, PHP 5.0, MySQL 5.0. I already build the wakka.config.php by hand due to the php5 error.
How can i fix it?
Thanks a lot in advance and keep up the good work
Olaf
Hi Olaf,
thanks for using UniWakka. What you are experiencing are not errors, but notices, something we inherited from the original Wakka Api and, since not really errors, I did not correct so far. I will, though. UniWakka is undergoing some major changes, due for the 0.6 serie. These will include an AJAX editor (probably featuring some kind of WYIWYG editor mode), tempates, a more Object-oriented approach with class extensibility php-5 ready, and so on... This is somehow slowing down the release cicle.
By the way, you can solve your problem by changing your php.ini file. Search for: error_reporting =
you sould have something like error_reporting = E_ALL
Change that to error_reporting = E_ALL & ~E_NOTICE
This way those notices will not mess up your wiki. (The warnings you receive are due to the fact that those notices are being sent to the browser before setting your session cockies).
Hope this help. Please report back if not. Thanks. AndreaRossato
2. 4. XML Parsing Error makes page unable to load
(Feb 07, 2006)
Uniwakka is a great piece of software, and I had several months of fun with it so far. Unfortunately, I have come up against a problem that I cannot access my pages due to the XML parsing failing. The issue is a mistakenly input invalid unicode HTML entity.
Admittedly, I was not smart and pressed store intead of Preview, after all, what could one test charcter do? Well, I mistakenly exchanged the order of the # and the & in the unicode HTML entity I wanted to test, and now my page is unable to load, or edit back via the edit button:
In the above, I have put spaces between the characters of the offending unicode HTML entity, since I could not find a way to excape it from the parsing done by Uniwakka.
I have searched Google for ways to repair such damage, and come up blank. At the moment, does it mean reading the source code, calling up the database entry myself with the provided functions, shutting off HTML entity -> unicode conversion, and then editing and resaving, outside the confines of the wiki? Or is there another way open to Administrators?
Followup: hack
I added lines to the two replacement functions in wakka.php below to remove the character strings before the XML parser chokes on them. The parse could surely be improved to prevent this, since a choke also means the editing up until there is lost. I again had to add spaces between the characters of the offending entity to prevent choking.
<?php function deCP1252 ($str) { $str = str_replace( "# & x 8 F D 9 ;", "abcde", $str);
function deEntity ($str) { $str = str_replace( "# & x 8 F D 9 ;", "abcde", $str); ?>
Many thanks, Gernot Hassenpflug (gernot@rish.kyoto-u.ac.jp)
Solved in cvs. You need to apply this patch (I don't know if it will apply cleanly since it is against cvs HEAD): http://www.istitutocolli.org/uniwakka/files?filename=unicode.patch
This is not the cleanest solution. I need to find a way to better deal with valid xhtml named entities and to properly distinguish them from unicode entities. I'll study the problem. For the time being I'm not moving this issues in the solved corner of this page.... AndreaRossato
2. 5. Calendar disables TOC
(Feb 07, 2006)
If I have a calendar on a page, the Table of Contents for that page does not get created, just a grey box titled Contents. I now put Calendar on its own page to avoid this conflict.
Gernot Hassenpflug
2. 6. Copy&Paste problems with wakka.config.php text when server can't write the file
I use UniWakka with a project at Sourceforge so I have to update wakka.config.php by hand (Isn't it?). But when I copy the text it hasn't the /n.
You use // for comments so it break the php file. Use /* */... Or fix the Copy&Paste problem ;).
I use Firefox. Thanks for your works.
Aurelio Arroyo
2. 7. XML errors in RecentChanges
I'm using UniWakka 0.5.4. Loading the RecentChanges page often results in XML errors (the page is not displayed). I have found that line 60 of actions/recentchanges.php is to blame. More precise, the function Format():
Replacing $this->Format($page["user"]) with $page["user"] avoids the problem. I haven't looked into the definition of Format() to see what's causing the errors though.
Brecht Machiels
2. 8. Subwikis and the Ajax editor
There is a problem with the toolbar images of the Ajax editor when editing subwiki pages. The browser is looking in the wrong place. The Apache error log shows:
[Tue Dec 12 20:55:59 2006] [error] [client 134.58.253.130] (63)File name too long: Cannot map GET /subwiki/libs/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/images/ajax/wikiwyg/images/separator.gif HTTP/1.1 to file, referer: http://my.domain.com/subwiki/HomePage
Brecht Machiels
3. Closed Bugs
3. 1. small bugs!
cool, I saw some new changes to CVS. Just a small bug that I found is in /actions/bibliomanage.php you fixed one of the school misspellings but still one is left. fixed
3. 2. Hiding footer logos in print
The logos in actions/footer.php are also showed in print mode. Changing the <p></p> tag around it to <p class="copyright"></p> will solve the problem. You can check that in print preview. fixed
3. 3. Linking URLs in citations
fixed
3. 4. Semi Private Wiki
We wanted to let everyone change the content on our wiki but also having the ability to limit read/write on some pages only to known users. Not having a group permission in Uniwakka (at least as far as I know) we decided to set the private flag on to have a closed registration and then setting the ACL to + on certain pages. But the current behavior of private is that it does not allow anonymous page changes at all. We changed our code by substituting private flag with 1 in all PHP files except the registration one. While having the ability to set ACL on every page, I believe disabling write on every page is not a good choice. Maybe it is better to instead have another flag which sets the default ACLs for new pages. I think it should not be that hard to implement, I can write it and release the patch. Ideas? PooyaKarimian
If I correctly understand, you need to have closed registration and anonymous users with write/read permissions on some pages, right?
This could be achieved by changing the behaviour of private wikis so that the default write ACLs are set to +, and only registration is closed. I can do that, since is probably a more consistent behaviour.
Instead, if you want open registration with default ACLs in new pages to be +, you just edit the configuration of the main wiki (or each subwiki) to have + as default ACL for write permission. AndreaRossato
Yes, that's the first case. Actually as I said before I did a quick hack (substituing private in some pages with 1), but I proposed that as a change to the public code. Because I believe when there's a permission for everypage then there's no need to check that flag every time too. The only difference can be in install script for setting the default permissions in the case of private wiki. PooyaKarimian
My concerns are related to updating existing databases. I need to study a safe transition. AndreaRossato
I decided to add a new Access Control option: now you can choose between an open wiki, a private wiki and a closed registration wiki. This way we do not have to bother updating the database. Moreover users can choose private wikis without bothering of ACL lists. There is an UI for updating, adding and editing new wikis. What do you think?
There are some more issues with Latex/MathML, but I hope to make 0.5.2 available as soon as possible. AndreaRossato
It looks good to me, Thanks. I see a change in the content-type options but I don't know whether it is a workaround for search engines or not. I myself may change our own wiki's code against the standard to make sure it is indexed in search engines. But maybe in future a standard way to do that for MathML is to have a formatter which converts pages to html (removing formulas) and then redirecting all the agent that don't understand MathML to that. Anyway, thanks for the good job, I'm sure releasing the new version will attract more people to UniWakka. PooyaKarimian
fixed
3. 5. Anti Spam
We were receiving lots of spam from bots at our wiki so I added some spam prevention code to UniWakka. This patch adds a textbox underneath any texbox asking for a Antispam word. It is a kind of simple text based WikiPedia:Captcha turing test for preventing bots. It ask for antispam_word defined in wakka.config.php. If the javascript is enabled then the user will not even feel it, because it will autofill the field and hide it. For a more complex approach or an image based Captcha (which is not an accessible solution), it is possible to generate antispam_word as a session variable and generate the graphics in gen_antispam function. But I believe that even this simple form can prevent most of the bots. I think the coressponding files that generate the configuration in setup/ dir should also be changed to add this to configuration. A suggesion could be to default it to wakka_name. Here comes the patch: http://www.pooyak.com/p/uniwakka/antispam.patch
A change in Firefox version 1.0.6 to 1.5.0.1 breaked the tab key again. To make TAB key press working again in textarea you can use the following patch: http://www.pooyak.com/p/uniwakka/firefoxtab.patch
this code also add a meta tag to pages that are not the latest to prevent search engine bots from indexing old pages that got reverted back because of spam. PooyaKarimian fixed
3. 7. code
tag handling
in "formatter/wakka.php", I think the if statement that finds the code sections (%%) should be moved up to before the one that finds (double quotation). Because we may have characters like -- or other formatters inside the code section which should not be processed as wiki tags. Look at this example:
Yes, you are right. But I'm finishing a new formatter, based on Text_Wiki: this should solve this and other problems (for instance the fact that it's impossible to insert inline formatting in headings). AndreaRossato
Hi!
I've managed to pass the uniwakka install, but although the installation writes the wakka.config.php, this file is not storing any information (only the uniwaka version is stated)... does anyone has a config file with all options written?
Allen
Hi Allen,
there seems to be problems in writing the configuration file in some installation. I believe this is due to some php 5 issue. Since I did not tested UniWakka with php5 I did not find out what causes the problem. I'll try to solve it as soon as possible. In the meantime you can try the following config file, to be edited according to your installation.
Let me know if it works, please.
<?php // wakka.config.php written at Sat Jun 11 12:41:00 2005 // do not change wakka_version manually!
$wakkaConfig = array( "site_name" => "wakka", "mysql_host" => "localhost", "mysql_database" => "YOURDATABASE", "mysql_user" => "MYSQL_USER", "table_prefix" => "wakka_", "root_page" => "HomePage", "wakka_name" => "MyUniWakkaSite", "base_url" => "http://localhost/wakka/", "rewrite_mode" => "1", "action_path" => "actions", "handler_path" => "handlers", "header_action" => "header", "footer_action" => "footer", "css" => "wakka.css", "navigation_links" => "PageIndex :: RecentChanges :: RecentlyCommented :: UserSettings", "referrers_purge_time" => "1", "pages_purge_time" => "0", "hide_comments" => "0", "default_write_acl" => "*", "default_read_acl" => "*", "default_comment_acl" => "*", "mathml" => "1", "private" => "0", "email_notification" => "Y", "mysql_password" => "MYSQL_PASSWD", "meta_keywords" => "", "meta_description" => "", "mail_admin" => "YOUR_EMAIL", "rdf_rights" => "Verbatim copying and distribution of this site are permitted worldwide without royalty in any medium provided this notice is preserved. Modifications may occur only on this site.", "rdf_lang" => "it-IT", "aspell" => "0", "aspell_dict" => "", "aspell_command" => "", "wakka_version" => "0.5.2", "admin_user" => "YOUR_ADMIN_USER"); ?>