|
===updaterules===
{{DPL parameterParameter
|name = updaterules
|purpose= define a set of rules which are executed to perform an update on selected articles (''bulk update'' or ''template value editing'')
===deleterules===
{{DPL parameterParameter
|name = deleterules
|purpose= allow the mass deletion of wiki pages
===goal===
{{DPL parameterParameter
|name = goal
|purpose= set the overall goal for DPL to either show '''pages''' (default) or '''categories''' these pages belong to
===allowcachedresults===
{{DPL parameterParameter
|name = allowcachedresults
|purpose= allow delivery of results based on cached database contents.
===reset===
{{DPL parameterParameter
|name = reset
|purpose= suppress references to pages, templates, images, categories in DPL output
=== fixcategory ===
{{DPL parameterParameter
|name = fixcategory
|purpose= assign the article containing a DPL statement to a category although <tt>reset</tt> was used.
===eliminate===
{{DPL parameterParameter
|name = eliminate
|purpose= suppress references to pages, templates, images, categories in DPL output
===debug===
{{DPL parameterParameter
|name = debug
|purpose= Sets debugging level.
===execandexit===
{{DPL parameterParameter
|name = execandexit
|purpose= process the command given as an argument and then exit immediately.
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.
=== dplcachecacheperiod ===
{{DPL parameterParameter
|name = dplcachecacheperiod
|purpose= put the result of a DPL query in a special cache from where it is served until the cache expires
}}
Syntax:
<code>dplcache=<i>name</i></code>
''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:
<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.
<u>The following principles apply to caching:</u>
* 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 <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").
=== dplcacheperiod ===
{{DPL parameter
|name = dplcacheperiod
|purpose= define the expiration period for the dplcache
}}
Syntax:
<code>dplcacheperiodcacheperiod= <i>number of seconds</i></code>
The default is 864003600 seconds, i.e.which is one dayhour.
| 
This wiki has been automatically closed because there have been no edits or log actions made within the last 60 days. If you are a user (who is not the bureaucrat) that wishes for this wiki to be reopened, please request that at Requests for reopening wikis. If this wiki is not reopened within 6 months it may be deleted. Note: If you are a bureaucrat on this wiki, you can go to Special:ManageWiki and uncheck the "Closed" box to reopen it.