Home
The Toolkit for Online Communities
17219 Community Members, 1 member online, 2028 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Development : Rename OpenACS Administration to Site-Wide Admin?

Forum OpenACS Development: Rename OpenACS Administration to Site-Wide Admin?

Icon of envelope Request notifications

I think there'd be less confusion about the difference between
subsite admin pages and /acs-admin if we renamed acs-admin
from "OpenACS Administration" to "Site-Wide Administration".

Any objections?

/Lars

Collapse
Posted by Don Baccus on
Not from me!
Collapse
Posted by Jun Yamog on
Hi Lars,

Ok... I hope this is just a trivial change unlike the context id change :).

Here is a related thread

http://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0005Q2&topic_id=12&topic=OpenACS%204%2e0%20Design

Don't tell me you have forgotten about this too :)

Collapse
Posted by Lars Pind on
It is indeed a trivial change ... and yes, I'd forgotten about that thread, too. I'm glad that you are willing to serve as my extended memory :)

/Lars

Collapse
Posted by Lars Pind on
Alright, this is done. It only works on a fresh install, though. Old installations will have to rename the site node themselves, though that's pretty trivial to do.

/Lars

Collapse
Posted by Stan Kaufman on
I just updated from CVS and now I get this error when trying to access /acs-admin/

Can this possibly be related to something you just did?

Request Error

       unknown command "instance_name":  should be authpassword, authuser, close, content, contentlength, driver, flags, form, headers, host, isconnected, location, method, outputheaders, peeraddr, peerport, port, protocol, url, query, server, sock, start, status, urlc, urlv, or version
           while executing
       "ns_conn $var"
           ("-get" arm line 5)
           invoked from within
       "switch -- $flag {
           -connected_p {
             return [info exists ad_conn(request)]
           }

           -set {
             set ad_conn($var) [lindex $args 2]
           }

          ..."
           (procedure "ad_conn" line 12)
           invoked from within
       "ad_conn instance_name"
           invoked from within
       "set title "[ad_conn instance_name] for [ad_system_name]""
           ("uplevel" body line 9)
           invoked from within
       "uplevel {
                 ad_page_contract {
           @author Bryan Quinn (bquinn@arsdigita.com)

           @creation-date August 15, 2000
           @cvs-id $Id: index.tcl,v 1...."
           (procedure "code::tcl::/var/web/epimetrics-dev/packages/acs-admin/www/in..." line 2)
           invoked from within
       "code::tcl::$__adp_stub"
           invoked from within
       "if { [file exists $__adp_stub.tcl] } {

             # ensure that data source preparation procedure exists and is up-to-date
             adp_init tcl $__adp_stub
       ..."
           ("uplevel" body line 3)
           invoked from within
       "uplevel {

           if { [file exists $__adp_stub.tcl] } {

             # ensure that data source preparation procedure exists and is up-to-date
             adp_init t..."
           (procedure "adp_prepare" line 2)
           invoked from within
       "adp_prepare "
           (procedure "template::adp_parse" line 30)
           invoked from within
       "template::adp_parse [file root [ad_conn file]] {}"
           (procedure "adp_parse_ad_conn_file" line 7)
           invoked from within
       "$handler"
           ("uplevel" body line 2)
           invoked from within
       "uplevel $code"
           invoked from within
       "ad_try {
               $handler
             } ad_script_abort val {
               # do nothing
             }"
           invoked from within
       "rp_serve_concrete_file [ad_conn file]"
           (procedure "rp_serve_abstract_file" line 60)
           invoked from within
       "rp_serve_abstract_file "$root/$path""
           ("uplevel" body line 2)
           invoked from within
       "uplevel $code"
           invoked from within
       "ad_try {
               rp_serve_abstract_file "$root/$path"
               set tcl_url2file([ad_conn url]) [ad_conn file]
               set tcl_url2path_info([ad_conn url]) [ad_conn path_inf..."

Collapse
Posted by Lars Pind on
Yes. You need to update your acs-tcl package as well.

/Lars

Collapse
Posted by Stan Kaufman on
Hmmm...do you mean I need to drop the database and reinstall? Restarting the server with the current CVS checkout completely hoses the site -- all I get now is an error in the browser: "The document contained no data." from any url.

Here is the error I presume is the clue:

debug: RP (9.866 ms): rp_filter: setting up request: GET / 
[16/Sep/2002:14:26:44][26713.5126][-conn2-] Error: tclop: invalid return code from filter proc 'can't read "node(instance_name)": no such element in array': must be filter_ok, filter_return, or filter_break

Collapse
Posted by Lars Pind on
I added instance_name to packages/acs-tcl/tcl/site-nodes-procs* and request-procssor-procs.tcl yesterday (I think).

request-processor-procs.tcl 1.20

site-nodes-procs.tcl 1.16

-postgresql.xql 1.17

-oracle.xql 1.11

Not tested on Oracle, though. Could that be the problem?

/Lars

Collapse
Posted by Stan Kaufman on
Nope, something's badly amiss; a fresh reinstall proceeds fine -- the kernel installs OK, the core services/packages also without error, likewise the site-wide admin and the system information.

Once I reach the "OpenACS Installation Complete" page, we're right back to where we began: "The document contained no data" and the same problem with 'can't read "node(instance_name)"' in the error logs.

Collapse
Posted by Stan Kaufman on
I'm using PG not Oracle. Guess I need to roll back to an earlier commit? Jeez, that means I'm going to have to figure out about 50% more about CVS than I know right now.
Collapse
Posted by Jun Yamog on
Hi Stan,

I just cvs updated my copy.  And did a fresh install my plain vanilla OpenACS runs fine.  Its using PG.

Collapse
Posted by Lars Pind on
Are you still having this problem?

Is it the installer that fails on the last page, or is it the /acs-admin/index page that fails when you restart after installation?

Do you have this line:

    ad_conn -set instance_name $node(instance_name)

in your packages/acs-tcl/tcl/request-processor-procs.tcl file?

I'm puzzled.

/Lars

Collapse
Posted by Ola Hansson on
Perhaps you need to do a cvs up -PAd to unset a date tag (-D) if you reverted to prior revisions?
Collapse
Posted by Stan Kaufman on
Lars, I also was puzzled, and still am -- but for a happier reason.

Encouraged by Jun's report of a successful install, I blew away my local CVS repository completely and started fresh (using your *very* helpful guide at http://www.pinds.com/acs-tips/openacs-setup -- thanks!!) from the openacs.org:/cvsroot.

This time the OACS site comes up just fine. That is why I'm puzzled -- I see from the Commits forum that there were no relevant changes to the CVS tree between last night when I last updated my old checked-out project and the new project I checked out this morning.

Furthermore, before I blew away the old one, I confirmed that the line setting instance_name in /packages/acs-tcl/tcl/request-processor-procs.tcl was in fact there.

Given this, I can't imagine what was going on yesterday, and I apologize for wasting the bandwidth on a problem that fixed itself. There must be something that I was doing with CVS that screwed things up, though what that might be eludes me. Looks like I'm going to have to quit treating CVS as a black box and actually learn what's going on inside it.

Thanks again!

Collapse
Posted by Lars Pind on
Glad it's working now :)

/Lars

Collapse
Posted by C. R. Oldham on
Given this, I can't imagine what was going on yesterday, and I apologize for wasting the bandwidth on a problem that fixed itself.

Stan,

Don't apologize--your posting detailed the same problems we were having, so that way we knew that it wasn't something we had done in the CVS update. And like you, this morning all is well, inexplicably.

Thanks for taking the time to post.

Collapse
Posted by Stan Kaufman on
Interesting. Misery loves company I guess.

But this raises in my mind the question of tracking CVS closely. How often have mysterious problems like this happened? Theoretically CVS should make it possible to roll backwards and forwards to different versions to get around problems like this (as well as to make it easy or at least possible to merge the canonical fixes by those with commit powers with one's own custom modifications).

But in reality, how well does this work? I've seen posts elsewhere about the hassles of reconciling one's own code with the moving target of the cvs code base. How do people make this work?

Collapse
Posted by C. R. Oldham on
I've seen posts elsewhere about the hassles of reconciling one's own code with the moving target of the cvs code base. How do people make this work?

Not to be flippant, but the answer to your question is "very carefully".

Here's what I've been doing lately. I check out a copy of openacs-4 from the repo with the -kk switch (don't expand tags), and also a copy of our own installation from our CVS repo with -kk. Then I use Beyond Compare (an incredible diff utility--I can't speak highly enough about it, too bad it's Windows only) to compare the two trees. BC lets me compare the differences and copy files that have changed between the two trees. This way I can see if the data models have changed (without an accompanying upgrade script) and make the changes in our schema if necessary. Then I commit changes to our CVS repo.

Yes, it's a pain. The more cvs-ish option of doing a 'cvs import' doesn't let me see directly what has changed, though it would be faster. It's been taking me about an hour a day to track CVS this past week.

Collapse
Posted by Jeff Davis on
One thing to keep in mind when talking about tracking CVS is that
you should not be surprised when things break on the head.
I think everything said about the nightly tarballs
( http://openacs.org/sdm/nightly-tarballs.tcl?package_id=9 )
goes double for life on the head (the it might not work, waste
of time if you don't know what you are doing, etc).

Obviously these postings about problems with the cvs checkout
go counter to what's stated on the tarball page, but I for one
find it helpful to hear if something is broken and can usually tell
right away if I am the one to blame.

You should also realize we are trying to get things in for the
code freeze on monday for the 4.6 release so things are
appreciably less stable than is typical.

I recently discovered M-x cvs-examine in Emacs. This command lets you examine a CVS directory and its subdirectories and provides an excellent dired overview of all files that differ from the repo. As with any dired view you can then select files for (in this case CVS) operations.

cvs-examine is part of the Emacs front end to CVS 1.9 and later and is included with Emacs 21. See pcl-cvs in the Emacs help for more info.