Forum OpenACS Development: Re: XoWiki 0.36

Collapse
12: Re: XoWiki 0.36 (response to 11)
Posted by Michael Steigman on 08/25/06 08:10 PM
A clean install isn't an option here. I want to install it into a working system. I reloaded the production DB into the dev environment and tried installed the latest xowiki/xotcl-core from HEAD (w/o the upgrade I had to go through after installing xotcl-core from the repository) and see the same behavior. Both packages appear to be enabled and I don't see any problems in the log regarding either package on server restart. I see this in the log when trying to access an xowiki package instance:

[25/Aug/2006:13:49:54][4915.1091598688][-conn:x-dev::4] Notice: --after adp, ::262 ::xowiki::Package->return_page (204ms, 43ms)
[25/Aug/2006:13:49:54][4915.1091598688][-conn:x-dev::4] Notice: --i ::262 DONE, ::262 -> (205ms, 0ms)

Collapse
13: Re: XoWiki 0.36 (response to 12)
Posted by Stan Kaufman on 08/25/06 08:43 PM
Yeah, there are some issues Gustaf will need to look at when he gets back from vacation. It doesn't seem likely that this bug is actually related to your problem (since a fresh install doesn't generate your problem). But it's clear that Gustaf has been refining things rapidly, so I would imagine that the packages will settle out soon.
Collapse
14: Re: XoWiki 0.36 (response to 12)
Posted by Gustaf Neumann on 09/03/06 08:58 PM
Concerning updates for the last few releases of xowiki:
some files were removed in the newer xowiki from cvs, which do harm the new version (now most requests are handled by index.vuh, so if there is e.g. a left-over www/view.tcl, it will mess up).

so, i would recommend for the upgrade to rename the old packages/xowiki directory and check out a fresh version from cvs. The rest should be done by the update scripts.

-gustaf

Collapse
15: Re: XoWiki 0.36 (response to 14)
Posted by Michael Steigman on 09/05/06 06:13 PM
Checked out stuff from scratch again from CVS. Reinstalled and restarted with pretty much the same result:

Error:

No page 'wiki/' available.

In the logs (a bit further up - probably didn't notice these last week):

snip...
[05/Sep/2006:11:53:58][20443.1087388000][-conn:x-dev::0] Notice: --try en:wiki/ -> 0, ::262 ::xowiki::Package->resolve_request (18ms, 0ms)
[05/Sep/2006:11:53:58][20443.1087388000][-conn:x-dev::0] Notice: --W object='wiki/', ::262 ::xowiki::Package->resolve_page (18ms, 0ms)
[05/Sep/2006:11:53:58][20443.1087388000][-conn:x-dev::0] Notice: no prototype for 'wiki/' found, ::262 ::xowiki::Package->resolve_page (18ms, 0ms)
[05/Sep/2006:11:53:58][20443.1087388000][-conn:x-dev::0] Notice: --before adp, ::262 ::xowiki::Package->return_page (19ms, 0ms)

Collapse
16: Re: XoWiki 0.36 (response to 15)
Posted by Gustaf Neumann on 09/06/06 08:50 AM
Michael,

your are trying to load a page named "wiki/". This is configured and not standard behavior of xowiki. can it be that you have defined (in the package parameters or in the folder object) that the index_page is "wiki/" and you have no page named "wiki/" available? Either remove in the first step the definition of the index_page or remove the trailing slash.

Collapse
17: Re: XoWiki 0.36 (response to 16)
Posted by Michael Steigman on 09/06/06 05:42 PM
Hi Gustaf,

I have the package mounted at mysite/wiki and the navigation is generated automatically based on the list of subsite apps. Since I've named the application instance "wiki", the link is generated as mysite/wiki, which is redirected to mysite/wiki/ (not sure if this is something xowiki is doing). I haven't configured anything, just mounted the package. I tried tacking "index" onto the url (mysite/wiki/index) but that resulted in a different error.

I also don't seem to have an index_page param (if it is an instance param) and since I cannot get to an xowiki page, I can't change behavior any other way.

Collapse
22: Re: XoWiki 0.36 (response to 17)
Posted by Gustaf Neumann on 09/08/06 04:37 AM
you mean, you are navigating from the "main site" page, where xowiki appears under applications, the url is wiki. i just tried this, also with subsite, and i saw no problem... is "mysite" the host or a name of the subsite? do you have already xowiki pages there? what happens, if you mount it a second time e.g. as woki instead if wiki? can you get to the admin page (mysite/wiki/admin/) of xowiki?
Collapse
23: Re: XoWiki 0.36 (response to 22)
Posted by Michael Steigman on 09/08/06 06:59 AM
mysite is the host. So I have mounted xowiki at mysite.com/wiki. However, I am using the host-node map so myhost.com is actually mainsite.com/mysite. Just occured to me that this might be part of the problem so I tried accessing the package via mainsite and sure enough, everything seems to work fine. This is not a possible solution for me though. Any idea as to why this is happening?
Collapse
24: Re: XoWiki 0.36 (response to 23)
Posted by Dave Bauer on 09/08/06 01:43 PM
Michael

Can you get to wiki/admin/
From there you can edit the Xowiki::object and add

set index_page en:index

Then create a new Xowiki::Page called index.

Then tell us what happens.

Thanks

Collapse
25: Re: XoWiki 0.36 (response to 24)
Posted by Michael Steigman on 09/08/06 07:32 PM
Yes, I can get to wiki/admin but "set index_page en:index" is there already. There appears to be a default index page as well. Everything works OK when I bypass the host-node map.
Collapse
27: Re: XoWiki 0.36 (response to 22)
Posted by Michael Steigman on 09/08/06 09:48 PM
Gustaf,

Just to follow up - Dave B and I just spent a bit of time trying to figure this out in IRC. Perhaps this will info will help:

Here's what appears at the beginning of a good request (i.e., the package is accessed directly, not through a host-node mapped site):

Notice: --starting... /intranet/wiki/en/index  form vars = , ::43182 -> (14ms, 0ms)
Notice: --try en/index -> 0, ::43182 ::xowiki::Package->resolve_request (15ms, 1ms)
Notice: --try en:index -> 43223, ::43182 ::xowiki::Package->resolve_request (16ms, 0ms)

I'm simple typing in mainsite.com/mysite/wiki. Here's the request through a host-node mapped site that generates the error:

Notice: --starting... /wiki/  form vars = , ::262 -> (9ms, 0ms)
Notice: --try wiki/ -> 0, ::262 ::xowiki::Package->resolve_request (10ms, 1ms)
Notice: --try en:wiki/ -> 0, ::262 ::xowiki::Package->resolve_request (11ms, 1ms)
262 is the Main Site instance of acs-subsite and 43182 is the xowiki instance. It seems to us that in a request for the index page or the root url of the package, the invoke method sees /wiki as an object instead of "". The page error itself is generated by the invoke method when this code returns "": set page [my resolve_page [my set object] method].
Collapse
28: Re: XoWiki 0.36 (response to 27)
Posted by Gustaf Neumann on 09/09/06 12:02 AM
do you have xowiki mapped as wiki in the host-node map, or do you have a subsite mapped, that contains xowiki mounted as wiki. The first setup is a problem, since e.g. register etc. are not urls of xowiki. I found a bug with the second case in connection with the host-node map, but i did not get your error messages. Please update xotcl-core from cvs head and look, whether this helps in your case.

all the best
-gustaf

Collapse
29: Re: XoWiki 0.36 (response to 28)
Posted by Michael Steigman on 09/09/06 07:59 PM
The latter. I updated and things are working now. Thanks!

On an unrelated subject, has anyone noticed that when you view xowiki on openacs.org, all the fonts shrink to the point they are almost unreadable, at least on Firefox? I see the same effect on my intranet with xowiki and a couple of other pages, including a basic listbuilder page with filters that I put together. Does anyone know what causes that?

Collapse
30: Re: XoWiki 0.36 (response to 29)
Posted by Michael Steigman on 09/13/06 11:54 PM
Just to follow up on my own observations above, I've found a couple of issues with the styling of xowiki. The first is that it seems to be unconditionally including the generic lists.css and this wipes out any changes folks may have made to list formatting/colors on their sites. I'm just getting started with the package and haven't done anything with xotcl yet but it looks like this is happening in Page's header_stuff proc.

Also, the basic xowiki.css includes this line:

table, td {font: 10px 'Lucida Grande', Geneva, Verdana, Arial, sans-serif; color: #000;}

which sets a base font size for all text in tables. This does not play nicely with the rest of the CSS on my site or on openacs.org. Check out https://openacs.org/xowiki/ and notice how the fonts in the top nav become illegible. This same thing happens on my site. Not sure what the best solution is here but I just deleted the line from my local copy of xowiki.css.

There's one other issue I'd like to bring up and it isn't really xowiki specific. Many packages now require their own navigation (admin/edit/etc.) but each one does it a little differently. Bug tracker, PM and Logger each use a different shade of blue/purple in a fat, page wide nav bar. This isn't going to look nice inside very many master templates. Xowiki has a very simple set of links in gray. I actually prefer this style but whatever the preference, shouldn't we handle this a little better, i.e., more uniformly and in a way that can easily be styled by a site's maintainer? We could start by having packages output a simple list of package nav links and style that at the site level. Thoughts?