[I posted this through the nntp interface, but I think my subscription
attempt was wonky, and it never showed up. Hopefully this won't be a dupe.]
Since posting this, I've looked into it a bit more, and it looks like
there is some nascent support for what I want with things like
$wgStylePath, but it seems like there are still issues with stuff like
mixing of skins/common in the same directory as custom skins, etc., so I
think/hope the question is still worth asking. I'm still digging to see
what it would take to completely separate out the local from svn stuff.
Chris
-------- Original Message --------
Subject: mediawiki source code directory layout and customization
Date: Sun, 05 Aug 2007 14:00:11 -0700
From: Chris Hecker <checker(a)d6.com>
Newsgroups: gmane.science.linguistics.wikipedia.technical
I did a bit of searching in the archive and didn't find anything on this
topic, but I'm sure it's been discussed before, so my apologies if this
is redundant.
Would it be possible and is there any interest in "slightly"
reorganizing the source layout so that installation specific files are
all in one directory hierarchy that's not versioned in the svn
repository? In other words, currently the files one needs to modify to
install and customize mediawiki are in a few different locations,
sometimes discrete files in directories with existing version controlled
files, sometimes new directories next to versioned core directories,
etc. This makes it somewhat difficult to run version control on my
local changes separately from the mediawiki changes.
To be concrete, files like LocalSettings.php and AdminSettings.php, and
new skins with their BlahSkin.php in skins/ along with the others, and
then their skins/blahskin css directory off that, and the README under
svn in extensions/, and these types of things, and the fact that there
are this many different places to put stuff, makes it difficult to
integrate the official versioned mediawiki and my local stuff,
especially with multiple local sites running the same core mediawiki but
different local customizations.
Do people think it would be a good idea to reorganize to have a "local/"
directory off the root that has AdminSettings.php and LocalSettings.php,
and then local/extensions/ and local/skins/ that are also searched for
extensions and skins in addition to the current ones? That way the
local/ directory could use an svn:externals prop to come from somewhere
else, or an svk view, or it could be a symlink, etc.
Is anybody else running into this issue?
Thanks,
Chris
Thanks a lot, David,
I left it running now for approx. 5 days !!! Finally it finished : 17
pages/sec (only)
>The problem is that you're using InnoDB and reindexing at every insert.
No, i used MyISAM tables. I need to use MyISAM for fulltext indexing.
See my next post.
But you are probably right:
>Disable the keys on page/text/revision
will resolve the problem.
I won't try that now, as i am happy enough to be able to go on with enwiki.
Btw. perl mwimport worked like a charm for dewiki, itwiki, frwiki , but
not for enwiki.
Alex
Norbert Huffschmid (nhuffschmid): Mobile access, WAP portal.
Norbert is the author of HawHaw and the Wikipedia portal at
http://hawpedia.mobi/
-- Tim Starling
rotem(a)svn.wikimedia.org wrote:
> Revision: 24546
> Author: rotem
> Date: 2007-08-02 19:00:53 +0000 (Thu, 02 Aug 2007)
>
> Log Message:
> -----------
> Toggles in RTL preferences indented to the right, hidden in IE in some cases.
o_O
What does this mean?
Were they indented to the right and hidden, but this was wrong? Or are
they *now* indented to the right and hidden and this is right?
-- brion vibber (brion @ wikimedia.org)
Sorry for my complete ignorance, but because I am unsure if this is a bug on
MediaWiki or simple the need to poke sysadmins to take a look at the s3
cluster more frequently, I am reporting this here.
A n00b at Portuguese Wikisource had decided to insert a brazilian salutation
slang in the second most used template on that wiki for unknown reasons. A
admin with poor English (me) reverted it. [1]. All have happened 9 days ago
but since it the job queue is floating between ~1,080 / ~2,400. What is
happening?
[1] -
http://pt.wikisource.org/w/index.php?title=Predefini%C3%A7%C3%A3o:Hino&acti…
Hi everybody,
I just finished hacking the mantainance/importImages.php script,
and it can now handle (seemingly safely) files already existing
on MW.
Removing the existence check as I suggested in a mediawiki-l
email a few days ago was working, but it was fairly unsafe: the
file was overwritten and no archive version was created.
This resulted in the impossibility to view, delete or revert to
earlier version - not quite ideal.
I seem to have been able to fix those problems and it appears
to be doing the right thing, plus I've added a feature that
a) creates two "accepted" and "rejected" directories
b) moves the original files in one of those directories
depending if it has been successfully uploaded or not.
The latter feature is useful for an automated import, so
that as the script gets called every 15 minutes or so,
it doesn't upload images that had been uploaded 15
minutes earlier and haven't been manually removed
from the source directory.
The question is, if I want to make it publicly available
(I have to ask permissions to the company first), what's
the best way to do so? And how do I get it double
checked - testing and code?
Thanks for your help!
Manu
While browsing UseMod, as I almost never do, I came across the
following interesting comment on
http://www.usemod.com/cgi-bin/mb.pl?WikiCreole:
"Several wiki engines have agreed to jump on board (including
MediaWiki and the Ward's original WikiWikiWeb)."
We have, have we? I was under the impression that we couldn't even
standardise our own markup, let alone support something else; I also
got the impression from the recent discussions in response to the
"announcement" that several developers did not see a significant
benefit in supporting it.
The question, then, is where this impression came from, and whether it
is correct; I'm directing this one at the release manager (Brion), and
his senior assistant (Tim). If the impression is false, then who on
Earth expressed this support?
Rob Church
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello!
You are receiving this email because your project has been selected
to take part in a new effort by the PHP QA Team to make sure that
your project still works with PHP versions to-be-released. With this
we hope to make sure that you are either aware of things that might
break, or to make sure we don't introduce any strange regressions.
With this effort we hope to build a better relationship between the
PHP Team and the major projects.
If you do not want to receive these heads-up emails, please reply to
me personally and I will remove you from the list; but, we hope that
you want to actively help us making PHP a better and more stable tool.
The first release candidate of PHP 5.2.4 was just released and can be
downloaded from http://downloads.php.net/ilia/. A fair of time had
passed since the last release so there is a great deal of changes,
with a large number of bug fixes and fair number of new feature
additions. Please try this release candidate against your code and
let us know if any regressions should you find any. The goal is to
have 5.2.4 out within about a month time, so timely testing would be
extremely helpful.
In case you think that other projects should also receive this kinds
of emails, please let me know privately, and I will add them to the
list of projects to contact.
Best Regards,
Ilia Alshanetsky
5.2 Release Master
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)
iD8DBQFGsmksLKekh381/CERAocNAKCC4hWufN+k1+5U93LSaoz7x3+7GgCfSHvz
mRo5MekZwAzF0L5Sa+OU06U=
=8rl5
-----END PGP SIGNATURE-----
I hate to be obstinate with this, but according to the results on:
http://download.wikimedia.org/enwiki/20070716/
The 7zip pages-meta-history.xml dump for enwiki is 3.2GB and OK. On 11/06 it was more than 8 GB long, so I think we still have a BIG problem to solve about that...
I hope that someone could be so kind to answer this message, not like the previous one that, apparently, arrived to nowhere...
Thanks.
Felipe.
---------------------------------
Sé un Mejor Amante del Cine
¿Quieres saber cómo? ¡Deja que otras personas te ayuden!.