Other parameters: Difference between revisions

From DynamicPageList3 Manual
Content added Content deleted
imported>FrozenPlum
(Add more examples)
 
(32 intermediate revisions by 10 users not shown)
Line 1: Line 1:
{{DPL Manual|section=Other parameters}}
{{DPL manual|section=Parameters|subsection=Other parameters}}
{{tocright}}


===updaterules===


==debug==
{{DPL parameter
{{DPL Parameter
|name = updaterules
|name = debug
|purpose= define a set of rules which are executed to perform an update on selected articles (''bulk update'' or ''template value editing'')
|purpose= Sets debugging level.
}}
}}


Syntax:


'''Syntax:'''
<code>updaterules=
<i>rule</i>;
...
<i>rule</i>;
</code>


<code>debug=<i>n</i></code>, where {{tt|n}} is one of:
Where rule is one of the following:
* <code>''0''</code> – Silent mode, shows nothing.
* <code>''1''</code> – Quiet mode, shows (fatal) errors.
* <code>''2''</code> – Default mode, like 1 + shows warnings; – '''(default)'''.
* <code>''3''</code> – Verbose mode, like 2.
* <code>''4''</code> – Dump raw SQL Query; only if ''$wgDebugDumpSql'' is set to true.
* <code>''5''</code> – Show wiki text output from DPL3 instead of parsed wiki text.


* rules for batch update of articles
replace ''pattern'';
by ''replacement'';
before ''pattern'';
insert ''text'';
after ''pattern'';
insert ''text'';


{{note|'''Note:''' If the debug parameter is '''not''' used in the first position of the DPL3 statement, the new debug settings are not applied before all previous parameters have been parsed and checked.''' This generates a warning for <code>debug{{=}}2</code> and above.}}
* rules for interactive update of articles
template ''template name'';
legend ''legend article name'';
table ''table format'';
editform ''form parameters'';
action ''form action'';
hidden ''value'';
submit ''submit button'';
commit ''commit button'';
parameter ''parameter name'';
value ''value'';
format ''display format'';
tooltip ''text'';
optional ''value'';
afterparm ''parameter name'';


* common rules
summary ''edit summary text'';
exec ''value'';


'''Example:'''<br><br><!-- transclude example from subpage-->{{#lsth:Examples/Parameter: debug (example 1)|Example}}
The first group of rules is intended for batch updates of articles. A DPL query can select a group of articles and perform updates like inserting a piece of text at a certain position or changing text portions based on regular expressions.
{{ViewTest|Examples|Parameter: debug (example 1)}}


'''Result:'''<br><br><!-- transclude example from subpage-->{{#lsth:Examples/Parameter: debug (example 1)|Result}}
The second group of rules is intended for interactive form-based editing of template values.


The third group of rules is common to both other groups and controls the update process.


'''Notes:'''
The <tt>updaterules</tt> feature is intended for wiki expert users only. It is recommended that articles usind this statement are 'protected':
* DPL3 debug messages are translatable in ''DynamicPageList2.i18n.php''.
* <code>debug=''1''</code> suppresses warning messages (e.g., if the result set of a DPL3 query is empty). As an alternative, the <code>{{DPL|suppresserrors}}=</code> statement can be used.




==allowcachedresults==
==== Rules for batch update in detail: ====
{{DPL Parameter
|name = allowcachedresults
|purpose= Cache query results to improve performance, keep servers from crashing under high load.
}}


===== replace ''pattern''; =====
Defines a regular expression which matches text portions that shall be replaced. It is in the responsibility of the user to provide enclosing characters for the regexp; modifiers line 'U' or 'm' can be used.


'''Syntax:'''
===== by ''replacement''; =====
Defines the replacement for the above pattern; back references like \1 can be used.


<code>allowcachedresults=''value''</code> where {{tt|value}} is one of:
===== before ''pattern''; =====
* <code>''true''</code> – ('''default''', need not be set).
* <code>''false''</code> – prevent caching.


Defines locations where text will be inserted. The location(s) will be immediately before the match(es) of the pattern. If a pattern matches multiple times, multiple inserts will be performed.


'''Notes:'''
The regexp will implicitly be enclosed in slashes. Hence literal slash characters must be escaped by backslashes.
* All queries are cached by default '''to reduce server load''', as generally articles do not change often enough to require updating every page load.
* If immediate updates are required every page load, such as for displaying {{DPL|scroll}} navigation via {{DPL|URL parameters}}, then set this parameter to false.
* Cache period is handled by the <code>{{DPL|cacheperiod}}</code> parameter.


===== after ''pattern''; =====


==cacheperiod==
Defines locations where text will be inserted. The location(s) will be immediately after the match(es) of the pattern. If a pattern matches multiple times, multiple inserts will be performed.
{{DPL Parameter
|name = cacheperiod
|purpose= Defines the expiration period for the DPL3 cache.
}}


The regexp will implicitly be enclosed in slashes. Hence literal slash characters must be escaped by backslashes.


'''Syntax:'''
===== insert ''text''; =====


<code>cacheperiod=''number of seconds''</code> – ('''default''' is 3600, meaning 1 hour).
Defines the text to be inserted.


A DPL statement may contain replacement, insertion before and after at the same time.
replace /([a-z]+])-cat/;
by \1-dog;
before foo;
insert bar;
after foo;
insert bar2;


==goal==
Only one 'replace'-'by' sequence, one insertion 'before' and one insertion 'after' can be specified. 'replace' is always executed first, followed by 'insert before' and 'insert after', regardless of the sequence in which the rules appear in the DPL source ´text.
{{DPL Parameter
|name = goal
|purpose= Set the goal for DPL3 to either show '''pages''' (default) or '''categories''' these pages belong to.
}}


==== Rules for interactive update in detail: ====


'''Syntax:'''
===== template ''template name''; =====


<code>goal=''goaltype''</code> where {{tt|goaltype}} can be one of:
The name of the template; the prefix "Template:" must be given.
* <code>''pages''</code> – ('''default''', need not be set).
* <code>''categories''</code>.




DPL3 produces a list of pages by default, and this is precisely what the name DPL3 promises.




If the goal parameter is set to 'categories' the list of pages is still be produced, but is not seen. Instead, it is used to '''calculate a unique ordered list of all categories these pages belong to'''.
be inserted. The location(s) will be immediately before the match(es) of the pattern. If a pattern matches multiple times, multiple inserts will be performed.


The regexp will implicitly be enclosed in slashes. Hence literal slash characters must be escaped by backslashes.


This allows the asking of question like: Given all pages that are a member of category ''X'' with a title matching ''"y%"'' and which use template ''"Z"'': to which categories do these pages belong?




One of the more useful applications would be a question like: "To which categories do the pages belong which contain a reference to the current page?"
a regular expression
after ''pattern'';
insert ''text'';
replace ''pattern'';
by ''replacement'';




The output of <code>goal=categories</code> is technically a ''list of pages of type category''. This means that all DPL3 formatting options can be used (<code>mode=userformat</code>, <code>listseparators</code>, <code>columns</code> etc.) and pseudo variables (<code>%TITLE%</code>, <code>%PAGE%</code>) to customize the layout of the report.




'''Technical Note:'''


Due to some limitations in MySQL, it is currently not possible to restrict the intermediate result set of pages to a certain maximum (using the LIMIT clause). In addition, the generated SQL code is not in all cases optimal (as its structure provides for complex selection criteria and therefore is unnecessarily complex in simple cases). So be careful and apply precise selection criteria.
For safety reasons the update statements will only be performed if "exec yes" is specified. So, leaving this away, you can check what would happen if the update were to be executed.


Note that if "exec yes" is present the update will be performed each time the page is renderes which contains the DPL statement with the <tt>updaterules</tt>. So it is advisable to set "exec yes" only via a command line argument and not as part of the statioc article text. Thus you stay in control when the update happens. Typically one would use an URL parameter like ''DPL_arg1'' for that purpose.


==eliminate==
The size of the form fields will dapt to the size of the displayed content.
{{DPL Parameter
|name = eliminate
|purpose= Suppress references to pages, templates, images, categories in DPL3 output
}}




'''Syntax:'''


<code>eliminate=''keyword,..''</code> where {{tt|keyword}} is one of:
* <code>''categories''</code>
* <code>''templates''</code>
* <code>''images''</code>
* <code>''links''</code>
* <code>''all''</code> – A synonym for all of the above.


To make the use of the <tt>updaterules</tt> feature easier we provide a [[Template:Bulk Update|special user interface]].


The output of a DPL3 statement typically creates links to all pages which are part of the result set. The inclusion of contents from other pages via DPL3 (using <code>{{DPL|include}}</code>) normally has these consequences:
''text'' is plain text; ''replacement'' is text which may contain references (like \1) to the matching ''pattern'' (provided that this pattern contains match groups).
* The page containing the DPL3 query becomes part of the categories of the transcluded page.
* It shares ('adopts') their use of templates.
* It shares their references to images.
* It shares their references to other articles.


===deleterules===
{{DPL parameter
|name = deleterules
|purpose= allow the mass deletion of wiki pages
}}


In some cases, this may be useful. But in many cases, this is not wanted. Especially when DPL3 is used to create a printable document which contains the full text of other articles, duplicating all links, template uses etc., of those articles is probably undesired.
<code>deleterules=
reason <i>text</i>;
exec true;
</code>


The <code>eliminate</code> parameter suppresses all or some of the effects described above.
This command is experimental at the moment.


For further explanation, see <code>{{DPL|reset}}</code>.
This will delete the selected pages; If "exec true" is missing, nothing will happen.


'''Note:''' The use of <code>eliminate</code> needs a considerable amount of extra computing power as it performs a second parser step for each included document.
===goal===



{{DPL parameter
==reset==
|name = goal
{{DPL Parameter
|purpose= set the overall goal for DPL to either show '''pages''' (default) or '''categories''' these pages belong to
|name = reset
|purpose= Suppress references to pages, templates, images, categories in DPL3 output
}}
}}


Syntax:


'''Syntax:'''
<code>goal=<i>pages | categories</i></code>


<code>reset=''keyword,..''</code>, where {{tt|keyword}} is one of:
Explanation:
* <code>''categories''</code>
* <code>''templates''</code>
* <code>''images''</code>
* <code>''links''</code>
* <code>''all''</code> – A synonym for all of the above.


Default is 'pages', which means that DPL produces a list of pages. And this is exactly what the name DPL promises.


The output of a DPL3 statement typically creates links to all pages which are part of the result set. The inclusion of contents from other pages via DPL3 (using <code>include</code>) normally has the consequences:
If you set the goal parameter to 'categories' the list of pages will still be produced but you won´t see it. Instead it will be used to '''calculate a unique ordered list of all categories these pages belong to'''.
* The page containing the DPL3 query becomes part of the categories of the transcluded page.
* It shares ('adopts') their use of templates
* It shares their references to images
* It shares their references to other articles.


This allows you to ask a question like: Given all pages that are member of category X with a title matching "y%" and which use template "Z": to which categories do these pages belong?


In some cases, this may be useful. But in many cases, this is not wanted. Especially when DPL3 is used to create a printable document which contains the full text of other articles, duplicating all links, template uses etc., of those articles is probably undesired.
One of the more useful applications would be question like: "To which categories do the pages belong which contain a reference to the current page?"


The <code>reset</code> parameter suppresses all or some of the effects described above.
The output of "goal=categories" is technically a ''list of pages of type category''. This means that you can use all DPL formatting options (mode=userformat, listseparators, columns etc.) and pseudo variables (%TITLE%, %PAGE%) to customise the layout of your report.


There are some subtle differences here depending on the mode in which DPL3 is used. These differences affect the question of how links, and categories etc., are treated which are direct part of the document containing the DPL3 query.
''Technical Note:''
Example:
<pre><nowiki>
[[Category:Q Cat]] linking to [[Q Link]] and showing [[Image:Q Image]] and using {{Q Template}}
... DPL3 query which includes contents from other articles.
assuming that this contents contains links and images,
that it uses templates and that the articles are part of one or more categories
RESET statement at the end of the DPL3 query with one or more of 'categories,templates,images,links'
...
</nowiki></pre>


Due to some limitations in MySQL it is currently not possible to restrict the intermediate result set of pages to a certain maximum (using the LIMIT clause). In addition the generated SQL code is not in all cases optimal (as its structure provides for complex selection criteria and therefore is unnecessarily complex in simple cases). So be careful and apply precise selection criteria.


'''In parser extension mode''' (tag like <code><nowiki><dpl></nowiki></code>):
===allowcachedresults===
* <code>reset=''categories''</code> – Ignores categories of included contents but keeps 'own' categories like 'Q Cat'.
* <code>reset=''images''</code> – Throws away references to images contained in included contents but keeps 'own' images like 'Q Image'.
* <code>reset=''templates''</code> – Ignores templates used in included contents but keeps 'own' template usage ('Q Template').
* <code>reset=''links''</code> – Throws away all references to other pages, i.e., links contained in included contents and links like 'Q Link' are ignored. This means all links can be used in the normal "FORWARD" way, but no "BACKLINKS" are available for them.


{{DPL parameter
|name = allowcachedresults
|purpose= allow delivery of results based on cached database contents.
}}


To avoid the above described effect of <code>reset</code> on one's 'own' links, <code>{{DPL|eliminate}}</code> can be used. However, it is important to note that ''eliminate'' is rather expensive in terms of computer power, as it does a second parse for all included contents.
Syntax:


<code>allowcachedresults=<i>true | false | yes+warn</i></code>


''' In parser function mode''' (<code><nowiki>{{#dpl:....}}</nowiki></code>):
Explanation:
* <code>reset=''categories''</code> – Ignores all categories.<br>
* <code>reset=''images''</code> – Throws away all references to images.
* <code>reset=''templates''</code> – Ignores all template invocations.
* <code>reset=''links''</code> – Throws away all references to other pages.


Default is FALSE, so normally DPL will disable the parser cache before it produces a result. Disabling the cache produces some extra server load but guarantees always correct results.


Using <code>reset</code> in parser function mode clears everything, regardless of whether it comes from included contents or whether it is direct part of the document containing the DPL3 query.
So, if you do not use this parameter you will always get a result which is based on the latest changes made on any articles. But in many cases you could have gotten the same result with using less server resources!


To avoid the above described effect of <code>reset</code>, <code>{{DPL|eliminate}}</code> can be used. However, ''eliminate'' is rather expensive in terms of computing power, as it does a second parse for all included contents. The extra parser step is conducted as soon ''eliminate'' is specified. In terms of extra processing needed, it does not make a difference whether one or more arguments are specified for the ''eliminate'' command.
If you set 'allowcachedresults=true', the parser cache will be used. That means, your results might be a little bit outdated (usually one hour or so). But there are less resources used on the server side. You might want to experiment with that parameter and check the size of load reduction (i.e. gain in term of response time).


If there is '''more than one DPL3 query''' in a page, the effects depend on the exact mode (parser extension or parser function mode), on the sequence of the statements and on the presence of 'reset' or 'eliminate' statements in each of the queries and on their individual arguments. As this is a very rare case, only a simple rule of thumb is given here: Once 'reset' is used in parser function mode or <code>reset=links</code> in parser extension mode, the effect of these statements dominates the rest.
If you allow cached results you can still enforce DPL to produce a correct result via using "&action=purge" in the command line.


'yes+warn' will use the cache; in addition the result will contain a warning indicating that the result may be out-dated. This is achieved by including the template ''DPL Cache Warning'' into the result header. It is up to you to provide a useful text under that name, see e.g. [[Template:DPL Cache Warning]].


===reset===
==fixcategory==
{{DPL Parameter

|name = fixcategory
{{DPL parameter
|purpose= Assign the article containing a DPL3 statement to a category, although <code>reset</code> was used.
|name = reset
|purpose= suppress references to pages, templates, images, categories in DPL output
}}
}}


Syntax:


'''Syntax:'''
<code>reset=<i>keyword,..</i></code>, where ''keyword'' is one of:
*''categories''
*''templates''
*''images''
*''links''
*''all'' &mdash; a synonym for all of the above


<code>fixcategory=''category name''</code>
The output of a DPL statement typically creates links to all pages which are part of the result set. The inclusion of contents from other pages via DPL (using 'include') normally has the consequence
* that the page containing the DPL query becomes part of the categories of the transcluded page
* that it shares ('adopts') their use of templates
* that it shares their references to images
* that it shares their references to other articles.


In some cases this may be useful. But in many cases this is not wanted. Especially when you use DPL to create a printable document which contains the full text of other articles you will probably not want to duplicate all links, template uses etc. of those articles.


Use multiple commands to assign the article to more than one category.
The <tt>reset</tt> parameter will suppress all or some of the effects described above.


If <code>reset=''all''</code> or <code>reset=''categories''</code> are used, the article containing the DPL3 statement is not be recorded in the MediaWiki link database. This may be quite useful if an article transcludes content from other pages. Without the <code>{{DPL|reset}}</code> command, the article would appear in a category if a text portion containing an assignment to that category was used.
There are some subtle differences here depending on the mode in which you use DPL. These differences affect the question how links, and categories etc. are treated which are direct part of the document containing the DPL query.
Example:
<pre><nowiki>
[[Category:Q Cat]] linking to [[Q Link]] and showing [[Image:Q Image]] and using {{Q Template}}
... DPL query which includes contents from other articles.
assuming that this contents contains links and images,
that it uses templates and thatthe articles are part of one or more categories
RESET statement at the end of the DPL query with one or more of 'categories,templates,images,links'
...
</nowiki></pre>


As a side effect of using <code>reset=''all''</code>, the article does not appear in a category, even if one is literally assigned to it.
<u>In parser extension mode (DPL '''tag''' like &lt;DPL&gt;):</u>
<code>fixcategory</code> allows a category assignment to be made which is not blocked by the <code>reset</code> command.
;reset=categories: will ignore categories of included contents but keep 'own' categories like 'Q Cat'.
;reset=images: will throw away references to images contained in included contents but keep 'own' images like 'Q Image'.
;reset=templates: will ignore templates used in included contents but keep 'own' template usage ('Q Template').
;reset=links: will throw away all references to other pages, i.e. links contained in included contents and links like 'Q Link' will be ignored. This means that all links can be used in the normal "FORWARD" way, but no "BACKLINKS" are available for them.


If you want to avoid the above described effect of <tt>reset</tt> on your 'own' links you can use <tt>[[eliminate]]</tt>. But you should know that ''eliminate'' is rather expensive in terms of computer power as it does a second parse for all included contents.


==execandexit==
{{DPL Parameter
|name = execandexit
|purpose= Process the command given as an argument and then exit immediately.
}}


<u>In parser fuction mode ('''<nowiki>{{#DPL:....}}</nowiki>'''):</u>


'''Syntax:'''
;reset=categories: will ignore all categories
;reset=images: will throw away all references to images
;reset=templates: will ignore all template invocations
;reset=links: will throw away all references to other pages


<code>execandexit=''wiki text''</code>
As you see, using <tt>reset</tt> in parser function mode will clear everything regardless whether it comes from included contents or whether it is direct part of the document containing the DPL query.
<br>or<br>
<code>execandexit=''geturlargs''</code>


If you want to avoid the above described effect of <tt>reset</tt>, you can use <tt>[[eliminate]]</tt>. But you should know that ''eliminate'' is rather expensive in terms of computing power as it does a second parse for all included contents. The extra parser step is conducted as soon as you specify <tt>eliminate</tt>. In terms of extra processing needed it does not make a difference whether you specify one or more arguments for the 'eliminate' command.


If no wiki text is given, the command is ignored. Otherwise, DPL3 outputs the wiki text and exits immediately.
If you have '''more than one DPL query''' in a document the effects will depend on the exact mode (parser extension or parser function mode), on the sequence of the statements and on the presence of 'reset' or 'eliminate' statements in each of the queries and on their individual arguments. As this is a very rare case we only give a simple rule of thumb here: Once you have used 'reset' in parser function mode or 'reset=links' in parser extension mode the effect of these statements will dominate the rest.
Note that the wiki text may be a parser function call which evaluates to an empty string.


'''Example:'''<br><br><!-- transclude example from subpage-->{{#lsth:Examples/Parameter: execandexit (example 1)|Example}}
{{ViewTest|Examples|Parameter: execandexit (example 1)}}


'''Result:'''<br><br><!-- transclude example from subpage-->{{#lsth:Examples/Parameter: execandexit (example 1)|Result}}
=== fixcategory ===


The special word ''geturlargs'' can be used as a wiki text to transform URL arguments starting with <code>DPL_</code> into variables, which can then be accessed via #var (if the [[mw:Extension:Variables|Variables]] extension is installed) or via #dplvar.
{{DPL parameter
|name = fixcategory
|purpose= assign the article containing a DPL statement to a category although <tt>reset</tt> was used.
}}


Using this command, DPL3 can be prevented from executing a database query; this may be useful if the user did not give a necessary parameter. Note that an <code><nowiki>{{#if:}}</nowiki></code> ([[mw:Help:Extension:ParserFunctions|Parser Functions]] extension) function call would NOT help in that case because <code>#if</code> evaluates its complete content before taking the "if" or the "else" path. So, embedding a DPL3 call within an <code>#if</code> is much less efficient than using the ''execandexit'' function.
Syntax:
<code>fixcategory=<i>category name</i></code>


Use multiple commands to assign the article to more than one category.


'''Example:'''<br><br><!-- transclude example from subpage-->{{#lsth:Examples/Parameter: execandexit (example 2)|Example}}
If you use <tt>reset=all</tt> or <tt>reset=categories</tt> the article containing your DPL statement will not be recorded in the mediawiki link database. This may be quite useful if your article transcludes content from other pages. Without the <tt>reset</tt> command your article would appear in a category if you included a text portion containing an assignment to that category.
{{ViewTest|Examples|Parameter: execandexit (example 2)}}


As a side effect of using <tt>reset=all</tt> your article will not appear in a category even if you literally assign it to one.
The <tt>fixcategory</tt> allows you to make a category assignment which is not blocked by the [[reset]] command.


'''Result:'''<!-- transclude example from subpage-->{{#lsth:Examples/Parameter: execandexit (example 2)|Result}}
===eliminate===


{{DPL parameter
|name = eliminate
|purpose= suppress references to pages, templates, images, categories in DPL output
}}


'''See also:''' [[Template:DPL3 scroll]] and {{DPL|scrolling}}.
Syntax:


<code>eliminate=keyword,..</code>


{{note|'''Note:''' <code>execandexit</code> acts like a short-circuit evaluation. This means, for example, that successive statements to influence caching behavior (like <code>{{DPL|allowcachedresults}}</code>) are not interpreted.}}
Where <tt>keyword</tt> is one of:


* <tt>categories</tt>
* <tt>templates</tt>
* <tt>images</tt>
* <tt>links</tt>
* <tt>all</tt> &mdash; a synonym for all of the above


==updaterules==
The output of a DPL statement typically creates links to all pages which are part of the result set. The inclusion of contents from other pages via DPL (using <tt>[[include]]</tt>) normally has these consequences:
{{DPL Parameter
* the page containing the DPL query becomes part of the categories of the transcluded page
|name = updaterules
* shares ('adopts') their use of templates
|purpose= Define a set of rules which are executed to perform an update on selected articles (''bulk update'' or ''template value editing'')
* shares their references to images
{{note|'''Important:''' The <code>updaterules</code> feature is intended for wiki expert users only. It is recommended that articles using this statement are '[[mw:Help:Protecting and unprotecting pages|protected]]'.|error}}
* shares their references to other articles

In some cases this may be useful. But in many cases this is not wanted. Especially when you use DPL to create a printable document which contains the full text of other articles you will probably not want to duplicate all links, template uses etc. of those articles.

The <tt>eliminate</tt> parameter will suppress all or some of the effects described above.

For further explanation see <tt>[[reset]]</tt>.

Please note that the use of <tt>eliminate</tt> needs a considerable amount of extra computing power as it performs a second parser step for each included document.

===debug===

{{DPL parameter
|name = debug
|purpose= Sets debugging level.
}}
}}


Syntax:


'''Syntax:'''
<code>debug=<i>n</i></code>, where ''n'' is one of:
* ''0'' &mdash; silent mode, shows nothing
* ''1'' &mdash; quiet mode, shows (fatal) errors
* ''2'' &mdash; default mode, like 1 + shows warnings; &mdash; '''(default)'''
* ''3'' &mdash; verbose mode, like 2 + shows SQL query.
* ''4'' &mdash; for internal use only
* ''5'' &mdash; show Wiki text output from DPL instead of parsed wiki text
* ''6'' &mdash; show SQL query but DO NOT EXECUTE the query.


updaterules=
'''If you use debug param but not in first position in the DPL element, the new debug settings are not applied before all previous parameters have been parsed and checked.''' This will generate a warning for <code>debug=2</code> and above.
''rule'';
...
''rule'';


Where ''rule'' is one of the following:
Example:
# '''Rules for batch update of articles'''
#* A DPL3 query can select a group of articles and perform updates, like inserting a piece of text at a certain position, or changing text portions based on regular expressions.


replace ''pattern'';
<pre><nowiki>
by ''replacement'';
<DPL>
before ''pattern'';
namespace=Media
insert ''text'';
debug=0
after ''pattern'';
namespace=Special
insert ''text'';
</DPL>
<ol>
</nowiki></pre>
<li value="2">'''Rules for interactive update of articles'''</li>
</ol>
:* For interactive form-based editing of template values.
template ''template name'';
legend ''legend article name'';
table ''table format'';
editform ''form parameters'';
action ''form action'';
hidden ''value'';
submit ''submit button'';
commit ''commit button'';
parameter ''parameter name'';
value ''value'';
format ''display format'';
tooltip ''text'';
optional ''value'';
afterparm ''parameter name'';


<ol>
This list will output the error for the first namespace: ''Media'' is not a valid [[#namespace|namespace]] value (pseudo-namespace). Assuming you haven't changed the default debug value (2), you will also get a warning: <code>debug=1</code> is not input first (before <code>namespace=Media</code>). So it did not apply to <code>namespace=Media</code> but only to what's after. Indeed, you won't get the warning for the second namespace (''Special'') since <code>debug=0</code> changed debug settings to silent mode.
<li value="3">'''Common rules'''</li>
</ol>
:* Common to both other groups (batch update or interactive update of articles) and controls the update process.
summary ''edit summary text'';
exec ''value'';


{{note|'''Important:''' The <code>updaterules</code> feature is intended for wiki expert users only. It is recommended that articles using this statement are '[[mw:Help:Protecting and unprotecting pages|protected]]'.|error}}
DPL debug messages are translatable in <code>DynamicPageList2.i18n.php</code>. See also [[#Internationalization]].


'debug=1' will suppress warning messages (e.g. if the result set of a DPL query is empty). As an alternative, you can use the <tt>[[suppresserrors]]</tt> statement.


===Rules for batch update in detail:===
====replace ''pattern'';====
Defines a regular expression which matches text portions that shall be replaced. It is in the responsibility of the user to provide enclosing characters for the regexp; modifiers line 'U' or 'm' can be used.


===execandexit===


====by ''replacement'';====
{{DPL parameter
Defines the replacement for the above pattern; back references like \1 can be used.
|name = execandexit
|purpose= process the command given as an argument and then exit immediately.
}}


Syntax:


====before ''pattern'';====
<code>execandexit=<i>wiki text</i></code>
Defines locations where text will be inserted. The location(s) are immediately before the match(es) of the pattern. If a pattern matches multiple times, multiple inserts are performed.
<br>or<br>
<code>execandexit=<i>geturlargs</i></code>


The regexp will implicitly be enclosed in slashes. Hence, literal slash characters must be escaped by backslashes.
If no wiki text is given the command will be ignored. Otherwise DPL will output the wiki text and exit immediately.
Note that the wiki text may be a parser function call which evaluates to an empty string.


The special word ''geturlargs'' can be used as a wiki text to transform URL arguments into variables which can then be accessed via #var (if the Variables extension is installed) or via #dplvar.
Purpose:


====after ''pattern'';====
Using this command you can prevent DPL from executing a database query; this may be useful if a necessary parameter was not given by the user. Note that an ''#if'' function call would NOT help in that case because ''#if'' evaluates its complete content before taking the "if" or the "else" path. So, emebdding a DPL call within a #if is much less efficient than using the ''execandexit'' function.
Defines locations where text will be inserted. The location(s) are immediately after the match(es) of the pattern. If a pattern matches multiple times, multiple inserts are performed.


The regexp will implicitly be enclosed in slashes. Hence, literal slash characters must be escaped by backslashes.
A typical use would look like this (note the double pipe symbols within the #if.
Calling the following page with &cat=Country would list countries, omitting the &cat parameter would trigger the error text mnessage (without DPL going to the database):
<pre><nowiki>
{{#dpl:execandexit=geturlargs}}
{{#dpl:
| execandexit = {{#if:{{#dplvar:cat}}||please specify a category via &cat= in the URL!}}
| resultsheader = pages in category {{#dplvar:cat}}:\n
| noresultsheader = there are no pages in category {{#dplvar:cat}}.\n
| count = 5
| category = {{#dplvar:cat}}
}}
</nowiki></pre>


See also: [[Template:Extension DPL scroll]] and [[DPL Example 020]] and [[Scrolling]]


====insert ''text'';====
Note <tt>execandexit</tt> acts like a short-circuit evaluation. This means, for example, that successive statements to influence caching behaviour (like [[allowcachedresults]]) will not be interpreted.
Defines the text to be inserted.


A DPL3 statement may contain replacement, insertion, before, and after at the same time.
=== dplcache ===
<pre>
replace /([a-z]+])-cat/;
by \1-dog;
before foo;
insert bar;
after foo;
insert bar2;
</pre>


Only one <code>replace</code> - <code>by</code> sequence, one insertion <code>before</code> and one insertion <code>after</code> can be specified. <code>replace</code> is always executed first, followed by <code>insert before</code> and <code>insert after</code>, regardless of the sequence in which the rules appear in the DPL3 source text.
{{DPL parameter
|name = dplcache
|purpose= put the result of a DPL query in a special cache from where it is served until the cache expires
}}


Syntax:


===Rules for interactive update in detail:===
<code>dplcache=<i>name</i></code>
====template ''template name'';====
The name of the template; the prefix "Template:" must be given.


The location(s) are immediately before the match(es) of the pattern. If a pattern matches multiple times, multiple inserts are performed.
''name'' must be a symbol which is unique for the DPL statement WITHIN your page. As you will in most cases have only one DPL statement in your page, a simple symbol like '1' will be o.k.


The regexp will implicitly be enclosed in slashes. Hence, literal slash characters must be escaped by backslashes.
Purpose:


A regular expression:
Save processing time and avoid unnecessary resource consumption. You can decide how long the result of a DPL query shall be considered to be reasonably 'valid'. This may be longer or shorter than the ParserCacheExpiration time which you have configured in your LocalSettings.php.


after ''pattern'';
The DPLcache will even survive editing of the page which contains the DPL statememnt as long as the DPL statement remains unaltered.
insert ''text'';
replace ''pattern'';
by ''replacement'';


Details:


For safety reasons, the update statements are only performed if "exec yes" is specified. So, leaving this away, what would happen if the update were to be executed can be checked.
The cache is automatically registered under the page_id of your article. So there is no need to specify the page name or something similar here. Currently the cache is held in the file system (this may cahnge to the database in one of the next releases).


Note that if "exec yes" is present, the update is performed each time the page is rendered which contains the DPL3 statement with the <code>updaterules</code>. So, it is advisable to set "exec yes" only via a command line argument and not as part of the static article text. Thus, staying in control when the update happens. Typically, one would use a URL parameter like ''DPL_arg1'' for that purpose.
As the cache works on page_id level it will only affect the most recent version of each page. When viewing older revisions it may be useful to add ''&DPL_refresh=yes'' to the URL to make sure that the cache is rebuilt (if this is really desirable).


The size of the form fields adapts to the size of the displayed content.
If your page uses ''scrolling'' you can provide an ''advanced cache'' which will take each result page (if it is viewed). In this case the ''name'' should look like this:
<code>dplcache=offset/{%offset:0%}</code>
This will create a separate cache entry for each result page. If one of these pages is purged (i.e. the cache is to be refreshed), all corresponding pages will be thrown away as well. See [[DPL Example 022]] to understand the details of this mechanism.


<!--To make the use of the <code>updaterules</code> feature easier, we provide a [[Template:Bulk Update|special user interface]].
<u>The following principles apply to caching:</u>
Note: This template is deliberately not present, as it can apparently alter lots of wiki content. The line above is retained as a comment, since it was part of the original DPL3 documentation. -->


''text'' is plain text; ''replacement'' is text which may contain references (like \1) to the matching ''pattern'' (provided that this pattern contains match groups).
* By default MW uses a ParserCache with an expiration of 24 hours. The expiration period can be influenced via $wgParserCacheExpireTime.
* Once a page is in the ParserCache DPL will not be invoked any more as long as the cache is considered to be up-to-date. For this reason DPL normally DISABLES the MW ParserCache.
* On really huge websites you may still want to use the MW ParserCache in addition to the DPL cache. You can do so via setting 'allowcachedresults=true' as part of your DPL statement. Alternatively the administrator can configure DPL in a way that 'allowcachedresults=true' is the general default for DPL statements (set ExtDynamicPageList::$respectParserCache = true; after the require_once() for DPL).
* If DPL is used together with an active ParserCache DPL can only check its own cache as soon as the MW ParserCache has expired, i.e. you cannot have a shorter period for the DPL cache than the MW ParserCache has.
* You can always enforce the MWParserCache to be purged by adding &action=purge to the URL of a page. This will enforce a page refresh and DPL will be invoked. It can then find out if it still wants to rely on its DPL cache content or if it wants to re-execute the query against the database to produce the latest results and update its cache with that result.
* Purging the ParserCache will silently be accepted for usres who are logged in; anonymous users will get a "do you really want ..." confirmation box.
* Note that if your page contains more than one DPL statements, all of them need to set 'allowcachedresults=true' to avoid switching off the MW ParserCache. If, on the other hand, keeping the ParserCache is configured as DPL's default behaviour, the cache will be disabled as soon one of several DPL statements of a page explicitly switches it off via 'allowcachedresults=no'.
* Regardless of the DPL configuration in your LocalSettings.php the &lt;DynamicPageList&gt; tag will always use the ParserCache (for reasons of compatibility with older versions of Dynamic Page List aka Extension:Intersection).
* If a page is being served from the MW ParserCache there will be a respective comment in the HTML text - but the user will not get any notice. He may be surprosed however, that a page reflects 'outdated contents' although he has just made a change which should have had an impact on the DPL result being displayed.
* If you use the 'dplcache' command the user will see a little box under the DPL result which indiactes that the DPL cache has been used. It tells the user how old the content is and it can reduce the amount of annoyance caused by outdated results being taken from the cache. The note also offers a refresh button. If the MW ParserCache is active, however, this mechanism cannot work.
* Using the ''FlaggedRevisions Extension'' together with DPL caching adds another level of complexity as that extension uses an additional cache ("StableParserCache").


=== dplcacheperiod ===


==deleterules==
{{DPL parameter
{{DPL Parameter
|name = dplcacheperiod
|name = deleterules
|purpose= define the expiration period for the dplcache
|purpose= Allow the mass deletion of wiki pages
}}
}}


deleterules=
Syntax:
reason ''text'';
exec ''true'';

This command is experimental at the moment.


This deletes the selected pages; If "exec true" is missing, nothing happens.
<code>dplcacheperiod= <i>number of seconds</i></code>


[[Category:Primary Module|05]]
The default is 86400 seconds, i.e. one day.

Latest revision as of 08:37, 21 April 2023

Manual Parameters Other parameters


debug

Page Template:DPL parameter/styles.css must have content model "Sanitized CSS" for TemplateStyles (current model is "plain text").

debug Sets debugging level.


Syntax:

debug=n, where n is one of:

  • 0 – Silent mode, shows nothing.
  • 1 – Quiet mode, shows (fatal) errors.
  • 2 – Default mode, like 1 + shows warnings; – (default).
  • 3 – Verbose mode, like 2.
  • 4 – Dump raw SQL Query; only if $wgDebugDumpSql is set to true.
  • 5 – Show wiki text output from DPL3 instead of parsed wiki text.


Note: If the debug parameter is not used in the first position of the DPL3 statement, the new debug settings are not applied before all previous parameters have been parsed and checked. This generates a warning for debug=2 and above.


Example:

{{#lsth:Examples/Parameter: debug (example 1)|Example}}

Page Template:ViewTest/style.css must have content model "Sanitized CSS" for TemplateStyles (current model is "plain text").

Result:

{{#lsth:Examples/Parameter: debug (example 1)|Result}}


Notes:

  • DPL3 debug messages are translatable in DynamicPageList2.i18n.php.
  • debug=1 suppresses warning messages (e.g., if the result set of a DPL3 query is empty). As an alternative, the suppresserrors= statement can be used.


allowcachedresults

Page Template:DPL parameter/styles.css must have content model "Sanitized CSS" for TemplateStyles (current model is "plain text").

allowcachedresults Cache query results to improve performance, keep servers from crashing under high load.


Syntax:

allowcachedresults=value where value is one of:

  • true – (default, need not be set).
  • false – prevent caching.


Notes:

  • All queries are cached by default to reduce server load, as generally articles do not change often enough to require updating every page load.
  • If immediate updates are required every page load, such as for displaying scroll navigation via URL parameters, then set this parameter to false.
  • Cache period is handled by the cacheperiod parameter.


cacheperiod

Page Template:DPL parameter/styles.css must have content model "Sanitized CSS" for TemplateStyles (current model is "plain text").

cacheperiod Defines the expiration period for the DPL3 cache.


Syntax:

cacheperiod=number of seconds – (default is 3600, meaning 1 hour).


goal

Page Template:DPL parameter/styles.css must have content model "Sanitized CSS" for TemplateStyles (current model is "plain text").

goal Set the goal for DPL3 to either show pages (default) or categories these pages belong to.


Syntax:

goal=goaltype where goaltype can be one of:

  • pages – (default, need not be set).
  • categories.


DPL3 produces a list of pages by default, and this is precisely what the name DPL3 promises.


If the goal parameter is set to 'categories' the list of pages is still be produced, but is not seen. Instead, it is used to calculate a unique ordered list of all categories these pages belong to.


This allows the asking of question like: Given all pages that are a member of category X with a title matching "y%" and which use template "Z": to which categories do these pages belong?


One of the more useful applications would be a question like: "To which categories do the pages belong which contain a reference to the current page?"


The output of goal=categories is technically a list of pages of type category. This means that all DPL3 formatting options can be used (mode=userformat, listseparators, columns etc.) and pseudo variables (%TITLE%, %PAGE%) to customize the layout of the report.


Technical Note:

Due to some limitations in MySQL, it is currently not possible to restrict the intermediate result set of pages to a certain maximum (using the LIMIT clause). In addition, the generated SQL code is not in all cases optimal (as its structure provides for complex selection criteria and therefore is unnecessarily complex in simple cases). So be careful and apply precise selection criteria.


eliminate

Page Template:DPL parameter/styles.css must have content model "Sanitized CSS" for TemplateStyles (current model is "plain text").

eliminate Suppress references to pages, templates, images, categories in DPL3 output


Syntax:

eliminate=keyword,.. where keyword is one of:

  • categories
  • templates
  • images
  • links
  • all – A synonym for all of the above.


The output of a DPL3 statement typically creates links to all pages which are part of the result set. The inclusion of contents from other pages via DPL3 (using include) normally has these consequences:

  • The page containing the DPL3 query becomes part of the categories of the transcluded page.
  • It shares ('adopts') their use of templates.
  • It shares their references to images.
  • It shares their references to other articles.


In some cases, this may be useful. But in many cases, this is not wanted. Especially when DPL3 is used to create a printable document which contains the full text of other articles, duplicating all links, template uses etc., of those articles is probably undesired.

The eliminate parameter suppresses all or some of the effects described above.

For further explanation, see reset.

Note: The use of eliminate needs a considerable amount of extra computing power as it performs a second parser step for each included document.


reset

Page Template:DPL parameter/styles.css must have content model "Sanitized CSS" for TemplateStyles (current model is "plain text").

reset Suppress references to pages, templates, images, categories in DPL3 output


Syntax:

reset=keyword,.., where keyword is one of:

  • categories
  • templates
  • images
  • links
  • all – A synonym for all of the above.


The output of a DPL3 statement typically creates links to all pages which are part of the result set. The inclusion of contents from other pages via DPL3 (using include) normally has the consequences:

  • The page containing the DPL3 query becomes part of the categories of the transcluded page.
  • It shares ('adopts') their use of templates
  • It shares their references to images
  • It shares their references to other articles.


In some cases, this may be useful. But in many cases, this is not wanted. Especially when DPL3 is used to create a printable document which contains the full text of other articles, duplicating all links, template uses etc., of those articles is probably undesired.

The reset parameter suppresses all or some of the effects described above.

There are some subtle differences here depending on the mode in which DPL3 is used. These differences affect the question of how links, and categories etc., are treated which are direct part of the document containing the DPL3 query. Example:

[[Category:Q Cat]] linking to [[Q Link]] and showing [[Image:Q Image]] and using {{Q Template}}
... DPL3 query which includes contents from other articles.
    assuming that this contents contains links and images, 
             that it uses templates and that the articles are part of one or more categories
    RESET statement at the end of the DPL3 query with one or more of 'categories,templates,images,links'
...


In parser extension mode (tag like <dpl>):

  • reset=categories – Ignores categories of included contents but keeps 'own' categories like 'Q Cat'.
  • reset=images – Throws away references to images contained in included contents but keeps 'own' images like 'Q Image'.
  • reset=templates – Ignores templates used in included contents but keeps 'own' template usage ('Q Template').
  • reset=links – Throws away all references to other pages, i.e., links contained in included contents and links like 'Q Link' are ignored. This means all links can be used in the normal "FORWARD" way, but no "BACKLINKS" are available for them.


To avoid the above described effect of reset on one's 'own' links, eliminate can be used. However, it is important to note that eliminate is rather expensive in terms of computer power, as it does a second parse for all included contents.


In parser function mode ({{#dpl:....}}):

  • reset=categories – Ignores all categories.
  • reset=images – Throws away all references to images.
  • reset=templates – Ignores all template invocations.
  • reset=links – Throws away all references to other pages.


Using reset in parser function mode clears everything, regardless of whether it comes from included contents or whether it is direct part of the document containing the DPL3 query.

To avoid the above described effect of reset, eliminate can be used. However, eliminate is rather expensive in terms of computing power, as it does a second parse for all included contents. The extra parser step is conducted as soon eliminate is specified. In terms of extra processing needed, it does not make a difference whether one or more arguments are specified for the eliminate command.

If there is more than one DPL3 query in a page, the effects depend on the exact mode (parser extension or parser function mode), on the sequence of the statements and on the presence of 'reset' or 'eliminate' statements in each of the queries and on their individual arguments. As this is a very rare case, only a simple rule of thumb is given here: Once 'reset' is used in parser function mode or reset=links in parser extension mode, the effect of these statements dominates the rest.


fixcategory

Page Template:DPL parameter/styles.css must have content model "Sanitized CSS" for TemplateStyles (current model is "plain text").

fixcategory Assign the article containing a DPL3 statement to a category, although reset was used.


Syntax:

fixcategory=category name


Use multiple commands to assign the article to more than one category.

If reset=all or reset=categories are used, the article containing the DPL3 statement is not be recorded in the MediaWiki link database. This may be quite useful if an article transcludes content from other pages. Without the reset command, the article would appear in a category if a text portion containing an assignment to that category was used.

As a side effect of using reset=all, the article does not appear in a category, even if one is literally assigned to it. fixcategory allows a category assignment to be made which is not blocked by the reset command.


execandexit

Page Template:DPL parameter/styles.css must have content model "Sanitized CSS" for TemplateStyles (current model is "plain text").

execandexit Process the command given as an argument and then exit immediately.


Syntax:

execandexit=wiki text
or
execandexit=geturlargs


If no wiki text is given, the command is ignored. Otherwise, DPL3 outputs the wiki text and exits immediately. Note that the wiki text may be a parser function call which evaluates to an empty string.

Example:

{{#lsth:Examples/Parameter: execandexit (example 1)|Example}}

Page Template:ViewTest/style.css must have content model "Sanitized CSS" for TemplateStyles (current model is "plain text").

Result:

{{#lsth:Examples/Parameter: execandexit (example 1)|Result}}

The special word geturlargs can be used as a wiki text to transform URL arguments starting with DPL_ into variables, which can then be accessed via #var (if the Variables extension is installed) or via #dplvar.

Using this command, DPL3 can be prevented from executing a database query; this may be useful if the user did not give a necessary parameter. Note that an {{#if:}} (Parser Functions extension) function call would NOT help in that case because #if evaluates its complete content before taking the "if" or the "else" path. So, embedding a DPL3 call within an #if is much less efficient than using the execandexit function.


Example:

{{#lsth:Examples/Parameter: execandexit (example 2)|Example}}

Page Template:ViewTest/style.css must have content model "Sanitized CSS" for TemplateStyles (current model is "plain text").


Result:{{#lsth:Examples/Parameter: execandexit (example 2)|Result}}


See also: Template:DPL3 scroll and scrolling.


Note: execandexit acts like a short-circuit evaluation. This means, for example, that successive statements to influence caching behavior (like allowcachedresults) are not interpreted.


updaterules

Page Template:DPL parameter/styles.css must have content model "Sanitized CSS" for TemplateStyles (current model is "plain text").

updaterules Define a set of rules which are executed to perform an update on selected articles (bulk update or template value editing)
Important: The updaterules feature is intended for wiki expert users only. It is recommended that articles using this statement are 'protected'.


Syntax:

updaterules=
    rule;
    ...
    rule;

Where rule is one of the following:

  1. Rules for batch update of articles
    • A DPL3 query can select a group of articles and perform updates, like inserting a piece of text at a certain position, or changing text portions based on regular expressions.
    replace pattern;
        by     replacement;
    before  pattern;
        insert text;
    after   pattern;
        insert text;
  1. Rules for interactive update of articles
  • For interactive form-based editing of template values.
    template  template name;
    legend    legend article name;
    table     table format;
    editform  form parameters;
    action    form action;
    hidden    value;
    submit    submit button;
    commit    commit button;
    parameter parameter name;
        value     value;
        format    display format;
        tooltip   text;
        optional  value;
        afterparm parameter name;
  1. Common rules
  • Common to both other groups (batch update or interactive update of articles) and controls the update process.
    summary edit summary text;
    exec    value;


Important: The updaterules feature is intended for wiki expert users only. It is recommended that articles using this statement are 'protected'.


Rules for batch update in detail:

replace pattern;

Defines a regular expression which matches text portions that shall be replaced. It is in the responsibility of the user to provide enclosing characters for the regexp; modifiers line 'U' or 'm' can be used.


by replacement;

Defines the replacement for the above pattern; back references like \1 can be used.


before pattern;

Defines locations where text will be inserted. The location(s) are immediately before the match(es) of the pattern. If a pattern matches multiple times, multiple inserts are performed.

The regexp will implicitly be enclosed in slashes. Hence, literal slash characters must be escaped by backslashes.


after pattern;

Defines locations where text will be inserted. The location(s) are immediately after the match(es) of the pattern. If a pattern matches multiple times, multiple inserts are performed.

The regexp will implicitly be enclosed in slashes. Hence, literal slash characters must be escaped by backslashes.


insert text;

Defines the text to be inserted.

A DPL3 statement may contain replacement, insertion, before, and after at the same time.

     replace /([a-z]+])-cat/;
     by      \1-dog;
     before  foo;
     insert  bar;
     after   foo;
     insert  bar2;

Only one replace - by sequence, one insertion before and one insertion after can be specified. replace is always executed first, followed by insert before and insert after, regardless of the sequence in which the rules appear in the DPL3 source text.


Rules for interactive update in detail:

template template name;

The name of the template; the prefix "Template:" must be given.

The location(s) are immediately before the match(es) of the pattern. If a pattern matches multiple times, multiple inserts are performed.

The regexp will implicitly be enclosed in slashes. Hence, literal slash characters must be escaped by backslashes.

A regular expression:

    after   pattern;
    insert  text;
    replace pattern;
    by      replacement;


For safety reasons, the update statements are only performed if "exec yes" is specified. So, leaving this away, what would happen if the update were to be executed can be checked.

Note that if "exec yes" is present, the update is performed each time the page is rendered which contains the DPL3 statement with the updaterules. So, it is advisable to set "exec yes" only via a command line argument and not as part of the static article text. Thus, staying in control when the update happens. Typically, one would use a URL parameter like DPL_arg1 for that purpose.

The size of the form fields adapts to the size of the displayed content.


text is plain text; replacement is text which may contain references (like \1) to the matching pattern (provided that this pattern contains match groups).


deleterules

Page Template:DPL parameter/styles.css must have content model "Sanitized CSS" for TemplateStyles (current model is "plain text").

deleterules Allow the mass deletion of wiki pages
deleterules=
    reason text;
    exec   true;

This command is experimental at the moment.

This deletes the selected pages; If "exec true" is missing, nothing happens.