Hi,
I see that there was some discussion about this back in 2006 Jan, but I
haven't been able to locate a solution anywhere.
What I'm trying to do is to have a template {{Template:Header}} that
has, say,
<div style="border: 1px solid red;">
and then a template {{Template:Footer}} that closes that div:
</div>
Then on my page I want to do this:
{{Template:Header}}
some content
{{Template:Footer}}
When I do this, it auto-closes the div before "some content", which is
not what I want.
As other people have pointed out, it does work on the Wikimedia sites.
(I did the exact same thing on http://www.mediawiki.org/wiki/Sandbox and
it worked.)
In fact, 100s of portals use this technique on Wikipedia (see
http://en.wikipedia.org/wiki/Portal:Mathematics,
<http://en.wikipedia.org/wiki/Portal:Mathematics>
Portal:Mathematics/box-footer-empty
<http://en.wikipedia.org/wiki/Portal:Mathematics/box-footer-empty>,
Portal:Mathematics/box-header
<http://en.wikipedia.org/wiki/Portal:Mathematics/box-header>, for
example) so I know it can be done.
I'm using the latest version and all (1.9) on my installation, so what
does Wikipedia have set up differently that allows this?
If someone could tell me how to enable this (or disable auto-closing of
unclosed tags, as the case may be), please let me know.
Thanks,
Tyler
> Hi crew,
>
> great to finally get a discussion on that topic.
>
> I of course see the point of fixing broken tags in templates to keep
> the generated HTML clean. But besides tags that are left unclosed
> accidentally, we have a real use case for this as we see for the box
> template.
>
> Since I'm not too long into wiki usage, the suggestion might be wrong,
> but maybe it could solve this issue: A flag that turns on/off the
> parser's "error handling" by adding something like __DO_NOT_FIX_TAGS__
> would be cool. Feasible or not?
>
> Thanks, Gerrit
>
> On 1/27/06, Rick DeNatale <rick.denatale at gmail.com <http://lists.wikimedia.org/mailman/listinfo/mediawiki-l>> wrote:
> >/ On 1/26/06, Brion Vibber <brion at pobox.com <http://lists.wikimedia.org/mailman/listinfo/mediawiki-l>> wrote:
> />/ > Rick DeNatale wrote:
> />/ > > On 1/26/06, Brion Vibber <brion at pobox.com <http://lists.wikimedia.org/mailman/listinfo/mediawiki-l>> wrote:
> />/ > >> Gerrit Quast wrote:
> />/ > >>> The problem is that for every template, mediawiki closes tags that
> />/ > >>> left open. The second template (only the closing DIV) is escaped and
> />/ > >>> appears as clear text.
> />/ > >> IIRC, there's a bug in the parser cleanup when HTML Tidy is enabled which causes
> />/ > >> it to _not_ close the open tags for each template.
> />/ > >
> />/ > > Of course one man's bug is another feature.
> />/ >
> />/ > Well, that "feature" will break, badly, in future versions of MediaWiki which
> />/ > fix up the parser.
> />/
> />/ I don't use it myself, but when it breaks, it's going to break a LOT
> />/ of portal pages on wikipedia.
> />/
> />/ --
> />/ Rick DeNatale/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
January 10, 2007
MediaWiki 1.9.0 is the quarterly release snapshot for Winter 2007. While
the code has been running on Wikipedia for some time, installation and
upgrade bits may be less well tested. Bug fix releases may follow in the
coming days or weeks.
MediaWiki is now using a "continuous integration" development model with
quarterly snapshot releases. The latest development code is always kept
"ready to run", and in fact runs our own sites on Wikipedia.
Release branches will continue to receive security updates for about a
year from first release, but nonessential bugfixes and feature
development happen will be made on the development trunk and appear in
the next quarterly release.
Those wishing to use the latest code instead of a branch release can
obtain it from source control:
http://www.mediawiki.org/wiki/Download_from_SVN
1.9 includes a number of compatibility fixes since 1.8 as well as many
bug fixes and some new features, so all users who can run PHP 5 are
strongly encouraged to upgrade.
There are no changes from 1.9.0rc2 to 1.9.0 final except the version number.
Full release notes:
http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_9_0/phase3/RELEASE-NOT…
Download:
http://sourceforge.net/project/showfiles.php?group_id=34373
MD5 checksums:
cb58560858e2b85ac7b94097ad3e4531 mediawiki-1.9.0.tar.gz
SHA-1 checksums:
c60e212ae5c02501405d91014db6c53499fafa39 mediawiki-1.9.0.tar.gz
Before asking for help, try the FAQ:
http://www.mediawiki.org/wiki/Manual:FAQ
Low-traffic release announcements mailing list:
(Please subscribe to receive announcements of security updates.)
http://lists.wikimedia.org/mailman/listinfo/mediawiki-announce
Wiki admin help mailing list:
http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Bug report system:
http://bugzilla.wikimedia.org/
Play "stump the developers" live on IRC:
#mediawiki on irc.freenode.net
- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFpVY9wRnhpk1wk44RAuaLAKDZMiz0XUxIEUdbB6/b90ETuPDKZgCcDM50
N2xH6gBQ5AW5ncvhvRRitGk=
=Uomr
-----END PGP SIGNATURE-----
Every FUCKING JERK is publishing these Emails from this mailing list all
over the world. There are coming more and more SHIT SITES which are
publishing every word I am writing here on its dammed websites without my
permission. Every open webforum is more private than this list.
Rob,
this is defenetly the reason, why noone uses this mailing list anymore.
Perhaps you should write near the subscription button: "note, everything you
write here is published on several sites all over the world"
I will defenetly unsubscribe from now on.
Hey guys,
I have a question, is it possible to create a drop down list of categories when a new page is created? To allow users to classify their article under one or more categories? Even a small change in the spelling will cause the article to be classified under a different area..... ideas??
thanks,
AJ
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Documentation needs some more updates before I roll up the release
packages, particularly the release notes and the upgrade information,
but I've gone ahead and branched 1.9 off from trunk to make sure it
doesn't get hit by another ten regressions by morning. ;)
The 1.9 release branch can be checked out via Subversion at:
http://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_9/phase3
A few more testers to confirm that installation and upgrade work on
configurations other than developers' own machines before we make a
wider release would be welcome, so don't be shy about testing it. :)
- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFojUowRnhpk1wk44RAgnCAJ9JJAfc2WuUSoQ2LZIfb3dcX+L1rQCglt9H
T/vOy3I/zwZ5eLa1u62NVZU=
=mnri
-----END PGP SIGNATURE-----
Hi. i have two wikipedias on one server (www.wikipasy.pl and en.wikipasy.pl).
First is main project, secound is english translation). Each one have own
database, but i want to not duplicate list of users and media files like
images. It is possible to hack secound wiki (en.wikipasy.pl) to use first
wiki users and files?
Best regards,
Dinth
I have ConfirmEdit up and running using
http://meta.wikimedia.org/wiki/ConfirmEdit_extension tutorial, well I
thought? When I try to add a page with a link and I am not logged in,
the captcha looks good but filling in the correct word doesn't allow
me to post? Is there any way I can debug this problem? Only thing I
can think is some how my $wgCaptchaSecret = '****'; doesnt match my
--key=**** but it should?
The site is http://wikidetails.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I've made a snapshot release candidate from 1.9 branch; this is a chance
to get a few more possible installation/upgrade regressions tested and
fixed.
A more widely announced 'final' 1.9.0 release will come after another
day or two.
Full release notes:
http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_9_0RC1/phase3/RELEASE-…
Download from:
http://sourceforge.net/project/showfiles.php?group_id=34373&package_id=93103
MD5 checksum: 55eb83d15a95db85ed002aace93a18d9
SHA-1 checksum: 1ee7d5ddc5b356288f7bdaa9b5800cb89a461216
- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFov17wRnhpk1wk44RAm0NAJ9cCdwCyI05uxYzub91uU19NYEu8ACfWSsB
1vXMvKj5Q3Hhb6h0gLphWWA=
=fhhJ
-----END PGP SIGNATURE-----
We're working on upgrading our 1.4.12 wiki to 1.9.0.
One thing I discovered is that template usages in 1.8.2 and 1.9.0 now
require correctly matching title case. This was not the case in 1.4.12.
i.e. For Template:NavBar, pages that worked previously with {{Navbar}} in
the wikitext are now broken links. Switching it to {{NavBar}} fixes the
inclusion.
My first question, is this a bug or a feature? You can't safely have
Template:NavBar and Template:Navbar in the same wiki database anyway,
correct?
Unfortunately we now have a large number (over 1,000) of broken template
links in our site if we upgrade. One possible solution is to use redirects
from the improperly capitalized templates to the correct ones, which could
probably be done mostly with a XML import. Any issues with that solution?
--
View this message in context: http://www.nabble.com/Template-title-case-sensitivity%3A-bug-or-feature--tf…
Sent from the WikiMedia General mailing list archive at Nabble.com.
Is there a way to get a quick list of broken internal links in
MediaWiki? I found weblinkchecker.py, but it seems to be geared only to
external links. How can I get a list of internal links that point nowhere?