Difference between revisions of "DPL:Requests for new features"

Revision as of 00:34, 19 September 2007

Please add requests for new features at the bottom of this document. If possible make syntax suggestions and give an example for the desired behaviour!

Old requests (which have been resolved) can be found in the DPL:Requests for new features Archive.

Include other wiki pages

I want to include parts of Wikipedia articles on my wiki. Can DPL be expanded to do this? -Eep² 10:22, 20 August 2007 (CEST)

I don´t think so. Every wiki has its own categories, templates, images,.... So just transcluding the raw text (if it is available via &action=view) would not make much sense. And transclusion of rendered html text is not possible nor desirable either. Gero 14:28, 20 August 2007 (CEST)

And yet many websites (like http://encyclopedia.thefreedictionary.com/) do it all the time without any apparent problems (and there's even a WordPress plugin)... All I really want to pull in is the first paragraph; I don't need templates, categories, or even images. Links can obviously be pulled in easily enough that go to the correct place (Wikipedia or external links). See http://www.killertux.com/pages/Wikipedia_Simple_API.php?q=node/44 too for a "screen scraper" with PHP code you may be able to implement in DPL. -Eep² 15:19, 20 August 2007 (CEST)

Using the killertux API you can yourself include a whole wikipedia article into your wiki (as html or text). I can´t see what DPL should do in that context. DPL cannot and will not parse such scraped contents. You would have to build a completely separate and different mediawiki extension for that purpose. Gero 20:17, 22 August 2007 (CEST)

Most active page?

ordermethod=activity

Most number of edits or biggest diffs in the last t units of time???

--Dmb 18:11, 10 August 2007 (CEST)

The sheer number of edits is not very meaningful; and as soon as 'significance of change' comes into play, I see no way to implement such a feature without having to calling diff3 on every document. And that is definitely too resource consuming. Gero 14:55, 15 August 2007 (CEST)

Add 'contributors'?

addcontributors = TRUE contribthresh = x Kb

Instead of listing one page author or the last editor, addcontributor would add the users who had made significant diffs to the article, where significant is determined by contribthresh. The multiple names are listed separated by commas.

Woop!

--Dmb 18:11, 10 August 2007 (CEST)

That´s a pretty good idea. Maybe I will add that somewhen. Gero 23:56, 10 August 2007 (CEST)

I also thought of another idea... List users by total contrib size. Its a bit 'lets see who has the biggest penis' - but could be useful to see who has contributed most to a certain page or category. --Dmb 08:21, 14 August 2007 (CEST)

After some investigation I feel that it would be very slow and resource consuming to build that feature. If somebody can come up with a SQL statement which delivers the basic data we want to show: fine (I don´t know how to do it with pure SQL). Otherwise one would have to call diff3 for each document. That´s a show stopper. Gero 14:52, 15 August 2007 (CEST)

Hello Gero, and sorry for taking so long to reply. Here is the SQL that I have come up with. I think that it does the job (more or less).

SELECT
  rc_title, rc_cur_id, rc_user_text, rc_user,
  GROUP_CONCAT(rc_new_len - rc_old_len) AS DEBUG,
  SUM(ABS(rc_new_len - rc_old_len)) AS CONTRIB
FROM
 db_prefix_categorylinks  cl
INNER JOIN
  db_prefix_recentchanges rc
ON
  cl.cl_from = rc.rc_cur_id
WHERE 
  cl_to='Some_category'
GROUP BY
  rc_cur_id, rc_user
;

Using the above we get to see which user has done the most 'editing' of a page in the given category. The notion of 'editing' implemented above is quite crude, but I can't think of any better systematic way to do it (SQL or otherwise). The contributors option would take a threshold parameter to delineate the valid list of 'significant contributors' - that parameter could even be a fraction of the page size! Anyway, lemmy know if this is what you were looking for, and if not why not.

Thanks for the brilliant extension!

P.S. I wonder if we could apply a modified version of the above to look at the 'most active pages' request above?

--Dmb 13:53, 14 September 2007 (CEST)

Table row/column header switch

Can the table headers be used as the beginning of rows instead of at the top of columns? I would like to duplicate my game comparison table and need this functionality. -Eep² 05:43, 29 July 2007 (CEST)

Please give more details: How should the new switch be named, which values be allowed? In which modes should it have an effect and how should the result be affected?

For information: There will be no changes to the DPL sources within the next three weeks. Gero 08:13, 29 July 2007 (CEST)

I'm not a programmer, Gero...I just have ideas and what I want to do programmatically that I can already do (and have done for years) manually. Perhaps creating a "table" mode that deals with all table-related parameters like header (and column/row types). resultsfooter could have an option to be the last row or column of the table and include parameters for totals of a specific header (# articles in table, etc), a number field (like a "sum" function), etc. cellseparators could be used instead of listseparators (or at least as an alias) and. of course, support for specifying normal/regular non-suffixed template fields. Essentially, DPL needs more table-specific support to move it beyond just lists, per se. -Eep² 08:28, 29 July 2007 (CEST)

Still need this too... -Eep² 05:40, 11 September 2007 (CEST)

Template field output

Is it possible to output the unescaped wikimarkup (so it actually works as on pages that use the template) in DPL output? I want to create a DPL table that has same links as articles do that use the template in them which is also called in the DPL table. -Eep² 06:56, 26 July 2007 (CEST)

User-friendlines

DPL talk:Manual - DPL Special Page with Parameters#User-friendliness -Eep² 11:42, 25 July 2007 (CEST)

Be PostgreSQL compliant

Request

As of DPL 1.1.7, usage of DPL in a PostgreSQL-based MediaWiki requires further effort, which I describe in DPL:Manual - DPL with PostgreSQL.

I don't know if there is a common syntax between MySQL and PostgreSQL for the database functions - if not, my solution is easy to install.

But the need for a patch is really nasty. I think with my patch, DPL still works with MySQL as well. If so, could you kindly incorporate it.

I'd be curious if you consider this a feature request or a bug report…

rss feed from dpl

Request

A DPL might also have an according RSS feed. For example, a calendar might give a feed with the upcoming events from now on. --Eiland 09:30, 16 April 2007 (CEST).

Response

I haven´t worked with RSS generation so far. Is there a php library or a mediwiki module for that purpose? --Gero 22:08, 23 April 2007 (CEST)

Plenty of MediaWiki Extensions for RSS... should be easy to integrate with DPL :) --141.14.26.126 13:16, 29 April 2007 (CEST)

Which one would you suggest? Can you do the integration? Gero 20:12, 2 May 2007 (CEST)

Request

I have a similar request... Make each DPL into an RSS feed! --Dmb 11:20, 1 June 2007 (CEST)

Wait... that was me talking ... I just recognized my IP... (oh my memory!)

Well... you could start by looking here...

That should certainly help with the details. Unfortunately I cannot do the integration myself or I would happily do it immediately. Thanks for the brilliant product and keep up the good work! --Dmb 11:24, 1 June 2007 (CEST)

nudge

Rss rss rss rss rss rss!!!

display Table of Contents for an article

Request

the incudepage feature could be enhanced to include the TOC only; a %TOC% variable would ebe useful ...

Putting delimiters between results

Will this solve a related formatting problem - putting delimiters only between results? Ideally I'd like to have a single result returned inline, but multiple results in an ordered list. It could be I misunderstood the documentation, but there doesn't seem to be a way to avoid a leading bullet or whatever in a list. Frank 14:35, 20 August 2007 (EDT)

There is a mode called 'inline' which does what you want. You can define the 'inline' tag contents. Gero 07:50, 10 September 2007 (CEST)

Nig1 my separator Nig2 my separator Nig3 my separator Nig4 my separator Category:CountryA my separator Category:CountryB

Hook based data exchange between extensions

Would it be possible to add a 'hook' (i.e. wfRunHooks) to DPL? Once a 'query' is finished executing, the result could be signaled to other interested extensions. A 'context id' would be required as potentially many queries could co-exist on the same page. I would suggest adding a parameter such as 'context=' OR just a linear incremental counter.

A 'no output' option would be great also - this way, if the query is really meant to be consumed by another extension, the user isn't distracted by the result from DPL directly. mw:user:jldupont

Reply

I do not have experience with creating hooks. There is a point in the code where the sql result set is ready. But be warned: The columns contained in the result set may vary depending on the options used. Generally speaking, DPL is a beast that has reached its saturation level of complexity ;-). I would more be in favour of a way where DPL produces some kind of csv output which is then fed into another extension. With mode=userformat this is fairly easy because you have complete control over the output. You can create csv or whatever format suits your own extension. This need not be wikitext nor need it be html or plain text - any kind of grammar is possible. For example you can use the result of one DPL statement as a parameter for another one, i.e. you can nest DPL calls. There is a good example for this: Wgraph:Example 4. Here the inner DPL query produces a pipe-separated list for the outer one.

So, the 'no output' you are looking for is already there. It´s called mode=userformat -- and it will take you some time to understand its power. Being the author I am still myself learning what you can do with DPL ;-)

The problem of multiple contexts is also solved by extension nesting. Maybe you do a little exeprimenting and then come up with another comment?

Gero 21:05, 24 July 2007 (CEST)

DPL API

I'd like to see more of an API structure to the code. The manual lists all the parameters and groups them by functionality, but no such break-up exists in the code (at least not that I could tell). At minimum, I'd like there be one function that processes the search criteria to get the results or groups of results in the form of an array of Title objects (or an array of arrays of title objects), and another function to display the results in a specified or default format.

I'd like to be able to build my own extension that uses the DPL2 extension as an API without having to hack the DPL2 code. —Sledged (talk) 01:03, 10 September 2007 (CEST)

Reply

Why don´t you just go ahead with DPL as it is? You can put any call of a parser function into the output loop of DPL. And you can use DPL in a way that it does not produce any single byte of output on its own. You can easily create title objects within your code from the first parameter which is passed to my working template. You might say that this is less efficient than an integration on php level but before trying to optimize you could build your extension right now without any change to DPL and without any code interference. What kind of application do you have in mind, by the way?. For example:

{{#dpl:
  |resultsheader=²{my envelope template¦%PAGES%}²
  |category=some category
  |namespace=some namespace
  |... etc
  |format=,²{my working template¦%PAGE%¦%TITLE%}²
}}

--Gero 07:28, 10 September 2007 (CEST)

I've been toying around with DPL a bit with some of the examples on this site, and I see now that it can do what I want it to do. Excellent! I'm trying to be able to take user-supplied information from a page. In fact, the table on the main page with the headers "Country", "Area", "Population", "Text", and "#hits" is a perfect example of what I want to do. (The answer was in front of me all along.)

I still would definitely like to see an API layout to the code, even more so now. There are some really nice nuggets of functionality that would be useful as a suite of API tools and/or could be made into extensions in their own right, and if the code were in such a format, it'd be easier to pull out those bits of interest.

In fact, I'd like to see the mechanic in the aforementioned example in a form I can use outside of DPL. Also, I'd like to get my hands on that bit of code that utilizes the character escapes to prevent templates, magic words, tags, and other parser functions from being parsed before they're ready to be. —Sledged (talk) 00:25, 15 September 2007 (CEST)

`redirects` include pages that link to redirects

See DPL:Discussion#Redirects to include pages that link to them? -Eep² 05:07, 13 August 2007 (CEST)

`linksto` and other parameter case-insensitivity option

I need this without having to manually specify lower-/upper-case versions of every page... -Eep² 13:29, 2 September 2007 (CEST)

Mediawiki is case-sensitive by nature. So I can´t see what this should be good for ... Abc is the same as abc but is different from aBc and abC. DPL works on internal page_id numbers and these only exist for existing articles. Gero 14:31, 2 September 2007 (CEST)

Why must you fight me at every point in getting new features in DPL to make it easier to use, Gero? Geez. "Abc" is not the same as "abc" if $wgCapitalLinks = false; is set in localsettings.php, as I have it set in my wiki. I use DPL to list redirects but it requires a lot of variations on the page and support for multiple manually-entered parameters:

	 
|linksto={{FULLPAGENAME}}{{!}}{{FULLPAGENAME}}s{{!}}{{FULLPAGENAME}}es{{!}}{{FULLPAGENAME}}ies{{!}}{{FULLPAGENAME}}ing{{!}}{{FULLPAGENAME}}ed{{#if:{{{2}}}|{{!}}{{{2}}}{{!}}{{{2}}}s|}}

This query doesn't have any problem if any of these pagename variations don't exist so why would linksto have a problem with pagename case variations either??

Is this like how you couldn't see what "on"/"off" and "1"/"0" for boolean operators is good for? Or why someone would want to create table columns vs. rows (as I want for each game in my comparison table)? It's like the redirect issue you have been resisting and how MediaWiki devs resist adding suffix index (Special:Prefixindex in reverse) despite DPL being able to do it easily enough using a simple wildcard titlematch query (see http://www.tnlc.com/wiki/index.php?title=fire for an example). Enhancements like these make MediaWiki (and DPL) easier (and less frustrating) to use... -Eep² 15:38, 2 September 2007 (CEST)

I really need this functionality, since trying to create case variations for all of the above redirect variations (PLUS creating the actual redirects!) is a tad big annoying... -Eep² 05:40, 11 September 2007 (CEST)

DPL doesn't respect $wgNonincludableNamespaces

I'm using the Lockdown extension to restrict read access to a certain namespace to one group of users only. Part of restricting read access is preventing page inclusion by namespace. DPL allows one to bypass this.

As a suggestion, if you're able to fix this, could you make it so that with DPL it'd be possible to include / transclude pages within a nonincludable namespace, but not across namespaces? E.g. if I set NS_PROJECT to be non-includable, it'd still be possible to include NS_PROJECT content on NS_PROJECT pages, but not on main namespace etc. pages.

Thanks. 212.149.229.126 15:48, 11 September 2007 (CEST)

Do you think that DPL is wide-spread enough so that it is worth the effort? Is Mediawiki as a whole going to offer consistent support for such protection mechanisms and more elaborated access rights? --Gero 22:07, 11 September 2007 (CEST)

I have no idea how much effort would it take :) DPL's been actively developed for some time, so I thought I'd ask. I do realize Mediawiki isn't supposed to be a proper CMS with proper read access rules and so forth, so the private information wouldn't be that sensitive. In any case, it seems a bit too easy if it's accessible simply by using DPL. At the moment, there's no reason why I absolutely must use DPL, nor is there a reason why I absolutely must have read protected wiki pages. If the feature's very difficult to add, I'll just figure out which of the two, using DPL or having read restricticted wiki pages, save me more time. Thanks. 212.149.229.126 22:58, 11 September 2007 (CEST)

Integrating templates

Hi Gero! By this time, if we want to collect data in many articles using a template, like Example 1, we have to use the descriptions like followed:

includepage={Country} dpl,#History,#Religion[20],revolution

Could it be possible we could use them like followed:

includepage={Country} __,name,capital,dial__,#History,#Religion[20],revolution

or

includepage={Country} {{{,name,capital,dial}}},#History,#Religion[20],revolution

Then we would use Catlist to collect data. Because I am trying to develop the GUI of Catlist. Please see template:Catlist/test. I've added some elements like offset, include, table class and Title of column in it. But I still want to integreat all the templates in the one. The change which I ask for is come from new command table.

By the way, I am afraid that template:Catlist/test use Get instead of Post. Could it be possible it would be disabled by passing too many data? Thank you! --Roc michael 04:32, 16 September 2007 (CEST)

Gero, sorry! I'v seen the Eep²'s case like followed:

|includepage={game}:year,{game}:genre,{game}:publisher,{game}:developer,{game}:engine,{game}:character

It also seems to be great!

--Roc michael 13:39, 16 September 2007 (CEST)

Not really. As I've mentioned to Gero before (though I can't find where it's documented), it would be better if it could be declared like |includepage={game}:year,genre,publisher,developer,engine,character (or perhaps with colons vs. commas) without having to duplicate {game} for every parameter. -Eep² 15:10, 16 September 2007 (CEST)

I have a tendency towards the following syntax:

|include={myTemplate}:parm1:parm2:parm3

it could behave like the parameter list in the 'table' statement. It would deliver each parameter as acolumn of a row. What do you think? Gero 17:30, 16 September 2007 (CEST)

Sounds good. Would there be a way to optionally deliver each parameter as a row of a column too? I still want to have the option of column entries vs. row entries for my game comparison table (so it doesn't become unnecessarily wide due to the amount of parameters--I'd rather have longer vertical scrolling)... -Eep² 07:32, 17 September 2007 (CEST)

You have %USER% and adduser=true, what about %AUTHOR% to go with addauthor and %EDITOR% to go with addlasteditor ?

I realize that if addauthor = true, then %USER% is set to the author, but I want to create a table of data per page that includes both the most recent editor and the page author (first editor). For this we need the %AUTHOR% 'magic workd'.

Man ... so many things about DPL are confusing! I think the adduser option (first/last editor depending on ordermehtod) should be clarified wrt. addauthor and addlasteditor. The description of adduser actually talks about dates!

-D --Dmb 01:49, 17 September 2007 (CEST)

Specific enhancements for 'table from template' DPL

I think a very commonly needed and natural use of the DPL is the 'table from template' DPL. I would like to suggest the following syntax to make it easier to generate such DPL output...

...
incude = {Some template}:parameterOne
incude = {Some template}:parameterTwo
incude = {Some template}:parameterThree
tablehead =  Title,            One,            Two,            Three
tablebody = %TITLE%, %parameterOne%, %parameterTwo%, %parameterThree%
...

The above would generate a table of data for the named parameters passed to 'Template:Some template' in the included pages. I really really love the functions provided by DPL, I just find them hard to master! --Dmb 18:53, 18 September 2007 (CEST)

Reply

That´s almost exactly what will be in the next version! But The syntax will look like this:

...
include = {Some template}:parameterOne:parameterTwo:parameterThree
table   = ,, One, Two, Three

Creating pseudo variables for each column would add new complexity which I try to avoid.

Gero 20:13, 18 September 2007 (CEST)

I understand why keeping complexity to a minimum is important, but the above solution (clean though it is) is very rigid compared to the flexibility afforded by the use of pseudo variables. Imagine the following, parameterOne is information about the category of the page that I would like to wrap [[:Category:%p1%]], parameterTwo is an logo pointer that I would like to wrap [[Image:%p2%|200px]] and parameterThree is a website link that I would like to wrap [%p3% homepage]. None of this funn stuff is available via the above syntax (unless I am wrong). I can think of tons of examples where you just want the parameter, just like %TITLE% (or even %AUTHOR% or %EDITOR%). I am really enjoying watching DPL develope, and I realise that it is very easy for me to make suggestions without any clue regarding the underlying complexity, so sorry for sounding critical. The above is just an idea about what could be nice. All the best. --Dmb 01:34, 19 September 2007 (CEST)

@@ Line 275: / Line 275: @@
 Creating pseudo variables for each column would add new complexity which I try to avoid.
 :[[User:Gero|Gero]] 20:13, 18 September 2007 (CEST)
+:: I understand why keeping complexity to a minimum is important, but the above solution (clean though it is) is very rigid compared to the flexibility afforded by the use of pseudo variables. Imagine the following, parameterOne is information about the category of the page that I would like to wrap <nowiki>[[:Category:%p1%]]</nowiki>, parameterTwo is an logo pointer that I would like to wrap <nowiki>[[Image:%p2%|200px]]</nowiki> and parameterThree is a website link that I would like to wrap <nowiki>[%p3% homepage]</nowiki>. None of this funn stuff is available via the above syntax (unless I am wrong). I can think of tons of examples where you just want the parameter, just like %TITLE% (or even %AUTHOR% or %EDITOR%). I am really enjoying watching DPL develope, and I realise that it is very easy for me to make suggestions without any clue regarding the underlying complexity, so sorry for sounding critical. The above is just an idea about what could be nice. All the best. --[[User:Dmb|Dmb]] 01:34, 19 September 2007 (CEST)

Difference between revisions of "DPL:Requests for new features"

Revision as of 00:34, 19 September 2007

Contents

Include other wiki pages

Most active page?

Add 'contributors'?

Table row/column header switch

Template field output

User-friendlines

Be PostgreSQL compliant

Request

rss feed from dpl

Request

Response

Request

nudge

display Table of Contents for an article

Request

Putting delimiters between results

Hook based data exchange between extensions

Reply

DPL API

Reply

redirects include pages that link to redirects

linksto and other parameter case-insensitivity option

DPL doesn't respect $wgNonincludableNamespaces

Integrating templates

You have %USER% and adduser=true, what about %AUTHOR% to go with addauthor and %EDITOR% to go with addlasteditor ?

Specific enhancements for 'table from template' DPL

Reply

Navigation menu

Search

`redirects` include pages that link to redirects

`linksto` and other parameter case-insensitivity option