Am I nuts, or did Image deletion get horked somewhere between 20030829
and 20031107? I can't delete images anymore.
Anyone else see this?
~ESP
--
Evan Prodromou <evan(a)wikitravel.org>
Wikitravel - http://www.wikitravel.org/
The free, complete, up-to-date and reliable world-wide travel guide
So, I just wanted to say thanks to the MW team for doing the latest
release. Wikitravel has been using an includes directory outside the
Web directory since we started, and this should make things a little
easier.
One thing I wanted to note is that it's not really necessary to have
the LocalSettings.php file in the Web directory, either. Considering
that it contains a lot of passwords, etc., any attack that could get
that file's source would be pretty high-risk. Not that I know of one
offhand, but still.
Anyways, Wikitravel's layout is like this:
/etc/mediawiki/ - *Settings.php, Language*.php
/usr/local/share/mediawiki/ - All other *.php files
/var/www/wikitravel/wiki/ - *.phtml
/var/www/wikitravel/style/ - stylesheets
Adding /etc/mediawiki/ to the PHP4 include path makes this pretty
straightforward. I have to do some patches to the *.phtml and some of
the includes files so they know to include "LocalSettings.php" rather
than "./LocalSettings.php" or "$IP/Language.php" or whatever.
I can submit this stuff as a patch, if anyone else thinks it'd be a
better way to layout MediaWiki installations.
~ESP
--
Evan Prodromou <evan(a)wikitravel.org>
Wikitravel - http://www.wikitravel.org/
The free, complete, up-to-date and reliable world-wide travel guide
New release contains a number of bug fixes (see release notes) and an
important security update (see below). All sites are strongly
encouraged to upgrade, or use the workarounds described below.
Release notes:
http://sourceforge.net/project/shownotes.php?release_id=198060
Download:
http://prdownloads.sourceforge.net/wikipedia/mediawiki-20031117.tar.gz?
download
Previous versions of MediaWiki contained a flaw that could be exploited
in some configurations to execute arbitrary PHP code on the server if
the *.php files are located in a web-accessible directory and are
runnable through the PHP interpreter. This likely includes most
installations.
If you can't upgrade immediately, you should be able to easily
substantially reduce the risk by doing one or more of the following:
* Leave just LocalSettings.php and the *.phtml files exposed to the
web, moving the other *.php files into a directory that's not exposed
to the web; set $IP to point to this directory in LocalSettings.php.
-or-
* Remove the "$IP/" or "{$IP}/" from all include() and include_once()
statements, keeping the *.php and *.phtml files in one place.
* Explicitly disallow access to all the *.php files in the web server.
* Configure the server to run only *.phtml files through PHP, and not
*.php. (If you do this, be sure your database passwords are not exposed
through LocalSettings.php!)
-- brion vibber (brion @ pobox.com)
Hello all,
I've just finished upgrading to the latest release, most things seem to
be working as expected but there are a few little problems:
* The Message that should appear telling people that they can't edit
because the database is locked doesn't work. Instead you get "Fatal
error: Call to undefined function: file_get_contents() in
/home/sca/public_html/cunnan/OutputPage.php on line 484"
* The misspellings tool is giving false positives.
http://www.sca.org.au/cunnan/wiki.phtml?title=Special:
Maintenance&subfunction=mispeelings shows spelling mistakes on
http://www.sca.org.au/cunnan/wiki/Rosewater that are not there. (this
was happening before the upgrade as well).
* The article count has started going up again after having stopped
around 794 before the upgrade. What is the current definition of an
article?
As for the upgrade itself:
* running upgrade.php gave the following output: "ALTER TABLE ipblocks
ADD ipb_auto tinyint(1) NOT NULL default '0', ADD ipb_id int(8) NOT
NULL auto_increment,ADD PRIMARY KEY (ipb_id);
Creating interwiki table:
** error around line 1-10 in maintenance/archives/patch-interwiki.sql:
You have an error in your SQL syntax near ';
' at line 7
ok
Adding default interwiki definitions:
** error around line 1-110 in maintenance/interwiki.sql: You have an
error in your SQL syntax near ';
' at line 108
ok
Updating indexes to 20031107:
** error around line 1-9 in maintenance/archives/patch-indexes.sql: You
have an error in your SQL syntax near ';
' at line 4
ok
Copying files...
Done." Running the sql scripts manually fixed this.
* Upgrade.php copied the wikipedia logo over my custom logo.
Tobin.
Using checkout -r stable from 11/12/03, I created a new installation. Install.php processed without errors or warnings. When first connecting to the site, I added a few test pages. Later when trying to search these pages, I was unable to retrieve any results. I noticed the default namespaces search included Special, but did not include (Main). But, even after checking (Main) I am still unable to retrieve any search results. Bug? Or, do I need to enable something in a config file?
System info:
Linux 2.4.2
PHP 4.3.1
Apache 1.3.27
MySQL 3.23.55
Thanks for you help.
--
__________________________________________________________
Sign-up for your own personalized E-mail at Mail.comhttp://www.mail.com/?sr=signup
Search Smarter - get the new eXact Search Bar for free!
http://www.exactsearchbar.com/
Hi,
I'm trying to install mediawiki-20031107.tar.gz
(https://sourceforge.net/project/shownotes.php?release_id=196082) on a
Debian GNU/Linux testing/unstable box. System configuration: Kernel
2.4.22-xfs SMP, PHP4 4:4.1.2-6, Apache httpd 1.3.26-0woody3, MySQL
server 3.23.49-8.5. The Debian package php4-cgi is installed; the httpd
and php are working properly.
The install.php script starts installing WikiMedia in /var/www/wiki, as
instructed in AdminSettings.php; then it claims to create the database
"wikidb" and asks for the database's root password. After typing it in,
the script seems to hang in a loop, saying: "Warning: Wrong parameter
count for fgets() in /root/MediaWiki-Install/install.php on line 197".
This references to the following section in install.php:
while ( ! feof( $fp ) ) {
$line = trim( fgets( $fp ) );
$sl = strlen( $line ) - 1;
...
fclose( $fp );
Several files were being copied to /var/www/wiki/, including the
directories ../style and ../upload. But, in MySQL monitor, "show
databases" finds no "wikidb".
I'm not sure if this is a bug or if I'm doing something wrong; if it's
really line 197, maybe the fgets() statement is missing a second
parameter; this should be optional beginning with PHP 4.2.0 according to
the docs (I'm running PHP4 4:4.1.2-6 and INSTALL recommends PHP 4.3.2 or
later). But, of course, maybe I'm doing something else wrong.
However, is there a workaround for this, or should I try to manually set
up MediaWiki according to the Brion Vibber's post
(http://mail.wikipedia.org/pipermail/mediawiki-l/2003-October/000004.html)?
Thanks & greetings,
-asb
So, this is yet more noodling wishlist stuff I've been thinking about
for MediaWiki which I wanted to throw up for discussion.
Here's my problem. Let's say I'm reading a Wikitravel article about
Venice because I intend to go there. I want to print out the article
or download it to my PDA. Now, a trip to Venice is going to require
more than just the Venice city guide. I should also know about the
Italian language, the money used in Italy, visa requirements, and
perhaps about the region around Venice.
It would be possible to include all that information on the same page,
but since there are hundreds of cities in Italy, each needing the same
info, it would get unwieldy pretty quickly. For Wikitravel, we keep
country-wide info in the country page, phrasebooks in another page,
and so on. So, it would be nice if, when I choose to print the
[[Venice]] article, the Wikitravel software would suggest that I also
print out [[Italy]] and [[Veneto]] (the region Venice is in) and
[[Italian phrasebook]], which I could optionally do.
The question is then: how would the software know that these articles
are related at all? It could try to follow the links in the article,
but those might point to very loosely-related articles (say, there
might be some text pointing out that Venice has canals much like
[[Amsterdam]]). It also gets redundant saying that if you're in an
Italian city, you're in [[Italy]] and you should check out our
[[Italian phrasebook]] and by the way [[Italy]] is part of [[Europe]]
and...
There are other options, though. Metadata systems often declare
relationships between individual items. For example, the <LINK> tag in
HTML specifies sibling and parent page relationships. Dublin Core has
a "Relation" specifier that can specify "Is Part Of" and "References"
relationships, among others.
We have a system for tagging related articles in MediaWiki already --
interlanguage links. What I propose is that this system get expanded
to include metadata links to other articles in the same MediaWiki
system. For example, I could declare that [[Venice]] is-part-of
[[Veneto]], which in turn is-part-of [[Italy]]. I could also point out
that [[Italy]] is-related-to the [[Italian phrasebook]].
Now, my automatic suggestion tool only needs to navigate these
relationships instead of all the visible links in the page. The
related articles could also appear on the Web rendering in the same
way interlanguage links do -- so that I don't have to interrupt the
prose in the article to give "See also" style links.
I haven't developed this idea out fully, so I don't have a really good
syntax suggestion. I think the best I can come up with is something
like the interlanguage links, such as:
* [[meta:is-part-of:Veneto]] (for the Venice page)
* [[meta:has-part:Venice]] (for the Veneto page)
* [[meta:is-part-of:Italy]] (for the Veneto page)
* [[meta:related:Italian phrasebook]] (for the Italy page)
These would be kind of abstract, but usable on any MediaWiki
system. For example, it'd also work for showing that [[History of
Canada]] is somehow a part of the article on [[Canada]]. We could
probably just borrow the applicable Dublin Core names (minus stuff
about versioning and replacing, which don't seem that applicable for
MediaWiki articles).
It would also be nice to have article relationships specific to the
MediaWiki installation, like, for Wikitravel:
* [[meta:phrasebook:Italian phrasebook]]
* [[meta:country:Italy]]
* [[meta:region:Veneto]]
...where each installation could configure how to render the
metatags. It might even be possible to fit the interwiki pages into
this more general scheme.
Anyways, this is something I'd like to get into doing for MediaWiki,
since it's kind of important for us on Wikitravel. Any ideas,
comments, precedents, suggestions?
Thanks,
~ESP
--
Evan Prodromou <evan(a)wikitravel.org>
Wikitravel - http://www.wikitravel.org/
The free, complete, up-to-date and reliable world-wide travel guide
I've packaged up the current state of the stable branch from CVS and
put out a new release. There are a number of fixes and changes from the
20030829 release, so please do read the release notes!
Release notes and download:
https://sourceforge.net/project/shownotes.php?release_id=196082
Updating should be fairly straightforward: if you used the install.php
script, copy in your LocalSettings.php and AdminSettings.php and run
update.php, otherwise copy things to the destination directory manually
and run the SQL updaters noted in the release notes.
-- brion vibber (brion @ pobox.com)
So, the main reason I'm writing to this list because I want to see if
it's a discussion list or just for announcements. I think Brion said
it should be used for discussion of the MediaWiki software, not
wikitech-l.
But, to make this post something better than just the word "test", I
figure I should ask a question. Here goes:
It seems on Wikipedia that there are really only a few idioms that are
mainly used for adding images: left-float, right-float, centered, and
interpolated into text. Considering that these are all done with some
hairy HTML markup, I'm wondering if it wouldn't make sense to add some
Wiki markup for these standard items.
Has anyone done proposals for doing this? Something like, I dunno:
[[Image:left:name_of_image|alt text|caption]]
[[Image:right:name_of_image|alt text|caption]]
[[Image:center:name_of_image|alt text|caption]]
[[Image:name_of_image|alt text|caption]]
...where the alt text and caption are optional?
I haven't taken much of a look at the Wiki markup rendering stuff, but
I figure that whatever renders [[Image:]] links right now could
probably be altered to handle syntax like the above.
Any ideas? Different syntax? I might start whacking on this, and
submit a patch.
~ESP
--
Evan Prodromou <evan(a)wikitravel.org>
Wikitravel - http://www.wikitravel.org/
The free, complete, up-to-date and reliable world-wide travel guide
On Nov 3, 2003, at 14:52, Freerk Ohling wrote:
> Hello wikitech-l,
>
> I am trying to install the mediawiki-20030829.tar.gz on my
> webspace as a readonly mirror of the german cur database.
> I already got it managed to insert the 92MB mysqldump
> of the german cur_table into my mysql database.
>
> But I can't install the mediawiki. I do have a webspace packet
> with 200mb space, PHP 4.2.1, Apache 1.3.23 and MySQL
> 3.23.51-log on Linux 2.4.9-31 RedHat7.2. I also have phpMyAdmin
> 2.5.1 (but the mediawiki INSTALL file says: Recommended versions
> are: Apache 1.3.27 or later; MySQL 4.0.13 or later; PHP 4.3.2 or
> later.)
-snip-
(If you haven't already, you may wish to sign up for the mediawiki-l
mailing list, we're hoping to split setup help and release
announcements off from the day-to-day running-of-Wikipedia and active
development stuff here in wikitech-l.)
You may have trouble with that old a PHP, some things may need to be
replaced with older equivalents.
It should be possible to set it up generally, but not with the install
script.
All the *.php files from includes/ and languages/ (or at least, just he
languages/ files you need) need to go into a single install directory,
for simplicity this may be the place where you put wiki.phtml and
LocalSettings.php.
To create the database... first, in phpMyAdmin rename the existing
'cur' table to something else, say 'cur2', for the meantime. Now, in
phpMyAdmin you should have the option to run a sequence of sql
commands. I forget if there's a script upload option or if you just
have to paste in, but take maintenance/tables.sql and
maintenance/indexes.sql and execute all the commands in them; this
creates the table layout.
Now, get rid of the newly created 'cur' table and rename 'cur2' back to
'cur'.
If everything's set up right, you now should be able to browse pages.
Some features won't work (whatlinkshere, recentchangeslinked, nothing
yet in recentchanges, search won't work) and without the link tables
it'll be slightly less efficient loading pages, as it has to check the
existence of every linked page individually. "In theory" if you put the
'maintenance' subdirectory in there, and you've got an
AdminSettings.php, you can run the maintenance/rebuild-all.php script.
It may be buggy and may not work at all, be warned, and you really
_really_ shouldn't leave the maintenance scripts web-accessible.
-- brion vibber (brion @ pobox.com)