Forum OpenACS Development: Xowiki calendar offering ancient navigation?

Notice: --starting... /docwiki/weblog date=1943-07-05 form vars = date 1943-07-05, ::624000 -> (41ms)

Notice: --starting... /xowiki/weblog date=2001-11-04 form vars = date 2001-11-04, ::265634 -> (18ms)

and more like it.

Looks like this could be a problem if a spider aggressively visits the calendar. Of course the regular calendar has the same problem. I noticed mainly because, in this case, the data got all the way back to 1943, when means someone was pretty busy.

Should have have a configurable "start date" and possibly future end date for browsing the calendar if they are available to the public and search engines? This should be done for calendar package as well as xowiki calendar widget, I believe.

Collapse
Posted by Gustaf Neumann on
yes, these are from spiders, thanks for noting. Sometimes having an overly verbose package like xowiki has some advantages...

The problem is now fixed for xowiki in CVS HEAD and on www.openacs.org by specifying the offered time range for the weblog-mini-calendar from 2006 (birth of xowiki) to 1 year into the future from the actual date.

The problem exists as well for the link to the past as for link to the future. Adding two parameters for every calendar instance in openacs/dotlrn seems quite heavy, but in the general case, we don't have much options...

Collapse
Posted by Dave Bauer on
I think I have a simple solution that covers most, maybe all cases.

For users who are not logged in, we can just use the first and last items in the calendar to constrain the navigation.

Collapse
Posted by Gustaf Neumann on
ok, i have committed a version that calculates the time borders from the database. min/max queries are rather expensive, but it seems not prohibitively slow.
Collapse
Posted by Gustaf Neumann on
There is a related problem with forums. About 70% of the google-bot queries for forums are of the form /forums/message-post?parent_id=1013710, which will certainly fail. These requests are coming from the reply_buttons (per message and per thread)

i have changed this logic on openacs.org, such that (a) permissions(post_p) is used by the included adp chunks for controlling the visibility, and (b) by basing the display of the reply in message-view only on permissions(post_p) (the current code uses "$permissions(post_p) || [ad_conn user_id] == 0"). If there is interest, i can change this on head as well.

Collapse
Posted by Gustaf Neumann on
here is another problem of this category: search.

Googlebot loves search and iterates over all pages offered (it searches e.g. /search/search?q=confusion&search_package_id=&offset=1300). I counted 50 google searches in the last 30 seconds. Maybe the initial query happens, when someone posts a search query to a forum or to a public site.

For now, i have deactivated search for the googlebot on openacs.org. Since every information found via search should as well be found via navigation, there should not be a significant loss of visibity on google. Counterexamples might be file-content, only exposed via search. If people think differently, i have no problem to take this small change back.

Collapse
Posted by Brian Fenton on
I hope you're right Gustaf. I do all my OpenACS searching using Google as I have found the results from an OpenACS search not to be the best.

But let's see how it goes,

Brian