TEST - TEST - TEST - TEST
Test of the gmane.org mail-to-usenet gateway
If it works;
There are two different manners to use this list;
- As an ordinary e-mail discussion list
- As a newsgroup
In order to use this list like a newsgroup you must specify the
NNTP-server news.gmane.org at your newsreader. And also subscribe you on
the newsgroup gmane.org.wikimedia.mediawiki
Possibly this can go automatically by selecting the following URL;
For posting to the newsgroup you must be a list member. The first time
you post to the newsgroup you will receive an email for verification of
your email address, which is normal. If you work by means of the
newsgroup you probably no longer wants to receive the messages by email.
To disable email delivery go to "Edit Options".
All the other Wikipedia mailing lists are also available on gmane.
Search for "wikipedia" and "wikimedia" on the list of newsgroups of
My C++ parser is now a working offline browser. This is achieved by
converting a mysql dump of the cur table into an sqlite database once,
then using apache/php as a frontend and a php file calling the compiled
C++ executable, which renders HTML on-the-fly. Browse using your
favourite browser :-)
Why bother with this, if a static HTML version would do the same?
* sqlite databases can be changed, allowing for edits
* Encapsuled database object, can be easily switched to use mysql or any
other database instead of sqlite for use on a website
* Full-text search (which I'll implement next)
Some things that bug me:
* Is there an easy way to call an executable directly from apache,
without the need for a PHP script in-between?
* Is there a no-setup-needed web browser? Some .exe that I can start on
a windows machine, then fire up the web browser, and view/edit my local
On Wednesday, Oct 15, 2003, at 14:02 US/Pacific, Tomoaki Watanabe wrote:
> Hi. I and others are trying to install a mediawiki into iBiblio's
> server for a project, and I would like to get some help.
> It seems that installation requires command-line php, which is not
> available at their server.
> Is there any quick work-around that I am missing? Or is this the way
> it is? (Or am I simply wrong?) I would appreciate any input.
As a workaround for the installer script, you can do it manually. I'm
assuming you've got a way of running batch SQL commands, either through
the mysql command-line client or through some administrative tool such
First, create the database:
CREATE DATABASE wikidb;
(or whatever you'd like to name it)
into this database run the table creation SQL scripts, which are in the
maintenance subdirectory: tables.sql and indexes.sql. These create an
empty wiki database.
You may wish to create a separate MySQL user for the wiki, if so adapt
users.sql to the username and password you want to use and run that on
the table as a MySQL user with administrative privs.
Put wiki.phtml and redirect.phtml into the destination install
directory. You can put the rest of the .php files there if you like (as
the installer does), but I prefer to put them in a separate directory
which I then add to the PHP include path so multiple wikis can be run
from the same code (and the other source files aren't exposed to the
web on the off chance that something weird can be done by executing
Create your LocalSettings.php and put it into the same directory with
wiki.phtml. If the sample file isn't clear, refer to
DefaultSettings.php and override anything that isn't going to turn out
right for you.
Copy the *.js and *.css files from the 'stylesheets' subdirectory into
an appropriate place, which should be accessible as $wgStyleSheetPath.
* the wiki code currently requires that register_globals be on. You may
not wish to turn this on server-wide because some programs may be
insecure using that mode. See http://php.net/register_globals for how
to enable it.
* If your LocalSettings.php contains a password for the database user,
make sure you're not saving backup files that will be accessible via
the web served as text files.
* Interpretation of PHP in the upload directory really should not be
enabled, since anyone could execute arbitrary code as the webserver
user. It's also recommended that you set HTML files to server as plain
text to prevent cookie-stealing attacks. As an example apache config
php_admin_flag engine off
AddType text/plain .html .htm .shtml
* There's a bug in the upload code that may make it possible to delete
files with an appropriately crafted URL. Until this is fixed, you
should comment out the call to unsaveUploadedFile() in
SpecialUpload.php. This may occasionally leave temporary files around
from uploads that are discarded.
* iconv support is required, but it's not compiled into PHP by default.
If you don't have iconv support, you can work around it by defining a
dummy function like so: http://meta.wikipedia.org/wiki/Iconv_hack
* the $wgDebugLogFile must either be writable or be set to "" or you
get ugly error messages.
-- brion vibber (brion @ pobox.com)
Last tarball release on sourceforge was 2003-08-29. This is functional,
but stable branch has changed a bit since then. A new tarball should be
released in the next few days once some code is cleaned up.
To check out the stable release from anonymous CVS:
cvs -d:pserver:email@example.com:/cvsroot/wikipedia login
cvs -z3 -d:pserver:firstname.lastname@example.org:/cvsroot/wikipedia co
-r stable phase3
(Note that SourceForge's anonymous CVS server lags about a day behind
the developers' CVS server.)
-- brion vibber (brion @ pobox.com)