I've setup localsettings.php and createdb.php to use the correct
database but I continue recieving the following message.
"Parse error: parse error, unexpected T_VARIABLE in
/home/tobin/public_html/LocalSettings.php on line 10
Creating new tables. Could not select database
No Database Selected (tried non-p connect)
If this error persists after reloading and clearing your browser cache,
please notify the Wikipedia developers."
Server Information:
Operating System Linux
Kernel Version 2.4.7-10
Last Reboot 19days, 22:22min
Apache Version 1.3.27 (Unix)
Perl Version 5.006001
Perl Path /usr/bin/perl
Sendmail Path /usr/sbin/sendmail
Perl Modules Click to View
PHP Version 4.2.2
MySQL Version 3.23.54
cPanel Version 6.0.0-EDGE
cPanel Build 56
cPanel Theme cPanel X v1.4
Thanks in advance
Tobin Richard
The storage of old article revisions on Wikipedia is taking a few gigs
now, and getting larger.
Occasional alterations made to the old table's structure require a
duplicate temporary table; the downside of Innodb's storage management
is that while its storage pool can grow automatically, it doesn't
shrink! This leaves us with a few gigs of wasted space on the hard drive
that aren't available for other resources -- log files, uploads, etc
which might be needed. Frankly, we're running a little tight right now.
As the table grows, the doubled space requirements of maintenance time
are similarly going to increase. And even if we switch back to a db
backend that allows reclaiming unused space, we need to keep that space
available for when it comes time to add a field or adjust the indexes.
We could store old revisions as binary blobs compressed with gzip
instead of raw text; this should reduce overall storage requirements by
well over 50%. Performance shouldn't be harmed significantly, as old
versions are loaded relatively rarely and saved only once each.
Pro:
* Saves disk space!
* Should reduce maintenance downtime on table alterations, with less
data to copy around.
Con:
* Old revision contents wouldn't be searchable with straight SQL queries
(LIKE etc).
* Slight speed degredation due to compression/decompression; makes the
code a little more complex.
* PHP needs to be recompiled with zlib support; we may have to make it
optional for third-party sites.
* The downloadable dumps may actually get bigger, depending on how
compressors interact.
-- brion vibber (brion @ pobox.com)
I will describe my idea of creating categories through voting
in points (still a kind of draft):
// implementation notes are marked as here
Vote for category link on every page can lead
to Add keywords to the article you edit
// only one extra box needed
Software will count keywords as votes for particular categories.
// only one table for categories is needed
// cat_id, cat_name, cat_votes
// keywords can have mulptiple words like "physical anthropology"
// so some separator is needed
Keywords added by person who done some edit are weighted higher
e.g. like 5 'viewers votes'.
// this extra box can appear under editing pane like
// the description box appears
It is not obligatory to add any keyword in this case.
At the top of the article all categories can be presented
in the order of descending number of votes (let's say top 10).
If you disagree with the fact of a given article being in some category
or so high in the hierarchy preceed a keyword with minus sign.
Everybody (and especially admins) can view the whole list of categories
that a given article was assigned to (the number of votes are presented as well).
// maybe Special:Assignedto page?
Admins can remove real rubbish links to categories (including vandalism).
// delete link on said Special:Assignedto page (or a series of check-boxes)
Removed links are logged on a special page - that way everyone can check
if some admin overuses his rights.
=== Sifter extension ===
Another voting system could be implemented for "certified"
users who can vote for quality. This could incorporate "lighter" idea
of sifter into Wikipedia.
This won't have influence on editing capabilities of anyone.
Sister voting system, third one, could be implemented
for "certified" users who will vote for their category scheme.
Everyone can select either first or the second category scheme
or both when viewing article. As well, anyone can select quality
note to be rendered on the page.
----
Open problems:
- Will people like it?
- How filter RecentChanges with so many categories?
- What if a vandal, insane user, etc edits just to promote an article
in a given category? How to decrease voting counters?
- Should we stick to stif tree-like structures?
(Inclusion of one category into another can be done through...
voting on Category:Foobar_category page that describes
this particular category)
Regards,
Youandme
----------------------------------------------------------
Think fast! This message will self-forget in 15 minutes ;)
Something is wrong with contents of math table on Wikipedias.
On Polish and French math_html is empty, and math_mathml usually
contains what was supposed to go to math_html but without first
character.
On Polish Wikipedia all new formulas are rendered to PNGs now
because of that.
No such problem on test Wikipedia.
Maybe it's problem with incomplete upgrade ?
Brion: have you replaced binaries in /apache/htdocs*/w/math/ directories
with new versions ?
Hi everyone,
I am quite new to Wikipedia and wanted to set up a testing server for
our student organisation using the PHP script. I know some PHP and
MySQL, but don't have experiance with a CVS.
To get a snapshot of the project I used the command "cvs -d
:pserver:anonymous@cvs.wikipedia.sourceforge.net:/cvsroot/wikipedia
checkout phpwiki/newcodebase" as stated here:
http://de.wikipedia.org/wiki/Wikipedia%3APhase_III_Software (at the
bottom of the page).
After uploading everything on the server and adjusting LocalSettings.php
I copied all the files of the maintenance dir to the others and ran
createdb.php. Everything seemed to work fine and the tables were
installed. I tried to edit the Startpage and got the following error
message:
"A database query syntax error has occurred. This could be because of an
illegal search query (see Searching Wikipedia), or it may indicate a bug
in the software. The last attempted database query was:
INSERT INTO cur
(cur_namespace,cur_title,cur_text,cur_comment,cur_user,cur_timestamp,cur_minor_edit,cur_counter,cur_restrictions,cur_user_text,cur_is_redirect,cur_is_new,cur_random,inverse_timestamp)
VALUES (0,'Hauptseite', 'test', '', '0', '20030217212253', 0, 0, '',
'192.168.68.1', 0, 1, RAND(), '79969782787746')
from within function "Article::insertNewArticle". MySQL returned error
"1054: Unknown column 'cur_random' in 'field list'"."
After checking the tables I found out that the row cur_random does not
exist. I checked the buildtables.inc in the maintenance dir and found
out that there is no cur_random field set up during db creation.
Is it possible to download a kind of stable version of wikipedia via CVS?
Thanks for your help
Thomas
PS: The layout looks a little bit weird with Mozilla and I am unable to
access the top items (drop down menu, talk, log in), is that normal?
Brion Vibber wrote:
>
>Cologne Blue is still in desperate need of work, but my todo list is
>waaay too long and I haven't got to it yet. Others are welcome to pitch
>in...
>
>
If someone converts the PHP to using HTML templates, I'll do the HTML &
CSS work on Cologne blue & the other skins too :-)
(oops. went to the wrong list first time. sorry)
[pl]
Takie przejscie wymaga:
1. konsensusu (czy ktos zglasza sprzeciw ?)
2. operacji na ustawieniach skryptu Wikipedii PL
3. odwrocenia kolejnosci przekierowan w DNSie
z www.wikipedia.pl->pl.wikipedia.org na pl.wikipedia.org->www.wikipedia.pl
Kto administruje tymi nazwami ?
Czy te osoby moglyby ustalic jak wykonac punkt 3-ci ?
[en]
We need:
1. concensus (is anybody against ?)
2. changing settings of Wikipedia script
3. reversing DNS redirects from
www.wikipedia.pl->pl.wikipedia.org to pl.wikipedia.org->www.wikipedia.pl
Who aministrates both names ?
Could they please agree how to do the 3rd part ?
IMHO when I write
[[Wikipedia:Policies and guidelines|]]
this should not be turned into
[[Wikipedia:Policies and guidelines|Policies and guidelines]]
after saving. Instead, the link should stay the same, but the "Wikipedia:"
part should still be omitted. Otherwise, on many pages that have lots of
links with the namespace prefix omitted, you get lots and lots and lots of
redundant information, and it becomes very hard to read. The same goes for
[[The Lord of the Rings: The Fellowship of the Ring (movie)|]]
which should not become
[[The Lord of the Rings: The Fellowship of the Ring (movie)|The
Lord of the Rings: The Fellowship of the Ring]].
The (movie) part should instead be omitted "on the fly". This also makes
it easier to change the pipe trick behavior should that ever be necessary.
I believe this behavior would be more intuitive. In fact, I expected it to
work this way and was surprised when I noticed that it doesn't.
A comparison would be the "slash trick" which I have developed for
subpages.
[[/foo/]]
becomes a link called "foo" to the subpage /foo of the current page, but
it is *not* converted into [[/foo|foo]] for this purpose.
Thoughts?
Regards,
Erik
I'm all in favor of an eventual transition to some method of
categorization, or even some more general method of including what I
would call 'metadata'. (Someone else talked about objects in this
context.)
I just caution that we should not just proceed to do this in code.
This will be a major move, and it needs to be carefully discussed
first. One main thing we want to be careful of is making some
decision today that takes us down a path for the future that's hard to
generalize.
Erik Moeller wrote:
>Thoughts? Objections? I consider implementing this myself if nobody cares
>enough to do it.
I think there are some problems with the idea of creating a separate
category namespace.
(1) It creates an ambiguation problem. For example, should an article
about "events in U.S. history" appear in the main Wikipedia namespace
or in the the "category" namespace?
(2) It could fragment the Wikipedia. All of the other namespaces --
Talk, User, Wikipedia, etc. -- serve some sort of "meta" function
with respect to the actual "encyclopedia" part of Wikipedia, so it
makes sense to compartmentalize them in a separate namespace. This
isn't the case with "category" articles, which are themselves part of
the encyclopedia.
(3)
In addition to these problems, creating a category namespace only
provides limited utility. Thinking ahead a bit, I think something
more flexible and powerful would better serve the project as it grows
and matures. Rather than simply creating a category namespace, I
think it would be better to develop a system of object typing like
the one I described awhile ago. The Wiki syntax could be expanded to
include ways of marking object types and properties, which could then
be used in turn to support data mining. For example, if we had a way
of marking certain articles as "people" objects with properties such
as first name, last name, date of birth, etc., the software could
autogenerate lists of people sorted either alphabetically or by date
of birth. Also, the autogenerated lists could include selected
properties extracted from each of the articles in the list. Here's
some pseudocode to give an idea of how someone might generate a list
of U.S. presidents:
<LIST ORDER=year of inauguration>*'''[U.S. President->name]''', [U.S.
President->year of inauguration], [U.S. President->party affiliation]
</LIST>
The idea is that this would expand to the equivalent of:
*'''James Earl Carter''', 1976, Democrat
*'''Ronald Wilson Reagan''', 1980, Republican
*'''George Herbert Walker Bush''', 1988, Republican
*'''William Jefferson Clinton''', 1992, Democrat
*'''George W. Bush''', 2000, Republican
This sort of thing could be coded into Wikipedia with an object
model, but I don't see how creating a category namespace would make
it possible.
--
--------------------------------
| Sheldon Rampton
| Editor, PR Watch (www.prwatch.org)
| Author of books including:
| Friends In Deed: The Story of US-Nicaragua Sister Cities
| Toxic Sludge Is Good For You
| Mad Cow USA
| Trust Us, We're Experts
--------------------------------