Difference between revisions of "DPL:Manual - DPL parameters: Other parameters"

Revision as of 11:04, 13 June 2009

updaterules

Syntax:

updaterules=
    rule;
    ...
    rule;

Where rule is one of the following:

 before  pattern;
 after   pattern;
 insert  text;
 replace pattern;
 by      replacement;
 summary edit summary text;
 exec    true;

A pattern is a regular expression, typically enclosed within slashes; 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 updaterules feature is intended for wiki expert users only. Wrongly used it can create a big mess in your wiki!

For safety reasons the update statements will only be performed if "exec true" is specified. So, leaving this away, you can check what would happen if the update were to be executed.

Note that if "exec true" is present the update will be performed each time the page is shown which contains the DPL statement with the updaterules. So it is advisable to remove "exec true" immediately after the page has been shown once.

To make the use of the updaterules feature easier we provide a special user interface.

deleterules

deleterules=

    reason text;
    exec true;

This will delete the selected pages; If "exec true" is missing, nothing will happen.

goal

Syntax:

goal=pages | categories

Explanation:

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

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.

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?

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 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.

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.

allowcachedresults

Syntax:

allowcachedresults=true | false | yes+warn

Explanation:

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.

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!

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 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

Syntax:

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

• categories
• templates
• images
• links
• all — a synonym for all of the above

Please note that the behaviour of MediaWiki has changed with MW 1.14. 
MW does no longer insert backreferences to hyperlinks created by extensions.
So the use of reset and eliminate is obsolete with MW 1.14 and later. 

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.

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

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:

 [[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'
 ...

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

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 reset on your 'own' links you can use eliminate. But you should know that eliminate is rather expensive in terms of computer power as it does a second parse for all included contents.

In parser fuction mode ({{#DPL:....}}):

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

As you see, using reset 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.

If you want to avoid the above described effect of reset, you can use eliminate. 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 eliminate. In terms of extra processing needed it does not make a difference whether you specify one or more arguments for the 'eliminate' command.

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.

eliminate

Syntax:

eliminate=keyword,..

Where keyword is one of:

• categories
• templates
• images
• links
• all — a synonym for all of the above

Please note that the behaviour of MediaWiki has changed with MW 1.14. 
MW does no longer insert backreferences to hyperlinks created by extensions.
So the use of reset and eliminate is obsolete with MW 1.14 and later. 

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 these consequences:

• the page containing the DPL query becomes part of the categories of the transcluded page
• shares ('adopts') their use of templates
• shares their references to images
• 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 eliminate parameter will suppress all or some of the effects described above.

For further explanation see reset.

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

debug

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 + shows SQL query.
• 4 — for internal use only
• 5 — show Wiki text output from DPL instead of parsed wiki text
• 6 — show SQL query but DO NOT EXECUTE the query.

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 debug=2 and above.

Example:

<DPL>
  namespace=Media
  debug=0
  namespace=Special
</DPL>

This list will output the error for the first namespace: Media is not a valid namespace value (pseudo-namespace). Assuming you haven't changed the default debug value (2), you will also get a warning: debug=1 is not input first (before namespace=Media). So it did not apply to namespace=Media but only to what's after. Indeed, you won't get the warning for the second namespace (Special) since debug=0 changed debug settings to silent mode.

DPL debug messages are translatable in DynamicPageList2.i18n.php. 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 suppresserrors statement.

execandexit

Syntax:

execandexit=command (wiki text)

The wiki text given as an argument will be parsed. After this is done nothing else will happen and DPL will return the result of the command.

Purpose:

The only purpose of this command is to make DPL's URL commandline parameters accesible for other templates.

DPL 1.8.0 and later can take a couple of parameters from the URL command line, like DPL_offset for instance; these parameters can be accessed within DPL via a special syntax: {%DPL_offset%}. This helps to create pages which allow to scroll easily through huge result sets. For example you could write an article called 'MyPopularArticles' containing a DPL query like:

<dpl>
  category = my popular category
  count=100
  offset={%DPL_offset%}
  columns=3
</dpl>

Calling http://mywebsite/mywiki/index.php?title=MyPopularArticles will give you the first 100 articles in the category. Adding &DPL_offset=100 will give you the next hundred articles. This mechanism can be used to create a generic page scroll feature - provided you can access the value of DPL_offset also in other templates outside DPL. And this is where the execandexit command comes in: it can be used to store the URL parameter in a variable. We use the 'Variables' extension for that purpose, but other constructions are possible. The whole could look like this:

{{#dpl:execandexit=²{#vardefine:offset¦{%DPL_offset%} }² }}
Showing 100 pages starting from page {{#expr:{{#var:offset}} + 1}}:
<dpl>
  category = my popular category
  count=100
  offset={%DPL_offset%}
  columns=3
</dpl>

Note that we have to use the ²{ ... ¦ ... }² symbols because we want to pass the template invocation to DPL. Had we used standard syntax the MW parser would have expanded the template call to #vardefine before DPL would see it.

See also: Template:Extension DPL scroll and DPL Example 020

dplcache

Syntax:

dplcache=name

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.

Purpose:

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.

The DPLcache will even survive editing of the page which contains the DPL statememnt as long as the DPL statement remains unaltered.

Details:

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).

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).

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: dplcache=offset/{%offset:0%} 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.

The following principles apply to caching:

• By default MW uses a ParserCache with an expiration of 24 hours. The epiration 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 <DynamicPageList> 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").