Difference between revisions of "DPL:Bug Reports"

Revision as of 20:54, 2 September 2007

Please add new bugs concerning DPL at the bottom of this document.

If possible create a page in this wiki which demonstrates the bug and refer to that page!

Old bug reports have been moved to the DPL:Bug Reports Archive...

ordermethod ignored form2 demo (repost)

{{# dpl:
|category=Untranslated
|namespace=FollowTheScore
|shownamespace=false
|ordermethod=titlewithoutnamespace,firstedit
|addeditdate=true
|adduser=true
|addpagesize=true
|mode=userformat
|listseparators=¶{¦class="sortable" ¶!Script ¶!Last ¶!By ¶!Size,¶¦-¶¦style="background:#ccffcc;"¦%TITLE%¶¦%DATE%¶¦%USER%¶¦%SIZE%,¶,¶¦}
|secseparators=\n¦
}}

ordermethod is not processed. Bug to be reported in bugtracker. 82.255.229.238 14:30, 9 August 2007 (CEST)

The bug fix was included into the latest revision (1.3.3) Gero 11:13, 17 August 2007 (CEST)

Resultsheader with columns

The %PAGES% gives back <number of pages>/columns instead of <number of pages>. Is this intentional or a bug?

Page:Resultsheaderwithcolumns

It is a bug and will be resolved. Gero 21:08, 24 July 2007 (CEST)

DPL and Glossary clashing

Question

Using DPL with Glossary seems to result in difficulties in combining categories. Thus previously working combinations of categories result in filtering of output only by the first category, and much larger outputs than intended.

Curious! Any ideas on a work-around?

Reply

What is 'glossary'? Another mediawiki extension? If you want help you need to be more specific. You could upload a well-prepared example. If the glossary extension is needed for that I may be able to install it on this wiki. Gero 18:05, 22 July 2007 (CEST)

Reply

Glossary is a Mediawiki extension http://www.mediawiki.org/wiki/Extension:Glossary The following is part of the example Glossary I was using.

AAP//American Academy of Pediatrics
ABR//auditory brainstem responses
ACE//angiotensin-converting enzyme
ACPC//Area Child Protection Committee now Local Safeguarding Children's Board
ADH//antidiuretic hormone
ADHD//attention deficit hyperactivity disorder

The purpose of Glossary is to show the detailed text (after the //) when the mouse is over the abbreviated text.

I previously had functional queries in DPL. Subsequently, I added Glossary and could get this working. However, when I went back to my pages that used DPL, I found that they had been corrupted producing far more results than usual. This suggested that Glossary was somehow interfering with the DPL logic. I switched Glossary off, as DPL is more useful to me, and found that DPL worked as before.

All Chinese messages are wrong in DynamicPageList2.i18n.php

Every Chinese character has become "??", not normal Chinese character.The DynamicPageList2.i18n.php in the Zip file here also has wrong Chinese characters. See this page if you want to get the DynamicPageList2.i18n.php with right Chinese character.--Roc michael 11:42, 4 July 2007 (CEST)

DPL and RSSfeeds clashing

Hi, our wiki uses Xfeeds and DynamicPageList extensions. There seems to be a problem when they are used on the same page though. An error occurs in the magpierss file that causes the formatting of the page to display the error at the top of the page, and then display the rest of the page. The error occurs on line 404 of the magpie file that Xfeeds uses. Is there a way to fix this?

Columns Bug

When I use the columns setting, it breaks the background-colour I have set. If I remove it, the background-colour comes back.
Contact me here, if you have any further questions.
--Jamie

Can you demonstrate the effect here or in your wiki? Gero 05:18, 25 July 2007 (CEST)

Sorry about that.

Here ya go. :)

--Jamie

Have you seen DPL:Requests_for_new_features_Archive#Global background-color? Maybe you have the same problem?

Gero 15:30, 27 July 2007 (CEST)

When using simple tables in the included page

When using simple tables in the included page, the first to be included looks strange Table bug and not as the original Table Bug 2. All the others Table Bug 3 and Table Bug 4 look different but still not right in the DPLed list.

Is this a bug? And if so is there a workaround or anything I can do to avoid that (except of not using simple tables...)? Please inform me about your reply: NaSe1977 13:11, 25 July 2007 (CEST)

You may consider it a bug or a feature: DPL does not automatically insert newlines between the articles. That´s the reason why the output looks so strange. I modified your Table bug article to show how two additional lines solve the problem.

Gero 16:52, 26 July 2007 (CEST)

Thanks a lot, this helped. Strange enough my DPL2 1.2.9 does not seem to know format, do I have to enable it anyhow? (I used mode=userformat' and 'listseparators=...' instead)

NaSe1977 09:15, 27 July 2007 (CEST)

You may have downloaded the ZIP file just before I had updated it. Please try again and look for the String "'format'" in the source. Gero 09:51, 27 July 2007 (CEST)

Parser functions and templates in <dlp> versus #dpl

I try to call a parser function from within <dpl> and #dpl and find that the latter does not work. For example, I have the following

listseparators=,\n* [[%PAGE%|%TITLE%]]   (%CATLIST%)({{HEKtest3|%PAGE%}}) {{#sub:%TITLE%|0|7}},   

using <dpl> both the #sub function and the HEKtest3 template works as they shall. For #dpl, the result of the #sub is just the text TITLE. For the macro HEKtest3 it's even more strange, because if I output the parameter like {{{1}}}} it works fine, but if I use #sub on the parameter within the same template it does not output anything. So it seems the template has the correct value, but can not use it for anything other than simple output.

Again - this works fine with <dpl>.

Could it be the pipe-character that is the problem?

Thanks H

Possibly; try using template:! or ¦ per DPL:Manual - General Usage and Invocation Syntax#Using DPL2 as a parser function. -Eep² 12:34, 9 August 2007 (CEST)

Thanks - it helped a little. But:

• {{HEKtest3¦%CATNAMES%}} now works fine. The template is able to use the content of %CATNAMES%
• {{HEKtest3¦%PAGE%}} does not work! It creates an output that contains a link to the HEKtest3 template with the content of %PAGE% as the dislpay text. Weird!
• {{HEKtest3¦%TITLE%}} caused the same problem as above
• The #sub function does not work with ¦ either (see description of problem above)

Well, if all you want are the page name and title, try using the MediaWiki magic words {{FULLPAGENAME}} (includes namespace) and {{PAGENAME}} (page title only). -Eep² 17:50, 10 August 2007 (CEST)

Thanks, but that only gives me the name of the page I'm on, and not the name of the page retrieved by the #dpl function

This problem can be easily solved in the latest revision with ²{...}², see the manual. The idea is that this special markup will be translated to twin curly braces during the iteration over the DPL result set. Gero 20:49, 15 August 2007 (CEST)

addpagesize does not correctly report the size of the page

This is a bit pedantic, but its an important 'bug' in my wiki; See the following;

<dpl>
category = page size test
mode = ordered
ordermethod = size
order = ascending
addpagesize = true
</dpl>

1. Page size test page 1 [89 B]
2. Page size test page 2 [771 B]

As you can see by clicking above both pages are apparently about the same size, and page 1 is aparently a bit bigger. By looking at the source of the two pages we can see that this is only the case once the included template text has been taken into account. That is why I call "ordermethod = size" and "addpagesize = true" buggy... They should use the apparent size of the 'rendered page', not the size of the source code for that page.

I think this could be fixed... It would be a big help for me if it was... http://biodatabase.org/index.php/Sandbox

Thanks for the great extension! --Dmb 09:32, 10 August 2007 (CEST)

--Dmb 09:32, 10 August 2007 (CEST)

Reply

Summing up the size of included templates would be quite time consuming. I suggest that you create a DPL query which goes over the "original master date" (The copyrighted articles, I assume) and that you convert the link which DPL presents to the user into a link which points to your own article. Of course this is only possible if your article has a 1:1 correspondence with the master articles and if there is a consistent naming convention so that the name of your article can be algorithmically deduced from the master article´s name. O.k.??
Gero 20:54, 15 August 2007 (CEST)

Yup... but how do I do it??? Cheers, --87.160.217.187 20:09, 24 August 2007 (CEST)

Quite simple: use the namespace, categories etc. which apply to your raw data articles, set addpagesize=yes and use 'replaceintitle' to make the transformation of the title. Have a careful look into ther manual ;-). If you really can´t figure out how to do it, create demo pages which reflect the principle structure of your current pages here in this wiki and I´ll show you how to do it. ::::

Wrong number of items per column

Hi, I'm dealing with a DPL report that finds 116 articles and place them in 8 columns as specified by the following DPL parser function:

{{#dpl:
   |titleregexp=^TRB....$
   |mode=userformat
   |listseparators={{!}} valign="top" style="padding-right:20px;" {{!}},\n* [[%TITLE%]],,
   |columns=8
   |rowcolformat=style="color:black; background-color:white; text-align:left; vertical-align:top;"
   |replaceintitle=/ /,_
}}

The problem is: I get four columns with 15 items and four columns with 14 items, when the ideal would be 7 columns with 15 items and the last column with whatever is left (11 in this specific case). Is this some kind of off-by-one error in the code? I will try to reproduce it here, with a smaller number of articles: stay tuned!- Manu3d 13:29, 16 August 2007 (CEST)

By the way, this is a screenshot of what I see:

(A few minutes later) I managed to reproduce the problem but it seems to point to a conceptual issue. Check out my user page. The problem is that the code tries to spread evenly the results over the maximum number of columns, adapting the number of items per column to put something into each column. Ideally, using "rows=" together with "columns=" estabilishes the number of items each column contains, potentially reducing the number of visible columns from the number estabilished by the user.

Is there a way around this?

Thanks for your help. - Manu3d 13:52, 16 August 2007 (CEST)

Reply

Indeed DPL tries to spread the results evenly over the columns. So far nobody complained about that... Why is it important to have a less well balanced output scheme? Gero 23:00, 16 August 2007 (CEST)

That isn't balanced, Gero. It should be equal column lengths until the very last column. At least make your idea of "balanced" columns optional... Your way seems balanced for horizontal/row lists (as in Special:Allpages):

 1  2  3  4
 5  6  7  8
 9 10 11 12
13 14 15 16

and not vertical/column lists:

1 5  9 13
2 6 10 14
3 7 11 15
4 8 12 16

-Eep² 11:10, 17 August 2007 (CEST)

I agree with Eep², the current way of handling it seems to originate from row-oriented thiking and it's fine for that purpose. But you wouldn't want a row-oriented result looking like this, would you:

 1  2  3  4
 5  6  7  8
 9 10 11 12
13 14 15
16 17 18
19 20 21

-Manu3d 11:38, 17 August 2007 (CEST)

Decision

O.k., your arguments convinced me. Will be changed in the next version. Gero 14:38, 17 August 2007 (CEST)

Well, you don't have to choose one way over the other, but if you allow both list directions (as an option), the associated balancing should take effect with it. -Eep² 15:12, 17 August 2007 (CEST)

Question Re: Templates

This isn't really a bug, but I wanted ask about this. If I have a template called 'Awards' and the template took too fields 'Award' and 'Date' where Award is a name of an award from a specific list and date is the date its awarded, can I use DPL to get a list of all pages using the 'Awards' template with 'Five Year Award' in the Award field? -Thanks. 18:21, 18 August 2007 (CEST)

Answer

You should be able to do this with uses=Template:Award, include={Awards}.dpl and includematch=/Five Year Award/ ; see the manual for details. There are examples for similar applications of DPL on this website. Your template Awards.dpl should contain code that produces a table row in your result. Gero 20:41, 18 August 2007 (CEST)

The bug of Template:Catlist?

Could anyone give me a hand? please! —The preceding unsigned comment was added by Roc michael (talk • contribs) 06:36, August 21, 2007. Please sign your posts!

Do you have Simple Forms and Call installed per DPL:Catlist? -Eep² 09:08, 25 August 2007 (CEST)

Thank you, Eep²! Please see The bug(s) is/are nothing about DPL.

environment setting

• MediaWiki: 1.10.0
• PHP: 5.1.6 (apache2handler)
• MySQL: 5.0.24a-community-nt-log
• Parser hooks
  1. CategoryTree
  2. CharInsert
  3. Cite
  4. CreateBox (version 1.5)
  5. CSS (version 1.0.0, 2007-06-15)
  6. CurrentUsers (version 1.0.2, 2007-07-26)
  7. DPLforum (version 3.2)
  8. DynamicPageList2 (version 1.3.1)
  9. Inputbox
  10. LabeledSectionTransclusion
  11. NiceCategoryList
  12. ParserFunctions
  13. RegexParserFunctions (version 0.1)
  14. Semantic Forms (version 0.5)
  15. Semantic MediaWiki (version 0.7)
  16. Simple Forms (version 0.3.4, 2007-08-03)
  17. SimpleTable
  18. StackFunctions (version 0.6)
  19. StringFunctions (version 1.9.3)
  20. SyntaxHighlight
  21. Variables
  22. Winter (Wiki INTERpreter) (version 2.0.2)

Reply

Open the Catlist article and remove one leading '{' from the #dpl statement. Thus you will see the input which is sent to DPL. Then check the argument of the namespace parameter. You seem to have user defined namespaces. Make sure that they start with numbers of 100 and greater (as recommended). Gero 16:24, 21 August 2007 (CEST)

Different results

Thank you, Gero!

After your instructions, I'v found that some different results, but I still don't know what're the reasons. The statements like bellows:

 {{#dpl: namespace=Category | format = ,\n*%TITLE%,, }}

and

 {{#dpl: namespace=Template | format=,\n*%TITLE%,, }}

Could cause the results

%DPL-1.3.1-??: ??? 'namespace' ??: 'Category'! ??: namespace= ???? (?) | Attribute | Attribute_talk | RD | RD_talk | Relation | Relation_talk....?

and

%DPL-1.3.1-??: ??? 'namespace' ??: 'Template'! ??: namespace= ???? (?) | Attribute | Attribute_talk | RD | RD_talk | Relation | Relation_talk....?

But in this site thay don't make this results? I notice that the version of between this site and mime are different. Is it the reason. Please help me! --Roc michael 00:51, 22 August 2007 (CEST)

The bug(s) is/are nothing about DPL

After several my testing I found the bug(s) I met is/are nothing about DPL. The reason of the bug(s) is/are that I've ruined my testwiki by changing charset of Localsetting.php to utf8 and ansi again and again.

Whan I changed the charset of Localsetting.php, my wiki-system will become unstable and some arguments of DPL can't work.

Thank Gero and others. You are very kind.--Roc michael 14:42, 22 August 2007 (CEST)

SQL error with uses= and linksfrom=

1.3.2 had this bugfix:

Bugfix with SQL error

ambiguous 'page_name' in SQL statement fixed (appeared when namespace= and linksfrom= were used together)

I believe there is a similar bug with 'page_id' in the SQL statement which appears when uses= and linksfrom= are used together. I put an example on Test linksfrom, which now errors: MySQL returned error "1052: Column 'page_id' in where clause is ambiguous (localhost)". It appears that uses= adds a reference to page_id which should be something like `page`.page_id instead.

Answer

Thank you for reporting that error. If you find a problem with a DPL statement, please add 'debug=4' as first parameter. This will echo the SQL statement even if it is buggy. Otherwise calling an article with such a DPL statement will reuslt in an empty page so that the user has no idea what went wrong.

Indeed there are some other parameter combinations (only with linksfrom) which cause the same error, for example revision+linksfrom. Will be repaired. Gero 09:06, 24 August 2007 (CEST)

Direct subcategory feature broken by spaces?

I added this example to Test category hierarchy‎. "category=*African Country" appears to not descend any subcategories, but "category=*African_Country" works correctly. —The preceding unsigned comment was added by 64.186.172.226 (talk • contribs) 18:43, August 23, 2007. Please sign your posts!

Yes. The bug will be corrected soon. Gero 14:40, 26 August 2007 (CEST)

Deleted pages show up on Special:Wantedpages

I have a query that pulls back a list of pages in a category called "Spec Work Required". I've had two matching articles that proved to be unnecessary and were deleted. They no longer show on the page with the query, but when I look at the special page, "Wanted Pages", they appear.

I restored one of them, removed the categories, saved the change, and deleted the article again, and it still appears on the Wanted Pages list.

The wiki where this is going on is a private one where my software development team is spec'ing a fairly large software application, so I can't share the pages with anyone at this time. In order to try to demonstrate the problem further, I created The Deleted Republic on this site. I don't seem to have rights to delete that page, though, so I can't complete the bug test.

To complete it, someone with adequate rights would have to delete The Deleted Republic, check to see that it has in fact been removed from the country list, then check Wanted Pages to see if the article appears. If it does, then I'd say the bug is verified.

At this point, this is not a critical bug as my team is pretty careful about checking our Wanted Pages list to make sure we're not referring to lots of specs that don't exist, but I'm thinking about incorporating this extension into another wiki site where it could be much more problematic.

--Aaron Overton 20:26, 25 August 2007 (CEST)

Answer

Hello Aaron, I tried to follow the procedure outlined above. After deleting "The Deleted Republic" it still shows on the WantedPages -- but because this very article refers to it ;-)). I suggest that you try in your wiki the following:

• delete an article which is part of a DPL result
• execute runJobs.php (in the maintenance directory) OR wait for an hour OR open the article containing the query and saving it without changes.
• Each of these steps should have the effect that the reference from the query page becomes deleted from the database. At least the last method works in my local wiki.

You could also add a final DPL statement with reset=all (see the manual for details!) to the article containing your query. Then the database will never contain backward links from the query page to the article page. In that case it should be enough to just delete the article.

Could you please check all of the above and report here briefly if it works as described? It would be nice if you could add an entry to the FAQ article afterwards ... Gero 14:26, 26 August 2007 (CEST)

Reply

Well, heck. I went back and followed my own directions on my own wiki and wasn't getting the same results. I found myself wondering if it was the hour delay - I didn't wait an hour after adding the test page.

However, I did navigate to the deleted page and check its "What links here" link and the DPL query page did in fact show up on that list. So I don't appear to be crazy, at least in this one small regard.

I tried your suggestion of opening the DPL query page in edit mode and saving it again. That did clear whatever was cached connecting the deleted article to its categories, thus making the article still appear in some way linked to the DPL query page. I trust that your other methods would work similarly. So it appears not so much to be a DPL bug, but something I guess I could call a "quirk" based on the interaction between MediaWiki and DPL. That makes it pretty darn minor, but I will go ahead and add something to your FAQ page. --Aaron Overton 20:54, 2 September 2007 (CEST)

Creating an annual calendar

When I try to creat an anual calendar with the commands of

{{CalendarSingle|year=2007|month=01|show_year=no|basepage=Events:}}
...
{{CalendarSingle|year=2007|month=12|show_year=no|basepage=Events:}}

I get an error - See DPL:Bug Reports/Annual calendar

Strange, it does work on this wiki. Doesnt work on mine, I can't even post the wikitext. [1]

-- 14:50, 26 August 2007 (CEST)

Maybe you should download the latest DPL version and check if your templates are the same as in this wiki, Gero 15:30, 26 August 2007 (CEST)

wfDynamicPageListSPloadMessages

DPL works fine on my wiki, but if I try to go to Special:Specialpages, I get the following:

Internal error

Invalid NULL return from broken hook wfDynamicPageListSPloadMessages

Backtrace:

#0 F:\edit\includes\MessageCache.php(677): wfRunHooks('LoadAllMessages')
#1 F:\edit\includes\SpecialSpecialpages.php(13): MessageCache::loadAllMessages()
#2 F:\edit\includes\SpecialPage.php(653): wfSpecialSpecialpages(NULL, Object(UnlistedSpecialPage))
#3 F:\edit\includes\SpecialPage.php(459): SpecialPage->execute(NULL)
#4 F:\edit\includes\Wiki.php(203): SpecialPage::executePath(Object(Title))
#5 F:\edit\includes\Wiki.php(45): MediaWiki->initializeSpecialCases(Object(Title), Object(OutputPage), Object(WebRequest))
#6 F:\edit\index.php(89): MediaWiki->initialize(Object(Title), Object(OutputPage), Object(User), Object(WebRequest))
#7 {main}

I know it's DPL throwing the error because it only happens when DPL is enabled, and it happens when DPL is enabled and the rest of my extensions are disabled.

I just downloaded the latest source for DPL today, and it didn't fix it. Any ideas? Jonathan Kovaciny 20:22, 27 August 2007 (CEST)

Reply

Please check the function which is hooked to 'LoadAllMessages' (wfDynamicPageListSPloadMessages()) and add "return true;" at the end. This may help. You could also comment out the line where wfDynamicPageListSPloadMessages is registered (in file DynamicPageListSP). You could also comment out the line in DynamicPageList2.php with the "require_once" statement for the special page. Anyway, the next version of DPL will no longer have a Special Page as the DPL GUI is a better alternative. So don´t bother with the special page. Gero 07:48, 28 August 2007 (CEST)

That template can't handle multiple namespaces, categories, or even articles (as I mentioned to you almost a month ago); it's not ready to replace the special page. -Eep² 09:23, 28 August 2007 (CEST)

I commented out line 19 ($wgHooks['LoadAllMessages'][] = 'wfDynamicPageListSPloadMessages';) and it seems to work now. But what does this line do? -- Jonathan Kovaciny 16:15, 28 August 2007 (CEST)

%PAGES% not working

{{#dpl:namespace=Template
|mode=category
|ordermethod=titlewithoutnamespace
|shownamespace=no
|rowcolformat=width=100%
|resultsheader=<h2>Templates (%PAGES%)</h2>
}}

Just shows "Templates (0)" instead of actual # of articles/pages (templates) found... Also, the column heights are not all equal except for the rightmost one, as stated in a recent update release notes. -Eep² 23:17, 29 August 2007 (CEST)

Indeed there is a bug in %PAGES% when used together with mode=category. Will be fixed in the next release. Gero 09:17, 30 August 2007 (CEST)

Transcluded parameter truncated

Transcluding a single template parameter sometimes does not get the full parameter. Example: See the Nigunda Test entry at Test section inclusion#include a single template parameter. The retrieved value is terminated prematurely (right before the pipe). I believe the scope of the bug is just when a pipe is used within square brackets in a parameter. --Rezyk 12:03, 31 August 2007 (CEST)

Answer

Thank you for reporting. There is a bug in the parser (it simply ignores hyperlinks and gets fooled by pipe characters inside hyperlinks). Has been corrected. Gero 13:37, 31 August 2007 (CEST)

reset=categories doesn't always work with parser function usage

Example: See Test reset categories, which includes part of Sudan (through a parser extension DPL call) and Test matches (through a parser function DPL call). Without the reset=categories call, it would inherit all the categories from both articles. With reset=categories, the categories from Sudan are suppressed, but Category:Test (which comes from Test matches) is not suppressed. --Rezyk 12:33, 31 August 2007 (CEST)

Answer

I had to do a lot of investigations regarding the "reset" parameter. And unfortunately it still doesn´t work always as expected. Are you a programmer? I could well need some help at that matter ... Gero 13:41, 31 August 2007 (CEST)

Well, I am no expert, but here are my thoughts after looking around in DPL 1.3.8 and MediaWiki 1.9.3:

Starting from the top level page parsing... (function stack at Parser::parse)

1. First all <dpl> calls are each processed.

   (Parser::parse => Parser::strip => DynamicPageList2)

   1. Each call also processes its category tags into mCategories before returning.

      (DynamicPageList2 => Parser::recursiveTagParse => Parser::internalParse => Parser::replaceInternalLinks)

   2. Each "<dpl>reset=categories</dpl>" empties any mCategories categorization done.
2. Then all {{#dpl:}} calls are each processed.

   (Parser::parse => Parser::internalParse => Parser::replaceVariables => Parser::braceSubstitution => wfDynamicPageList4)

   1. Each call does not categorize into mCategories before returning. Any category tags are returned as part of unprocessed text.
   2. Each "{{#dpl:reset=categories}}" empties any mCategories categorization done.
3. Then the top level result text as a whole processes its category tags into mCategories.

   (Parser::parse => Parser::internalParse => Parser::replaceInternalLinks)

The error case is step 2.1 spitting out a category tag that dodges 2.2's mechanism (because it is unprocessed text, not in mCategories) and is processed into mCategories in step 3. One way to address this might be to have 2.1 do categorization processing like 1.1 does (have wfDynamicPageList4 apply recursiveTagParse to its result like DynamicPageList2 does). Any "<dpl>reset=categories</dpl>" would still not work against {{#dpl:}} effects, but subsequent "{{#dpl:reset=categories}}" would. Note: if that does work, I wonder if wfDynamicPageList4 should also return with noparse=true (see description of Parser::setFunctionHook).

A "more clean and thorough" design might be to apply that fix, and also have DynamicPageList2 and wfDynamicPageList4 each record/copy the state of mCategories before calling DynamicPageList and restoring that state (if say, categorize=false) after calling recursiveTagParse. --Rezyk 07:58, 1 September 2007 (CEST)

Reply 2

Thank you for clarifying this. It was a conscious design decision NOT TO call recursiveTagParse at the end of a DPL parser function call as this gives much more freedom to the user. For example today you can define a table outside a DPL call and then invoke DPL just to produce some rows for that table (the table may contain other rows coming from other DPL statements or rows which you wrote manually). If I called recursiveTagParse this would no longer be possible because the parser would not understand a pipe charater at the beginning of a line as a markup for a table row (because it wouldn´t know that it is inside a table when expanding DPL output).

Do you see a chance to get rid of unwanted category assignments without calling the parser?

Gero 11:21, 2 September 2007 (CEST)