Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.

Bug 7122 - Introduce {{#ifexistlog:}} parser function


Summary:	Introduce {{#ifexistlog:}} parser function

Status:	NEW

Product:	MediaWiki
Classification:	Unclassified
Component:	Parser (Other open bugs)
Version:	unspecified
Hardware:	All All

Importance:	Low enhancement with 3 votes (vote)
Target Milestone:	---
Assigned To:	Nobody - You can work on this!

URL:
Whiteboard:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2006-08-25 10:56 UTC by Danny B.
Modified:	2011-04-14 15:11 UTC (History)
CC List:	0 users

See Also:
Web browser:	---
Mobile Platform:	---
Assignee Huggle Beta Tester:	---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Description Danny B. 2006-08-25 10:56:03 UTC

Sometimes it's handy to know, if there's any log record for such page. The idea
is based on already existing {{#ifexist:}} parser function.

The idea:
{{#ifexistlog:Foo|true|false}} - if any kind of log (move, delete, protect...)
for page Foo exist than true else false.

The enhancement:
It would be great to be able to differ the log type. I don't know the
limitations for syntax so these are some ideas:
* {{#ifexistlog:Foo|#delete|true|false}} - if delete log for page Foo exist than
true else false. The log type param is optional, therefore # to recognize if
it's log type or true/false param.
* {{#ifexistlog:Foo|delete|true|false}} - if delete log for page Foo exist than
true else false. The log type param is necessary, therefore some keyword needed
for undiffered logs - "all" or "any"?
* {{#ifexistlog:Foo|true|false|move}} - if delete log for page Foo exist than
true else false. The log type param is optional.
* {{#ifexistprotectlog:Foo|true|false}} - set of named parser functions for
certain log, plus the unnamed (see top) for any kind of log.
* Any other?

The greater enhancement:
Allow to differ via user as well. Can have the general syntax eg:
{{#ifexistlog:<pagename>|<logtype>|<user>|true|false}}
where logtype = any/all for undiffered log.
So eg:
{{#ifexistlog:Foo|all|||false}}
would output false if no log for Foo page otherwise nothing.

Comment 1 Rob Church 2006-08-25 13:17:58 UTC

That wanders off into the realm of being a little bit too expensive to fit in
with the other parser functions, and I seriously doubt the usage would be
anything like advertised.

I'm not saying it's not possible, but I dispute that it would be worth it for
more than a couple of cases.

Comment 2 Danny B. 2006-08-25 13:50:02 UTC

Well, the main purpose, why I requested that, is to put it on
MediaWiki:Noarticletext, so people who came via external link can see on the
first sight if the link was incorrect, or if anything with this page happened in
past. Now they have to check the log everytime even if it's empty.

Another places are MediaWiki:Newarticletext and MediaWiki:Nogomatch.

All three of them together are one of the most used MediaWiki messages I guess.

It's always better to say:
This page was never created...
or
This page was moved, check the log...
than
Check the log for possibility it's not empty and something happened to this page...

It shows directly some additional info about the searched page or page intended
to be created.

Other uses are minor, but useful as well:
* block log for users who've been blocked (eg. on rfa) - no need for people to
check everybody regardless if the log is empty or not, just those, who've really
been blocked (besides it's more polite to never blocked users to not show the
"list of blocks" link)
* page log on vfd - no need to check empty logs; it's always necessary to know
what was happening to the page, but sometimes nothing happened
* and couple others based on same principle.

Basically it's intended to save worthless checking of empty logs, which is
* annoying users
* creating traffic
* creating worthless server load to generate the log page

Comment 3 Rob Church 2006-08-30 08:06:50 UTC

I'm still concerned that this requires a SELECT to be done on the database for
each invocation, and I'm inclined to stab it now for that reason.

Note You need to log in before you can comment on or make changes to this bug.

Search

Personal tools

Navigation

Links

Contents Listing Alphabetical by Author:

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Unknown Other

Contents Listing Alphabetical by Title:

# A B C D E F G H I J K L M N O P Q R S T U V W Y Z Other

Medical Encyclopedia

Browse by first letter of topic:

A-Ag	Ah-Ap	Aq-Az	B-Bk	Bl-Bz	C-Cg	Ch-Co
Cp-Cz	D-Di	Dj-Dz	E-Ep	Eq-Ez	F	G
H-Hf	Hg-Hz	I-In	Io-Iz	J	K	L-Ln
Lo-Lz	M-Mf	Mg-Mz	N	O	P-Pl	Pm-Pz
Q	R	S-Sh	Si-Sp	Sq-Sz	T-Tn	To-Tz
U	V	W	X	Y	Z	0-9