Hi,
What is the recommended practice for making additional information available
to the phptal template?
I know that I need to call the set method on the template
$tpl->set( "foo", $bar );
but the temlate is created and returned within the outputPage method.
It would be great if there were a hook that could easily be overridden in a
subclass that would enable me to stick extra info into the context w/out
having to modify the distribution.
Is this the kind of patch you would consider taking?
thanks
Jonah
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
MediaWiki 1.4beta1 is an experimental release, to help flush out
remaining major problems in the code prior to a final public 1.4.0
release. It is not recommended to use this beta on a public site unless
you're familiar with MediaWiki innards and are willing and able to help
diagnose and fix problems that come up.
=== New features ===
* 'Recentchanges Patrol' to mark new edits that haven't yet been viewed.
* New, searchable deletion/upload/protection logs
* Image gallery generation (Special:Newimages and <gallery> tag)
* SVG rasterization support (requires external support)
* Users can select from the available localizations to override the
default user interface language.
* Traditional/Simplified Chinese conversion support
=== Installation and compatibility ===
* The default MonoBook theme now works with PHP 5.0
* Installation on systems with PHP's safe mode or other oddities
should work more reliably, as MonoBook no longer needs to
create a compiled template file for the wiki to run.
* A table prefix may be specified, to avoid conflicts with other
web applications forced to share a database.
* More thorough UTF-8 input validation; fixes non-ASCII uploaded
filenames from Safari.
* Command-line database upgrade script.
=== Customizability ===
* Default user options can now be overridden in LocalSettings.
* Skins system more modular: templates and CSS are now in /skins/
New skins can be dropped into this directory and used immediately.
* More extension hooks have been added.
* Authentication plugin hook.
* More internal code documentation, generated with phpdoc:
http://www.mediawiki.org/docs/html/
=== Optimization ===
* For many operations, MediaWiki 1.4 should run faster and use
less memory than MediaWiki 1.3. Page rendering is up to twice
as fast. (Use a PHP accelerator such as Turck MMCache for best
results with any PHP application, though!)
* The parser cache no longer requires memcached, and is enabled
by default. This avoids a lot of re-rendering of pages that
have been shown recently, greatly speeding longer page views.
* Support for compiled PHP modules to speed up page diff and
Unicode validation/normalization. (Requires ability to compile
and load PHP extensions).
=== What isn't ready yet ===
* A new user/groups permissions scheme has been held back to 1.5.
* An experimental SOAP interface will be made available as an extension
* PostgreSQL support is largely working, but search and installer
support are not complete. These are being actively worked on
and should come in later betas.
* E-mail notification of watched page changes and verification of
user-submitted e-mail addresses is not yet included. If updates
are available, this may make it into later betas.
* Log pages are not automatically imported into the new log table
at upgrade time. A script to import old text log entries is
incomplete, but may be available by the time 1.4 finishes.
* UI messages may be broken in Latin-1 mode in this release due to some
minor breakage in the language selection module.
Full release notes:
http://sourceforge.net/project/shownotes.php?release_id=287326
Download:
http://prdownloads.sf.net/wikipedia/mediawiki-1.4beta1.tar.gz?download
Wiki admin help mailing list:
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
Low-traffic release announcements mailing list:
http://mail.wikipedia.org/mailman/listinfo/mediawiki-announce
Bug report system:
http://bugzilla.wikipedia.org/
Play "stump the developers" live on IRC:
#mediawiki on irc.freenode.net
- -- brion vibber (brion @ pobox.com)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (Darwin)
iD8DBQFBsHrUwRnhpk1wk44RAmVjAKCS/S0DALe1b8F8OPBwp6POhDdmnwCgiY2n
oXBwQheNUN0xPWUim5qs4FA=
=mkWR
-----END PGP SIGNATURE-----
Hi,
I need still use template feature but not to parse other part of the text, for example images.
Can you suggest what file I have to modify to get this result?
Giovanni Putignano
Dear all,
I just wanted to point that I'll try to publish my Enotif (Email
Notification for page changes) incl. Eauthent (Email Address
Authentication) incl further patches for the branched 1.4 version until
Tuesday, 07.12.2004. -- working very very hard on that.
Some further tests are needed, and then a first release will come - I
promise, you will like my patch.
Tom
Nick Pisarro here...after disappearing into the woodwork since the
Spring...
I recently upgraded our MediaWiki run site to 1.3.7. In a fit of
programming frenzy, I have implemented a new feature; the ability to edit
the summary and Minor Edit flag of an article revision. Assuming I still
have the proper access rights to 'phase3' on SourceForge, I would like to
merge my feature into the head branch and upload it assuming enough of you
find the feature worthwhile.
The purpose of the feature is to allow people to correct errors they may
have made in a summary or to add one when the may have forgotten to--a
problem I have personally all the time. Sysops have the option to clean up
offensive language in summaries.
I have attached screen shots of the feature in action. I don't know if the
mailing list program will forward them.
Features.
* The feature is controlled by a flag in Default/LocalSettings.
* You may only edit the summaries of revisions you have made, except for
SysOps, who may edit any summary. (Summaries are referred to in the PHP
code as "comments".) Anonymous users, and hence users not logged in, may
not edit summaries.
* In the History listing and Contributions listings I have put a small
icon next to the summary on lines a user may edit the summary of.
* Clicking on the icon will bring up a page titled after the article being
edited and subtitled "Editing summary of revision...". The page has an
edit field and check box for adjusting the summary and/or changing the
Minor Edit flag. A user my click "Save" or "Cancel".
* A double check is done as part of making the database update, that the
user is still logged in and that they are the author of the revision, if
they are not a SysOp. This is done to thwart any evil robots spoofing a
submit of the edit page.
* The page is refreshed with a confirmation or cancellation message and a
link back into the History or Contributions page the user came from. After
ten seconds the user is flipped back automatically in a way that is
similar to Login/Logout.
* The edit page is implemented by a new file--EditComment.php. Internally
I modified the function OutputPage::returnToMain() to allow flipping back
to exactly where you came from, rather than always to a main article page.
Issues: Because there are no histories of summaries and hence no
'reversions' I thought there were too many security risks in letting
anonymous users edit their summaries (which may not actually be theirs),
or letting logged in users edit summaries other than there own.
Changing a summary will NOT change its listing in Recent changes. This is
because this is a log of past events and is a copy of the original
summary, not an actual reference to it. I thought it might cause too big
of a performance hit to try to fix up the Recent changes log, and perhaps,
philosophically not a good idea.
Future enhancement: Log changing the summary in Recent changes. This might
require a database format change, so I did not want to attempt it.
If desired, I could convert this message to an article on
meta.wikimedia.org.
User:Nick Pisarro, Jr.
Hi all :)
I hope this question is on-topic :)
We have some problems concerning thumbnails. We updated PHP to a newer version
(PHP 4.3.8) and it seems that thumbnails are created in another way than with
the older version. A good example is http://www.tuxfutter.de/wiki/The_GIMP.
I would like to switch to ImageMagick but unfortunately some packages are not
available (the system is an older FreeBSD).
Any hints or should I ask in a PHP group?
Thanks,
Hauke
--
> Sitze ich vor einer Winkiste bekomm ich hier die Kriese.
Ja, Windows ist wie Sackhuepfen ohne Beine.
----
diskless und valencia im Heise-Forum
Is there any way to generate a table of contents to disaplay on the main
page och any special page.
I am using MediaWiki for documentation and dictionary on our intranet
and a good overview of all the topics would be great.
Any work done on this kind of feature?
/Peter
Dear all,
do you want to have the Email Notification in REL1_4 ?
I invested a lot of time and it is almost ready and stable since months
(in my checked-out branch, daily updated from HEAD) and would simply
like to know your opinion.
Or, you could alternatively allow me to commit into the HEAD, so that
the new 1.5 comes with that.
Tom
I asked brion on #mediawiki if he ever had problems merging between
branches due to the CVS keywords we have embedded in the source code.
Keywords in source make merging between branches kinda hard; you get a
lot of spurious conflicts, and it's consequently harder to find and
resolve the real ones. See this URL for details:
https://www.cvshome.org/docs/manual/cvs-1.11.18/cvs_5.html#SEC64
Brion said that, yes, he did have problems with them, and said to remove
CVS keywords when I saw them. I then did a global search-and-replace
across the codebase, removing all the CVS keywords I could find (almost
all were $Id:$; I found one or two $Revision:$ ones).
I realize that having CVS keywords in source files can be convenient; I
don't think that convenience outweighs the burden put on release
managers when merging across branches. Life's hard enough for our
release managers, and if a release manager misses a real conflict
because a merge caused 65 false ones, we've got a quality problem.
I've added notes to this effect in the coding standards in
docs/design.doc; I'll try to find a place on meta.w.o to add it, too. I
should have posted to the list about it earlier; sorry I didn't.
~ESP
--
Evan Prodromou .O.
http://bad.dynu.ca/~evan/ ..O
evan(a)bad.dynu.ca OOO
--
Evan Prodromou <evan(a)wikitravel.org>