--- Brion Vibber <brion(a)pobox.com> wrote:
> On Nov 19, 2003, at 19:23, Steve Cooney wrote:
> > But Im curious, for SP (or any other MW site) to
> use
> > MW, some specialized modules will have to be made,
> > some of which may not be useful to WP, but may be
> > useful for something else.
> >
> > Should imminently enthustastic and abundant SP
> > developers simply join MW, and get their works
> lost in
> > the shuffle, or can there be project forks in CVS
> > under the MW (still "Wikipedia" on sForge --they
> dont
> > do account transfers, eh?) that are modestly
> > independent and somewhat autonomous?
>
> We could add additional branches in CVS, but they
> would likely be much
> harder to maintain that way instead of just putting
> them right in the
> main dev branch, where people will test them and
> they have half a
> chance of getting maintained and going in the main
> stable distribution.
>
> Useful general-purpose stuff like SVG support and
> annotations should
> certainly go in the main code (and good features
> should also be easy to
> disable where not needed!)
>
> -- brion vibber (brion @ pobox.com)
Ok --but would it be better for MediaWiki if it had
some emphasis on its ability to branch out into
different, customized applications? By this, I mean
that, just as some have pointed out, MediaWiki aspires
to be more than just Wikipedia, and as such, people
will want use-specific packages, perhaps including
cut-down lite wiki versions (but with the benefit of
some newer bells and whistles). I know the whole thing
is actually pretty tiny anyway, though.
Just curious, because it seems to me that MediaWiki
wants to be more of an umbrella for other
non-Wikimedia wikis, and not just a one-trunk deal.
The difference is perceptual, but may effect how
MediaWiki recieves attention from freelancers, who
just want to find free sockets and new directions they
can plug themselves into.
Sincerely,
Stephen Cooney
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
So, the way MediaWiki markup works now, something that looks like
"=this=" gets rendered as "<h1>this</h1>", and something that looks
like "==this==" gets rendered as "<h2>this</h2>", and so on with more
equal signs making deeper HTML header tags.
The problem with this is that the stylesheets we have render <h1> tags
really, really big. It seems like people try to avoid using one- or
even two-equals headers, just because they render outrageously large.
This seems like a bad precedent to me. The equal signs, in my opinion,
should be used more as *logical* section separators than for physical
formatting. I think that the top level of sections in a page should
use one equal sign -- always, without exception -- and subsections of
those sections should use two equal signs, and so on and so forth.
My question is: how can we get the rendering right so "=this=" renders
more neatly, and less obstructively, on a page? One quick-and-dirty
solution is to just have the rendering code shift everything down one
- -- "=this=" becomes "<h2>this</h2>", and "==this==" becomes
"<h3>this</h3>", and so on and so forth.
The problem with that strategy, of course, is that you bottom out at
five section levels, which I personally think is fine for pages at the
granularity of Wikitravel (and Wikipedia, AFAICT). When someone uses
two equal signs for a top-level section header, that's pretty much
what they're doing, anyways.
The other possibility is changing the stylesheets to make h1, h2, h3,
etc. tags somewhat smaller. This seems to be a little less flexible,
wouldn't necessarily work with all browsers, and is harder to get
right.
Suggestions, ideas, comments?
~ESP
- --
Evan Prodromou <evan(a)wikitravel.org>
Wikitravel - http://www.wikitravel.org/
The free, complete, up-to-date and reliable world-wide travel guide
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/u8k8ozwefHAKBVERAs80AKDckW/hkrEFrenm9/iqQ5HfKlWMMACgiAKS
fJc0cdemYDuiyAiGjabOOb0=
=y3nb
-----END PGP SIGNATURE-----
Im starting a new wiki called symbolproject.org -- i'm
wondering if it might be better just to go with
installing the unstable branch just to try it out,
since we're just getting started.
I understand that some people have been waiting months
to get their code up live on wikipedia. Im thinking
that they could get it going right away on
symbolproject.org, and the different project goal
might be interesting to people who want to take a
break from wikipedia-specific development. The
question i have i guess, is to fork mediawiki in
sourceforge cvs or not --maybe this could help
mediawiki development, i dont know.
-Stephen Cooney
__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
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