Remind me: What was it about Jake's web host's setup that precluded migrating the old wiki to it?
Is this something that simply throwing a few bucks a month at a different host would solve?
I don't know much about Jake's site to comment on that.
It would be useful to know what technology we could take advantage of. For example if we had a Tomcat (or equiv) there is a great commercial quality Wiki (http://www.atlassian.com/confluence) that we could probably get through the Open Source license. (We are effectively Open Source music). I use it at work an it is very capable. However it requires a Java web environment.
Another area that could be useful would be some database technology such as MySQL or even better Postgres. I think some of the content on the site could be better maintained as links in a database for better organization and querying ability. It also can help with managing versioning of information.
I think that we have a couple different kinds of content that we need to work with in the site. Discussion threads (best managed by forums), song and descriptive content (best managed by a wiki), and classification, versioning, and linkage of different resources such as mp3s and image files (album covers, etc).
It would nice if we could take advantage of all of these things and integrate them together with a web front end. I think the web GUI stuff I have been playing with in the prototype can do a good job if we can design a good layout.
It would also be good to have more integrated support for RSS and such as well.
As you said a few bucks in the right direction of a host could make life easier. My host (www.1and1.com) provides ALOT for about 4 bucks a month. I am sure there are comparable things available.
At the very least I am happy to help prototype anything that I can on my site.
UseMod wiki and its descendants, like the one we were using (I forget the name,) want a hierarchy similar to this:
/root
/cgi-bin
perlapp.pl
/wikidata
/subdirs
/www
(stuff)On Jake's server, the root and the /www are the same, so you can't put the wiki app in ../cgi-bin or create a ../wikidata directory. Or, at least, I can't. Maybe because it's a subdomain, Jake is able to get to a higher-level directory. However, when I created a cgi-bin directory and tried to run some things from there, I got error messages that basically indicated that cgi-bin was more of a system-wide directory, rather than something users got to use.
There's another issue with the old wiki that was independent of which server it ran on: the code is crappy to edit.
If it helps, this is the kind of account I have: http://pair.com/services/web_hosting/advanced.html
Also, there are some statistics for the site here: http://ainaz.pair.com/jwgh/WWW_REPORTS/interrobang.jwgh.org.html
Jake, do they have some kind of log file somewhere? Because I notice there are no reports for keywords used in searches. I suppose we could write something that parsed the log file, though, and accumulated information about searches. Also, about how many times a file has been downloaded, which would be necessary to impliment the download tracker Charlie suggested.
Is there a way to delete entries? At least our own entries?
Yes, in /usr/home/jwgh/www_logs . Do you have access to that? If not then I'll try to figure out how to give it to you.
Charlie:
It can be done from the admin page, but I don't see a way for users to delete their own entries. But I better check in case I disabled that.
Jacob:
No, I have no access to that. I can't get above the web directory. Not sure if a script can or not.
On Dag's Wakaba and Kareha Support Board (http://wakaba.c3.cx/sup/) there's a delete link next to every post. Must be configurable.
Do the links appear now?
Sorry for the delay in responding to this; I have been thinking about it, but didn't get around to investigating it until just now.
It doesn't look like there's an easy way to give your FTP account access to the logs. Probably the simplest way for me to do it would be to create another FTP account specifically to access the logs; if you'd like me to do that then let me know.
I bet that any scripts you create would have access to the logs, though. I can send you a sample file so you can see its format if you want.
Either Pair has added some new features, or I forgot about existing features. As of a few minutes ago I've configured it to hold on to 30 days worth of logs, and not to bother recording anything that appears to be an attempt to exploit IIS security flaws. (Pair uses Apache.) I can change any of this if you'd prefer. (Previously it held onto logs forever.) I've also disabled some of the less useful reports that I've had Pair generate for me in the past.
Maybe the scripts have access to the logs. What would the path be?
Oh, wait, nevermind.