Since the first release candidate, an in-place web-based install script
has been added. While still a bit experimental and incomplete, it makes
it much easier to get a new wiki started, particularly where shell
access isn't available for the old command-line installer.
*NOTE:* The web install script doesn't yet support updating old
databases or other maintenance procedures. It can create a new
database, or write a basic LocalSettings.php to access an existing
(up-to-date) database without altering it. The new installer is still
experimental and may fail mysteriously; we'd love to hear from you, if
you do or don't get it to work.
Download and release notes:
http://sourceforge.net/project/showfiles.php?group_id=34373
See 'INSTALL' in the archive for some notes on the new installer.
MediaWiki 1.2.0 includes improved inline image and thumbnailing
support, smoother account management, and a number of interface tweaks
as well as numerous bug fixes and backend features (squid cache
purging, authenticated SMTP, tighter upload security, PHP5
compatibility). Also fixes an incompatibility with MySQL 3.2.x in the
default install that cropped up in 1.1.
-- brion vibber (brion @ pobox.com)
Please, as it was discussed in length, could someone make the tool bar
feature disabled by default.
This feature is broken. It does not work on many browsers. It should not
be "on" per default for a newcomer. It is very disturbing.
Thanks
ant
I agree with Brion, and I'm sorry I replied to Timwi before reading
Brion's "I forbid" post.
I've done profiling on Visual Basic 4.0 & 5.0, MS SQL Server 6.5, and
Java; and let me tell you I'm frequently amazed at the kinds of things
that cause slow spots. "But that can't be true!" is the usual response
of my colleagues. Then, you show them the profiling data, and they're
like, "Well, I'll be durned. Who would have known?"
Anyone know how to profile MySQL code?
Ed Poor
Webalizer job ran on March 2 around 23:55 hrs UTC
It produced af.wikipedia.org/stats up to da.wikipedia.org/stats
de and higher are still from Feb 28
so I assume the job abends (every night?)
Erik Zachte
Hi,
for a open source project I'm involved in we want to use the Wikimedia
software for our webpage and for documentation of our software. Yesterday I
received an email from a group member who volunteered to install wikimedia
software that wikimedia needs to have
register_globals=on
which seems to be a security risk according to
http://lists.evolt.org/archive/Week-of-Mon-20021209/130049.html.
Are there any plans to replace this code or can anyone who is more familiar
with the code explain to me how much work it would need to change the code
such that register_globals can be switched off? I assume that using the
software with "register_gloabals=off" does not work at all, is that correct
or would it only mean that some of wikimedias features are disabled?
Thanks and best regards,
Marco
--
Marco Krohn
Theoretical Physics
University of Hannover
Does the GNU Free Documentation License give everyone the right to stick
a frame around the Wikipedia and rename it, as Sterling has done?
What's the difference between hijacking and proper use?
Is Sterling making a mockery of Jimbo's promise not to have ads in
Wikipedia?
Someone explain this to me, please.
Ed Poor (speaking for myself only)
Is there a way to prevent abominations like www.powerpedia.org, which
put Wikipedia in a frame with their own adverts? While that
particular site is probably not very important, I can see this
becoming more of an issue. Would it be possible for Wikipedia pages
to use that lovely bit of Javascript so common nowadays, which
automatically breaks out of frames? It looks something like:
<script language="JavaScript">
<!--
function SymError()
{
return true;
}
window.onerror = SymError;
var SymRealWinOpen = window.open;
function SymWinOpen(url, name, attributes)
{
return (new Object());
}
window.open = SymWinOpen;
//-->
</script>
<body onload="var SymTmpWinOpen = window.open; window.open =
SymWinOpen; delayedreload(); window.open = SymTmpWinOpen;">
--
Allan Crossman - http://dogma.pwp.blueyonder.co.uk
PGP keys - 0x06C4BCCA (new) || 0xCEC9FAE1 (compatible)
I wrote:
> Would it be possible for Wikipedia pages to use that lovely bit
> of Javascript so common nowadays, which automatically breaks
> out of frames?
And I see we already do. Doh.
Still, how come it ain't working in this instance?
--
Allan Crossman - http://dogma.pwp.blueyonder.co.uk
PGP keys - 0x06C4BCCA (new) || 0xCEC9FAE1 (compatible)
I believe we need to start thinking about ways to better separate content
and metadata. Making them editable separately, and perhaps making either
type of content filterable, gives us room for expansion in the meta realm
without impacting editability for users who just want the plain text.
Current meta-tags:
* interlanguage links
* __NOTOC__
* __NOEDITSECTION__
* category links (experimental)
Possible future meta-tags:
* <editnote> - shown on top of the edit box during editing, e.g. "Please
describe new events in the present tense"
* <sizelimit> - for auto-archiving or size warnings
* __NOCACHE__
* __NOTITLE__, __NOSUBTITLE__ for navigational pages, Main Page
* [[Edition=Print]] and other name=value tags
* .. anything else that would be useful, but clutter on the article page
I see two possibilities, one of which I call the hackish approach and the
other the clean approach.
== The hackish approach ==
Add a new tag, called <meta>. Content within <meta>..</meta> is shown in a
separate window, like this:
<pre>
_________________________________________
| |
| The PURINA brand of dogfood is very |
| tasty. Critics allege that it is made |
| of harvested souls from children |
| in the third world. |
|_________________________________________|
_________________________________________
| [[de:Fnord]] [[simple:Wormwood]] |
| __NOTOC__ [[Category:Dogfood]] |
| <editnote>Do not edit after dark</editn |
|_________________________________________|
[ SAVE ] [ PREVIEW ]
</pre>
There would be an option to hide meta-information during editing, and one
to use the old (single-window) behavior.
The meta-content would be part of the regular cur_text, it would be simply
concatenated with it / split away from it on demand.
Advantages:
* Relatively easy to implement
* single diffs for edits that change meta content and article content
Disadvantages:
* regular editing can still cause edit conflicts with meta-editing
* no easy filtering of meta-editing from RC, diffs
== The clean approach ==
It would of course be cleaner to separate meta-content in the database. If
we desire to do this, we should do it as part of the pending database
redesign. In this case we would have a text blob and a meta blob which
could be edited separately without conflicts. Any edit of a text or meta
blob would result in an entry in the recent changes log.
The most problematic effect of this change would probably be on the page
history. Again, the most logical approach would be to list a change to
either meta or article-content in the history, but perhaps in separate
color.
Disadavantage:
* requires table redesign, might affect quite a few pages
* more difficult but not impossible to maintain single window behavior
* complicates diffs, esp. summary diffs
Advantages:
* makes it easy to filter meta-edits from RC, history
* meta-edits cannot cause edit conflicts with regular ones
* storing and retrieving the different types of data is a lot easier and
less error-prone
== Thoughts? ==
I think before we go any further into the meta area, we need to clean up
the separation, otherwise we'll end up confusing newbies. I'd appreciate
feedback on how to do this.
Regards,
Erik
Could someone knowledgeable in the quirks of language files please take
a look at [[m:Advice needed on LanguageXX.php files]], please? We've
recently implemented LanguageCy.php which works pretty well, but we've
somehow managed to break {{msg:...}}, among other things.
The meta article describes the few problems we've noted so far, and
ideas for how to fix them would be gratefully received.
--
Arwel Parry
http://www.cartref.demon.co.uk/