Discussion archive page for the PageQuery plugin

Could you please give an working example for your plugin. I'm not sure about limiting search to namespaces. Are relative paths allowed? {{pagequery>.}}
Is it possible to sort by ID and group it by abc, e.g. A ..(all pages with heading starting with a)… B etc. (similar to indexmenu)

If you need to do anything clever you'll need to use the fulltext option. After that the syntax follows the normal DokuWiki search syntax. The default PageID search is more limited (but I'm planning to improve it, for now it's based on an existing DokuWiki core function). So to answer your initial question: relative paths are not (yet) accepted… but I do agree that it makes sense to allow them.
I've added some examples above to show how pagequery could be used.
Hope this makes things a little clearer. Like I said the plugin will grow and improve with time and input from others.

Symon Bent 2010-04-21 10:40

Update: Namespaces are now supported in page name mode too; see above

Symon Bent 2010-04-23 09:00

Would is be possible to have the list bulleted, without the text being justified? I'm using columns and the longer entries that wrap around the column don't look as nice. It would be good to clearly see which entries are wrapping around and I think bullets are probably the simplest solution. Also, in my opinion, having the entries that wrap around the column stretch out to justified text makes the text look a bit “off”.

I'll look into this. The list is bulleted already, it is just that the bullet symbols are turned off to keep the display as simple as possible. However the justified text is caused by the built-in CSS. I'll try to override it in the plugins CSS… watch this space.

Symon Bent 2010-04-28 08:20

Done! I removed the text justify (yes, I agree it did not look too good!), and instead of bullets a multi-line link now has a hanging indent, i.e. the second line is indented slightly. I like it, hope you will. If you really, really want bullets I might consider adding it as “another” option… but be warned I do try to err on the side of simplicity.

Symon Bent 2010-04-28 16:35

This is actually the perfect solution. I wanted the indentation and the removal of the justified text, but I agree that the bullets make the lists look messy. I just thought that putting them in would be the simplest way to implement it, but having it this way is definitely the best solution.

Wonderful plugin!
Would it be possible to enable/disable/localize “(cont…)” in multicolumn layout?

Aivars Miška 2010-04-28

Your wish was my command: I already removed it in the upcoming version — it now always starts a new column at a group header only, this alleviates the need for “(cont…)” Symon Bent 2010-04-28 16:35

I want to use this pagequery plugin to list all pages of a namespace,but when I add a new page in this namespace,it doesn't show,and I can see the page in the index view, could you please show me how to do it?

The plugin does not turn off the default DokuWiki page caching mechanism (I could make it the default, but not everyone wants that…), so you'll need to put:

~~NOCACHE~~

somewhere on your page (i.e. the page containing the pagequery markup.) Symon Bent 2010-04-29

Note: This also fixes a problem I was having when I tried to access my index page using a parked domain (i.e. same dokuWiki just a different domain) it was coming up that there were no pages found. Symon, you might want to check if this is plug-in related (does it rely on the domain when it builds the pages?). P.s. Great plug in, thanks! DumKopf 2010-05-07

Forgive my ignorance, I don't fully understand the problem… I use my wiki on a localhost only! However, internally the plugin uses the built-in “ft_pageSearch” and a (heavily) customised “ft_pageLookup” function from “inc/fulltext.php” to grab the matching wiki pages and the the “html_wikilink” function to display them. So I don't really know where the problem would lie. Symon Bent 2010.05.07

In my wiki I have a namespace called “directory” and then sub-namespaces for each letter of the alphabet. When I query the “directory” namespace and use group headers, the headers look like this “directory:a”, “directory:b”, and so on. I just want the sub-namespaces (the letters) listed without the namespace that I am querying (“directory”). I'm using this query:

{{pagequery>@directory;sort=ns,name;group;border;cols=4}}

Is it possible to just list the sub-namespaces? Also, is there a way to have the group headers in proper case or capitalized, but not the items in the list? I would like the headers to be capitalized but I would like to keep the original format of my page names. Thanks.

Well, sounds to me like you need the IndexMenu plugin, it is much more suited for listing namespaces, which as I understand, is your goal. Pagequery is focused much more on listing pages… yes, all is possible, but the options are beginning to pile up quickly. How would you imagine that the syntax would work, i.e. defining which bit of the directory name you would like to display?

Certainly no disrespect intended, but this sounds like a very particular use case. I wrote pagequery with the lofty goal of escaping the namespace madness — I dump my pages into a namespace for each month, and then use pagequery to display them in a nice, structured way. Looks like you went down a different path! I will think more about your request and if I can come up with a sensible way of providing the feature I'll try to add it… but no promises.

Still, if all the files in directory:a begin with 'a' and directory:b with 'b', and so forth, then you could just use a more simple:

{{pagequery>@directory;sort=a,name;group;cols=4}}

You should get the same result… Symon Bent 2010-04-29

I think that I didn't express my question clearly. Sorry. My original text makes it seem like I want to list the namespaces, but not the pages. I didn't mean that. I am using this plugin to list pages. I am only referring to the format of the group headers. When I query the namespace “directory” (which has sub-namespaces of “a”, “b”, etc.), the group headers read “directory:a”, “directory:b”, and so on. The only change that I would like is for those group headers to simply read “A”, “B”, and so on. Since I am only querying the namespace “directory” I don't need all of the group headers to include the “directory:” text. I hope this makes sense.

It does, I think I understood you fine the first time, which is why I thought that the IndexMenu plugin would be better for your needs… However I've been doing some thinking and here's a few ideas:

• I could add an argument to the proper option, e.g. proper=hdr or proper=name or proper=both [default]; that should solve your first request about the group header vs. page name formatting

UPDATE: this feature has been added to version 0.5beta. Symon Bent 2010-05-04

Thanks for this option. Just a note… now when I use this option, headers that used to read “directory:a” now read ““Directory : A” with extra spaces on either side of the colon. It's not really a problem, but I wonder if it is intentional on your part.

I thought that I had fixed that, sorry! It'll be rectified in the next release.

• Which “part” of the group header to display is a little more tricky: my first thought was group=0,1or group=-1,1; where the first arg ⇒ start character, second arg ⇒ no. of characters (as per PHP substr function). So the second example would start from the end (”-1“) of the group name and display just “1” character (i.e. the a, b, c, etc… in your case)
• My next thought is what about displaying just one element of the namespace, how would that work? Any thoughts? group=-1,1,ns?? group=-1,1,: (i.e. split header using ':' character, and return the last element) or just group=ns,-1. But what happens when we have sub-group headers?… Maybe this should be added as a sort option: sort=ns(-1) (last namespace element), sort=ns(1) (first element), etc…

Hi, I really like your plugin an so far it delivers a lot of functional listing results for my aims. But one function I really miss. Is it possible to filter out special words out of the listing results. In my case, I have a lot of namespaces, and every one contains as a startpage the page called “hauptseite” like the standard “start”-page in DokuWiki.

It now will list an a page all the pages which start with an “a” (“namespace:a*”), the listing output is a list with the a-sides and a list with h-sides wich contains all the “hauptseite”-pages. so I'm looking for a way do a pagequery for all the a-pages and nothing else

I hope I described my problem well, thanks if u could help!

I think that I understand your problem, you could try this:

{{pagequery>@namespace a.*}}

This will take pages from the “namespace” namespace only, and then fetch pages beginning with 'a' only (a.* is a regex for 'a' followed by any other character(s))
Is this what you were looking for?

Hi again, yes, that's what I'm looking for (or a way to get the result I want), but sorry the way you describe it doesn't work. :( I still get a list with the a pages and after the “hauptseite”-pages. is it in your way for the plugin to implement a function for filtering some keywords? or is this an problem of the core DokuWiki search?

Don't put too many time in this problem. I'm using the plugin at the moment with this little handicap.

many thanks for the quick answer, bye the way

I think I need to understand your wiki namespaces better before I can find a solution to you query. Could you email me a screenshot if possible? Symon Bent 2010-05-03 09:45

UPDATE: Check the latest version 0.5beta, these issues should now be fixed! Symon Bent 2010-05-04

Hi, I just updated to to newest 0.5 version and my lists seem to look more like the 0.3 version: the ”(cont…)“ messages are there, the text is justified, and the long names no longer have the extra space in the second line that was added to 0.4 version. Also, I tried the nostart and proper=header options - nostart didn't seem to do anything and proper=header made everything in proper case (not just the headers) and added to extra spaces to my headers.

Probably because I mistakenly uploaded version 0.3beta again (sheepish grins all round)… My apologies! I've fixed the download!

I'm having some difficulty with the new abstract function. In the previous version, I used to get the automatic tooltips, but now, using the abstract=tooltip I don't get any tooltips. And using an (for example) abstract=10 option just puts a blank quote box under all of my entries (not just the first 10). Although, when I do that (the abstract=10) the first 10 entires will now have a much shorter version of a tooltip - basically just the directory listing.

Sorry, it was working fine on my own wiki. I'll check it out. I have noticed that some plugins do cause problems with the 'abstract' meta-data, for example 'yalist'… could it be a plugin issue? (But then you said that it used to work fine as a tooltip… so now I'm not sure) I'll upload the latest version once I've looked things over. Update: yes, there is something quirky going on, I'll fix it! Symon Bent 2010-05-15

Fixed!: please download version 0.6beta2 Symon Bent 2010-05-15

The plugin is great. But is it right, that the abstract box information are unformated and only show the wiki-code?

Yes, I'm afraid it is, it is based on the existing “abstract” feature built into Dokuwiki, and that is the current output. I'll look into improving it, but it requires more work than I have time for right now. Symon Bent 2010-07-05

Hi, thanks for this wonderful plugin. But It seems that utf-8 encoded namespaces is not supported. –lainme 2010-05-16

Yes, the perils of speaking English, I should know better! I'll see what I can do about that! Could you send me a screenshot (to my e-mail address)? Symon Bent 2010-05-16

Hi, I am sorry that I didn't pay attention to this issue for a long time. Now I find the problem is gone with the latest version of dokuwiki!

Hi, first of all thank you for this great plugin. I'm using your plugin together with bureaucracy to offer users a form to create pages. The problem is, that a page is not shown by pagequery until someone has accessed the page. I can however see the newly created page when clicking on the index-button. I think the difference to a normal page creation vs bureaucracy is, that the page is not accessed upon page creation.

Do you have ~~NOCACHE~~ on the page? The pagequery plugin uses the same functions as the Index as far as I can remember, so it “should” be visible, but I will have to check to be sure. Symon Bent 2010-06-11

Hi Symon, sorry, I forgot to mention, that I'm using your plugin with a git checkout - guess you should have known that before. I've digged deeper and found out, that the newly created page doesn't show up in the data/index/page.idx file. And thats why pagequery's _pageLookup doesn't list it. Dokuwikis index-function however does list the page. When I'm calling ./bin/indexer.php the new page is added to the index and pagequery finds it too. But I don't know what the right way to fix it would be. Maybe this problem only exists in the devel version. Alex Ganster 2010-06-24

I Symon, maybe you're interested in this bit. I modified the function so that it doesn't rely on the pageindex to find the appropriate pages. This solves the problem for me, but actually it would be better if bureaucracy would add the page to the pageindex after creation.

private function _pageLookup($query, $pageonly) {
        global $conf;
        $query = trim($query);
#$pages = file($conf['indexdir'].'/page.idx');

        search($searchpages,$conf['datadir'],'search_allpages',array('skipacl' => false));
        $pages = array();
        foreach ($searchpages as &$searchpage) {
           array_push($pages, $searchpage[id] );
        }

        $pages = array_values(preg_grep('/'.$query.'/', $pages));
...

It's a solution to be sure, however it means recreating the page index every time, rather than using the cached page.idx. I really think the root problem lies with the bureaucracy plugin: does it inadvertently prevent page indexing on page save? I don't use it myself, I've made my own simple page creation plugin, and that works fine with pagequery. If I get some time I'll download bureaucracy and check through the source code and see what the problem could be. Thanks for sharing all the same! Symon Bent 2010-07-05

Hi Symon! I was on vacation for two weeks.. You're right! it's bureaucracy that doesn't add the page to the index. I made a bug report there.. it's only a single line, that's missing. See: https://github.com/splitbrain/dokuwiki-plugin-bureaucracy/issues#issue/8 Thank you for you efforts! Alex 2010-07-20

Thanks Alex, good to see you found a proper solution!

I have the translation plugin (http://wiki.splitbrain.org/plugin:translation) installed and having trouble listing only one language. The pagequery lists both the 00basemodule:01something:12somethingelse and the en:00basemodule:01something:12somethingelse pages. Please advise how to list only one language.

Ok, to answer my question: I had trouble using regexs, because I missed out the fullregex keyword. Using the fullregex and the “^00basemodule” and “^en:00basemodule” regexs solved my problem.

Well, I'm glad to hear it! It never hurts to read the manual… Symon Bent 2010-07-05

Hi, thanks for this nice plugin. Is it possible to show the last created pages? Andreas

Yes, it is possible. I do this on my own wiki at home. For example, to show the last 10 created pages in the entire wiki the following options would work:

{{pagequery>*;sort=cdate;limit=10;title;nostart;proper;inwords}}

If you study the options table above you'll find others ways to adapt this example to your real needs. Hope this helps! Symon Bent 2010-Aug-24

Perfect, thanks a lot! :) Andreas

This plugin is great! I'm using it for kind of a special case. Basically, I want to list all of the pages in a common second-level namespace used throughout our wiki. For example we have HR:Policies as well as Medical:Policies. I wrote the following to display all of the pages in the secondary Policies namespaces, regardless of the primary namespace:

 {{pagequery>@*.:policies *;sort=ns,name;group;proper;cols=1;fullregex;}}
 

The only problem I am having is in the group headers. For the first one, for example, I see [H1] Medical [H2] Policies [Page Listing], then for the second one [H1]HR [Page Listing]. So, the “Policies” header is only showing up for the first primary namespace listed. I would prefer that it didn't show up in any of them (since I can just put at the top “Policies”), or that it showed up on all of them. I modified the code myself in a very “hacky” way to fix this problem by just looking for secondary namespaces called “policies” and ignoring them, but I didn't know if there was a way you could build in an option for this…could be something as simple as “ignoreheaders=policies” just to leave it out of the group headers, or perhaps a more complicated system that was smart enough to realize that given a namespace query where a wildcard is used, I want to ignore the groups of any non-wildcard parts…

Forgive my confusion, I'm still struggling to understand the exact problem, but my first suggestion would be to have 2 separate pagequery lists on the same page, e.g:

{{pagequery>@hr:policies *;sort=ns,name;group;proper;cols=1;}}
{{pagequery>@medical:policies *;sort=ns,name;group;proper;cols=1;}}

From what I have grasped so far, they are anyway unique topics. What you are asking for towards the end sound quite complicated…I would have to spend some time thinking about the concept! Basically you want to pull in pages from different namespaces and still group them by namespace. This is difficult as the two namespaces may not correspond at all (by name and depth), so how should the plugin decide which heading gets used? Currently, as you note, it is only designed to handle one main namespace. –Symon Bent 2010-Sep-05

Thanks for a great job! By the way, what about making two separate plugins instead of one? (Yes I imagine how it sounds like) Anyway displaying the list neatly grouped etc. is one field of responsibility and creating this list by querying it is another. So logically these two jobs must be done by different totally independent modules. What if I want e.g. only the pages tagged with specific tag (that's exactly my case)? Or I just want to create a long list by hand?

Thanks again. Nikolaus, 2010-10-24

Fundamentally I agree with you: it would be good to separate the query from the view. This concept is already used by other plugins (e.g. pagelist is used by other plugins for displaying lists). Do you already have a use-case, i.e. how would the plugin syntax work? Do you mean that the query “plugin” should return an unformatted list that can be used by the view “plugin”? Could you give me an example of how you imagine it working? Thanks! Symon Bent 2010-10-24

You're right I mean decoration plugin should be able to transform any unnumbered list. I'm not completely sure it's possible from the technical point of view, I'm new to this framework. But if it's possible to create a “composition” or “superpositions” of plugins it could work like following:

<decorate?param?param?param>
  {{someotherpluginreturningthelist}}
</decorate>

As for me personally I just need to filter the list by one or two tags. Another interesting task is to filter the page by data field (using data plugin).
Regards, Nikolaus, 2010-10-25

Looks like you're a Python programmer I don't know any way of “decorating” another plugin in Dokuwiki; however plugins can use another plugin's functionality internally, but I've never considered your idea of “piping” the output of one plugin into another via on-page syntax. Maybe I'll ask about this on the mailing list. Symon 2010-10-25

Hi, I ran into a problem when making this pagequery:

{{pagequery>@downloads:a3 *;sort=cyear,cmonth,cday;group;inwords;proper;cols=2;border}}

Now that rightly produces a list sorted by year, month (in words) and day (number, in words). However the day in words does not match the day on this specific date e.g. the 6th of Octobre 2010 was Wednesday but in the list it's “6, Sunday”. Same goes for any other heading. I haven't managed to find a pattern yet but I checked the mktime command in your code where the header is created and it actually seems to produce a false timestamp for me. Any suggestions would be appreciated. — yodahome 2010/11/02 14:55

Fair enough, I'll have a look and get back to you–could well be a bug! Yes, there is a serious flaw in my date creation logic… it'll get it fixed in the coming days I hope–my time is a bit short at the moment… sorry! Symon Bent 2010-11-02 21:05

Thanks, that would be very helpful. I would try to fix it myself but up to now I couldn't put my finger on the exact problem. — yodahome 2010/11/02 20:17

Sorry that it took so long (programming is not my day job!), but the solution was not simple, I had to completely re-think the way dates are displayed in words–my original approach was flawed. Still it's done, hope it serves your needs. 2010-11-13 Symon

Thank you, works like charm now. — yodahome 2010/11/14 02:28

We are using V0.6.5 and do a search without namespace, such as

{{pagequery>[Rr]elease[nN]otes.*;title;sort=name}}

The query actually returns a few hits, but the sort does not work. It returns

Warning: array_multisort() [function.array-multisort]: Array sizes are inconsistent in /dokuwiki/lib/plugins/pagequery/syntax.php on line 542

I tried other sort options, removed the title keyword, but none did resolve the issue. Any ideas what could be wrong? — Marcus 2011/01/10

Don't really know yet, but I'm looking into the problem and will get back to you as soon as I can find the cause!—Symon 2011-01-10
I just tried an almost identical query in my home installation and it works fine… so where to look next?
AMOF: All My Own Fault: I did fix a recent bug that was causing this problem—I'll upload a bugfixed version in a moment. My apologies for your frustration!—Symon 2011-01-10 20:14
Done! 2011-01-10 20:45

You are fast! Thanks a lot. I am eager to try it, but github currently does not allow me to download the zip (probably a github issue). On the pagequery page someone added a to the download link, too (which is not shown obviously). —Marcus 2011-01-11 09:13

Please don't attach to the formular in “downloadurl”. I added it under the formula. The download is broken, because the source repository is empty. Maybe you could contact the author by e-mail. — lupo49 2011/01/11 11:15

The download link is fixed. I have installed it and it is working great now including sorting —Marcus 2011-01-13 09:42

You're welcome—Symon 2011-01-13 11:55

Line 494 of syntax.php causes a syntax error under some circumstances (sort options) because function “mb_substr” is unknown. I removed the “mb_” and it worked. Is there a special reason to use mb_substr here? — Jochen 2011-01-13 10:50

I guess you do not have extension=php_mbstring.dll (or .so)” enabled in your php.ini file. I'll change this line to use the built-in Dokuwiki function “utf8_substr” instead in the next release. This function ensures that multi-byte encodings are correctly allowed for when choosing the first 1-3 letters of a word. (Think accented languages…)—Symon 2011-01-13 14:00

I think you're right with the missing extension, but I have a workaround anyway. Thank you! — Jochen 2011-01-13 14:04

How can I explicitly exclude certain pages from the pagequery list?

This question is a little vague, but if you are just searching by pagenames then you can exclude pages using a regular expression, otherwise there is no other way to do it. If you could be more specific about your needs maybe I could find a solution or even add the functionality you are looking for.–Symon 2011-01-25 09:03

I have the same doubt (I am the user below), you could create an example of exclusion of namespace with regular expressions?

After a little local testing I can see that I need to improve this feature—I did try to provide the same ^exclude and @include syntax as the normal Dokuwiki page search but it does not work consistently. I'll work on this in the coming weeks, and see what I can come up with!—Symon 2011-01-31 11:55
Update: I have the include/exclude feature working correctly now on my dev version at home; I'll release an update in the coming days. Syntax as per normal Dokuwiki search @namespace -or- ns:namespace for includes; ^namespace -or- -ns:namespace for excludes. Note: excludes take precedence, and only included namespaces are displayed.
0.6.7 Released on 2011-Feb-01

This also works perfectly! now this plugin is perfect for me! you are superman

It's always a pleasure to help! Glad that it serves your needs.—Symon 2011-02-03

something still goes wrong.
The pagequery>*;namespaces=^blog ^syslog;sort=ns,name:asc;cols=2;proper;border;title;natsort tag does not exclude blog and syslog namespaces.
What am I doing wrong? — jno 2011/06/28 12:46

There is no such parameter namespaces=… (sorry for any frustration!.) Pagequery “queries” were designed to work the same way as the standard Dokuwiki search box. The following change should help you:

{{pagequery>^blog ^syslog *;sort=ns,name:asc;cols=2;proper;border;title;natsort}}

You can also write it this way:

{{pagequery>-ns:blog -ns:syslog *;sort=ns,name:asc;cols=2;proper;border;title;natsort}}

if that is clearer to you.

See if this does want you want… Regards Symon 2011-06-28 17:24

Thanks a lot! This way it works. — jno 2011/06/30 16:20

Is possible to request a pagequery that goes not beyond a specified number of sub categories?
If I erase file in ./data/meta & ./data/attic nothing happens, if I erase file in ./data/page the pagequery is updated correctly but, if I edit or create new pages or namespace in ./data/pages they do not appear in the list! If you want to make them appear you should start to change from within the wiki (does not matter if you do not save changes).

Are these two different questions or are they related somehow?

1. What do you mean by sub-categories? Namespaces? If so, then it might be a little difficult to achieve as pagequery is not like indexmenu which is fully based around namespaces. PageQuery just searches for pages and sorts/groups them. If you could provide an example of what you want to create maybe I could help you.–Symon 2011-01-25
2. PageQuery will only recognise new pages if they are created or opened within Dokuwiki, that's when indexing takes place. This is not a bug, it is just the way Dokuwiki works.

1. Example: I have a tree with a branch of five nested namespaces (ns1>ns2>ns3>ns4>ns5). Now I include as an option for pagequery something like “subns=3” allowing the display of only the pages that come to the third namespace (ns3) and no further.
2. there is no way to force the regeneration of the index allowing inclusion of pages generate manually?

In answer to your suggestions–Symon 2011-01-20 09:50:

1. Yes, I could think about adding that option, give me some time to find the best way/syntax. Update: a new option maxns will be added to the upcoming release. Use: maxns=3 ⇒ display up to namespace level 3 inclusive.—Symon 2011-01-30 16:05
2. You could use the searchindex plugin to re-index your pages now and again, or open the added pages within Dokuwiki and save to force a re-index

Many thanks for your solutions. Maxns works just as I thought and searchindex it's perfect.

I seem to be having trouble using maxns to limit the results to the current namespace only (i.e. I don't want any of the pages with appear in the subnamespaces. While I could probably figure out the proper regex to accomplish the same thing, I expected maxns=1 would just be the root ns (:one:two:three), and wouldn't return the next levels (namespaces “two” and “three” would be ignored). However the following 3 pagequery commands return identical results, which confuses me. Am I missing something, or can you suggest a way for me to do this using regex?

~~NOCACHE~~

maxns 0 (should return "all", including pages within sub-namespaces, this is the default when maxns is omitted): \\
{{pagequery>@one;maxns=0;nostart;sort=abc:asc,name;proper=both;abstract}}

maxns 1 (should return only the specified namespace, and ignore any pages in any sub-namespaces): \\
{{pagequery>@one;maxns=1;nostart;sort=abc:asc,name;proper=both;abstract}}

Trying to exclude a namespace specifically, also doesn't seem to work: \\
{{pagequery>^one:two @one *;maxns=1;nostart;sort=abc:asc,name;proper=both;abstract}}

Using the alternate syntax to the one immediately above should be identical, but instead, no pages are found: \\ 
{{pagequery>-ns:internal:projects ns:internal *;nostart;sort=abc:asc,name;proper=both;abstract}}

I was able to almost get this to work by adding the “fulltext” option, but then “nostart” is ignored. (Note that my namespaces are internal and internal:projects instead of one and one:two used previously.) Also the following pagequery with “fulltext” omitted, generates an error¹⁾:

An attempt using fulltext works, but note that "nostart" has no effect with this one: \\ 
{{pagequery>@internal * -ns:internal:projects;maxns=1;nostart;sort=abc:asc,name;proper=both;abstract;fulltext}}

Omitting "fulltext" like this, generates an error message (see footnote above this code block) and therefore also returns no results: \\ 
{{pagequery>@internal * -ns:internal:projects;maxns=1;nostart;sort=abc:asc,name;proper=both;abstract}}

Thanks in advance for any help and/or suggestions. —Rick 2011-07-15 14:24

With all my recent changes and refactoring maybe there is something quirky going on here. I'll do some checking and get back to you on this. Thanks for the useful error reporting, it's appreciated.—Symon 2011-07-16 07:55

Ich habe bei meinem Dokuwiki das Vector-Template installiert und habe in der Navigation auf Namespaces verlinkt. Eine solche Namespace-Seite habe ich (da wie eine Art Index gedacht) nun mit diesem Code gefüllt:

{{pagequery>@fahrzeuge;fulltext;sort=ns,name;group;cols=1;proper=name;nostart}}

~~NOCACHE~~

Die Startseite selbst, also eben diese Namespace-Seite, auf der man sich gerade befindet, wird aber ebenfalls in der Liste dargestellt, genauso wie alle Startseiten der “Unterkategorien”, denn ich unterteile den Fahrzeuge-Namespace nochmal in Toyota- und Lexus-Fahrzeuge, und danach jeweils in Konzept- und Serienfahrzeuge. Überall, wo es Seiten in diesen Namespaces gibt, wird in der Liste auch die entsprechende Startseite des Namespace mit angezeigt. Woran liegt das? Denke ich falsch, und das ist ganz normal, weil das gar keine Startseite ist? Kann ich die aktuelle Seite denn irgendwie ausschließen?

- Jorin 28.01.2011

Please stick to english language. At least to let the plugin author understand it.
Do you use “start” as default name for start-pages? — lupo49 2011/01/28 19:36

Sorry, I read this notice and thought I could write in german:
“NOTE: I understand both French and German, so feel free to explain your problems, requests and suggestions in those languages also if it is more comfortable for you. Any useful information that comes out during discussion will be transferred to the main page now and again.”
Yes, I use “start” for the start page.
- Jorin 28.01.2011

Seems to work now. I had the start page named “Start” in the admin section. Changed this to “start” and now it works great!
Thanks for your help, lupo49.
- Jorin 29.01.2011

I was going to mention that the plugin honours the start page name as configured in your config file. Thanks for sorting that out lupo49. I read German fine so no problem; I might mention this potential problem in the FAQ when I get time (in English)—Symon 2011-01-30 16:10

That's the way the built-in sitemap works : pages for which current user has no read right don't appear in listing. Would that be possible to implement the same functionality in pagequery? It could be a standalone option like inwords or nostart…
—Pierre, 2011-02-15 18:50

Well, I thought it already had this functionality; I did include a ACL check in the code, as below:

syntax.php
 
656    } elseif(auth_quickaclcheck(trim($pages[$idx])) < AUTH_READ){
657        unset($pages[$idx]);

If it is not working correctly I'll need to find out why.—Symon 2011-02-15 21:22

My mistake, I was too prompt to post this topic… At least for my problem (I'm not in Rick's case) after a few checks it turns out it was just a cache problem. Thank you anyway for the quick answer!
—Pierre, 2011-02-16 07:52

Works great for me at the page level (I'm running the latest available version as of this date and LOVE it), but would like it to also more elegantly omit at the namespace level, instead of showing “no results for @namespace”.

NOTE: I have a rather simple architecture where there are only several namespaces off the root (e.g. no subnamespaces). I use pagequery to build my own site-map (which is at the root), and I group my list of pages by namespace using pagequery> @namespace.

In short, I'd like to have a namespace listing that Editors see on this site-map, that normal (default) users do not; I have a page where there are multiple pagequery statements for each namespace in my Wiki. Hope this is clear. —Rick 2011-02-15 15:32

As you can see from the many fulfilled requests above, I would be happy to help you. However I'm still not entirely clear as to what is needed (and how to implement it… I only use the plugin on my home server.) Can anyone explain in more detail:

1. What is meant by “more elegantly omit at namespace level”? Do you mean that PageQuery should better distinguish between “No results” and “No rights”?
2. Could you provide an example of how the omitted result list should be displayed?
3. Any thoughts on how to implement this feature?

—Symon 2011-02-16 08:30

What I was intending to request was simply a switch that would make the pagequery “silent” if no results are found. By this I mean, it shouldn't return the group heading or any text at all. Is that more clear?

Would be even niftier if you could provide a parameter to define the way the result message reports… then you could specify “” (blank) as one of the options and achieve this result, AND you'd be able to also customize the “no results” message. For example, a “noresultmsg” keyword…

noresultmsg="No matching pages found in the namespace, perhaps you will find what you were looking for on the [[:sitemap:site map|Site Map]]."

If you were really ambitious, you could also allow tokens in the message so you could use global variables… something like

noresultmsg="We're sorry, @@username@@, there were no pages found to include on this list.",@@username@@

—Rick 2011-07-15 14:03

Am I correct in inferring that you would like to be able to do this on a case-by-case basis (i.e. as another option), or globally in the plugin's configuration? I can provide a simple off “switch” quite easily, in fact it is a very good idea.—Symon 2011-07-16 10:09

Yes. Your inference is correct. For advanced search queries that have multiple groupings (and corresponding headings), I wanted to be able to have the group omitted silently instead of having to see a “no results” message. I was also suggesting that being able to customize the no results message (perhaps even with tokens) would be a good feature, too.

I will try the zip below. And respond to that with the results later this afternoon. –Rick 18.7.2011

Try this :https://github.com/downloads/MrBertie/pagequery/pagequery_16-Jul-2011.zip and see if it fixes your issues. There is also a new option nomsg which removes the “no results” messages.—Symon 2011-07-16 13:40

Oh no! The site is down now. I installed the update using the plugin manager and get the following error message:
“Parse error: syntax error, unexpected T_FUNCTION in /var/www/navaradocs/lib/plugins/pagequery/syntax.php on line 860”
–Rick 18.7.2011

The error occurred because my server wasn't running PHP 5.3 (it is running PHP 5.2.7. I'll need to wait until my IT service team upgrades PHP on that server to test the update to the pagequery plugin. Not sure when they will do so, but I will post the results here when I can do it. –Rick 18.7.2011

I have installed your plugin and it works well with pagenames. Now i have enabled useheading und try to get a query like the following:

{{pagequery>@directory;sort=a,name;group;proper;cols=3;title}}

The result is a list with titles, but sorted by pagename and not title. Is there a way to group and sort by title?
—Stefan 2011-02-24 22:25

Thank you for pointing this out Stefan, it is supposed to sort and group by title if enabled, but there is a logical error in the code. I've fixed it and will release a new version today if time allows. Released 2011-02-26 20:04—Symon 2011-02-26 12:20

I am using and appreciating your plugin every day. I took me some time to work out one thing, and now I am stuck with another. So maybe I can help, while asking help myself.

The example of listing pages starting with numbers [0-9]+.* didn't work for me. Instead I got a listing of all pages which had a number in them. The same thing when I tried listing only pages starting with the letter “a” (a+.*), I got all pagenames containing the letter a…

I played around a little, and concluded this requires fullregex mode, so the working syntax reads:

{{pagequery>drafts:[0-9]+.*;sort=name;fullregex}}

I'm up to date on the stable branch of Dokuwiki and Pagequery 0.6.8.

For starters you'll need to use a regex like ^[0-9]+.* to filter only words beginning with, however, to provide some consolation: there is a problem with the regex searching code, which I am busy fixing. fullregex is just for searching the entire pageid including namespace, that's why your 2nd example works. Watch out for a new release in the coming days to resolve your problem.—Symon 2011-Mar-05 21:18

Wouldn't starting with ^ also indicate skipping a namespace…? —Eivind 2011/03/06 14:10

Yes, hence see the additional comments in the parameter description table further up the page. I'm trying to offer the best of both worlds: Dokuwiki syntax and regular expressions; it's the best solution I can come up with for now.—Symon 2011-Mar-07 21:38

I have pages that are called 1, 2, 3 and so on, and articles that start with numerical values like 10, 100, 1000, etc. It is important for me to list these logically. Is there any way to do this with regular expressions, or do I have to change some code in the plugin itself? To be fair, I also have this “problem” or need with another plugin, so maybe the solution lies not in changing any Pagequery code at all, but rather in Dokuwiki… —Eivind 2011/03/05 11:09

What you are looking for is called “natural” case sorting; this is of course possible Eivind, however it will require a complete rewrite of the multi-column sorting function the plugin uses (because the PHP function array_multisort does not provide natural sorting.) I'll think about it, but providing this will considerably slow down the plugin, because sorting would have to be done manually in PHP.—Symon 2011-03-05 17:38

Thanks for the quick response! Would there be a possibility of using a different PHP function that provides natural sorting, in exchange of limited plugin functionality? I'm just asking out of curiosity. —Eivind 2011/03/06 14:20

I wish it were that simple, unfortunately the existing natsort function provided by PHP is for one-column only, which would severely reduce the functionality of pagequery. There are other solutions like I said, but they are not simple, and once I get some more time I'll look into your request (solutions are welcomed!)—Symon 2011-Mar-06 16:51
UPDATE: Just a quick update, I have a new version running on my dev machine at home that now allows correct natural/caseless sorting (and perhaps a few other sorting options too… WIP). It's functioning well so far, but it needs a bit more testing before I can release it officially. Thanks for the idea Eivind, it required a 50%+ code rewrite but I think that the result is a better, more flexible plugin. I also ended up with some pretty useful array multi-sort and grouping functions that will serve me well in other projects. Check the source of the new release if you are looking for something like that.—Symon 2011-Mar-15 16:40

Thanks for the update! This was above my expectations, however I am not able to get it working, it returns an error for line 118 in inc/msort.php… I am running the latest XAMPP release forOSX (PHP 5.3.1). —Eivind 2011/03/29 12:20
Hi Eivind, I cannot duplicate your error on my setup, could you send my more detail of your problem (full error message, screenshot, etc…)?—Symon 2011-03-29 11:30

The error comes when I'm trying for fullregex, Warning: Invalid argument supplied for foreach() in […]/pagequery/inc/msort.php on line 118 (as many errors as number of files). Without any parameters I get a No results for the search query: […]. Anything I'm doing wrong?

There was a problem with the fullregex option, which has now been fixed in the 0.7.1 release on the plugin page. Hope that does it for you. I've tried every possible option there is and it all works correctly.—Symon 2011-04-01 16:45

After testing the new version extensively, I have decided to go back to the previous version. I am using Pagequery very actively in navigation, and one of the factors that made me choose this in the first place was the speed of the plugin. This, unfortunately, seems to be one of the costs for natural sorting… Or maybe the cache system has changed in the more recent development version of Dokuwiki?

I'm sorry to hear that; on my own installation the new version does not seem to be any slower than the old one, maybe the problem is something else. I could do a proper performance test if you like. How many pages do you have in your wiki?—Symon 2011-04-11 12:48

I'm happy to hear that, and will give it another go after upgrading server and dokuwiki. My example: I have a template page containing links A:start B:start C:start, etc. These pages each contain a pagequery query similar to >wiki:a.*;fullregex;nostart. The template is included on top of each of the start pages, effectively creating the illusion of an alphabetical sorting option. Although I only have around 120 pages at the moment in that particular namespace, it took the new version around 3 seconds to show a page (in local development), which dispels that illusion. —Eivind 2011/04/11 20:28

The problem is not the sorting (120 pages on my home wiki averages 0.03 seconds to sort); I'll profile the code and see what the delay could be.—Symon 2011-04-12 21:55
Hi Eivind, I just profiled the plugin using xdebug and webgrind and the problem is overwhelmingly two things: 1.Getting the the page metadata (I changed the code to retrieve it only once per displayed page—shaved off 1 second), and 2.The ACL check on the page results. There is little I can do about either of the problems as they are part of the Dokuwiki core, but be assured that the slowdown is definitely not the natural sorting routine.—Symon 2011-04-14 19:00 Here's the latest version if you want to check it out!

Although my wiki: namespace is around 120 pages, the total number of pages in my wiki is 7.000… And that is just for development and testing, the production version will have closer to 100.000 pages. The thought crossed my dull mind that maybe this affects the speed of a fullregex search? —Eivind 2011/04/12 22:23

I have also thought of making a tableless version for single column usage, where the TOC will overlay the abstract/snippet, and not push it down. So that means I will have two versions of Pagequery running for separate purposes. Please let me know if this sounds like a bad idea. —Eivind 2011/04/11 10:59

I don't quite understand what you mean by: “TOC will overlay the abstract/snippet, and not push it down…”. Could you explain further?—Symon 2011-04-11 12:50

The pagequery table “collides” with the TOC, and is pushed downwards on the page, creating unnecessary empty space between header title and content. I want the TOC to make the text flow around it instead. Please forgive, but I cannot explain better at this late hour… —Eivind 2011/04/11 20:31

Got you, your explanation was fine, my understanding was lethargic! I've played with the code so that when only one column is displayed no tables are used. Is that what you are looking for?—Symon 2011-04-12 21:50

That's exactly what I'm looking for! Since you are both effective and responsive, how about this one: The abstract usually hides stuff that exist within a WRAP (DIV) or image captions from the Imagebox plugin. However, typographical replacements, acronyms and entities like (c) show up none the less, making the abstract less appealing. I can of course turn off the replacements and remove the affected acronyms, but if there exists another solution, I would be happy to hear! —Eivind 2011/04/12 22:12

I would like to find a better solution myself also. The snippet is based on the abstract meta-data entry, produced by the built-in Dokuwiki meta-data renderer. I would prefer to show the abstract using normal Dokuwiki markup, but that's going to have to be a project for another day. I have not worked out how to do it yet. Any suggestions are welcomed; what do you hope to see in the snippet?—Symon 2011-04-14 17:55

The snippet is not bad at all, although I wouldn't mind what you have mentioned below in regards to character limitation, or maybe just showing the first sentence or paragraph. In that way, I don't have to count characters when writing introductions. I actually turned off the typographical replacements and removed some of the abbreviations/acronyms to overcome the problem challenge I faced. Working within the boundaries often works just as well as trying to expand them. —Eivind 2011/04/16 18:04

Why does this code {{pagequery>* ^calendario;sort=mdate,name;limit=10;inwords;abstract=none}} not exclude “calendario” namespaces?

See the instruction table above: the namespace needs to be before the * or other page name query. I'm still looking for a better solution, but that's the way it works for now.—Symon 2011-03-08 08:49

Ah, okay, I had not grasped it but now it works, thanks :)

If any pagequery users have suggestions for how to improve the query syntax (it is modeled on the current Dokuwiki search syntax) please feel free to offer them. The main problem is distinguishing between ^exclude_namespace and ^regex_from_start_of_line (i.e. they both use ^ at the beginning!). Right now, as mentioned in the instructions, the plugin assumes that the last item is the search query.—Symon 2011-Mar-15 16:48

I am just trying out pagequery and downloaded the new 0.7.1 version. I have the following:-

{{pagequery>@blog ;fulltext;sort=a,name;group;snippet=0}}

It just produces a column of square dots (like list ones, but nothing more).

If I change it to:-

{{pagequery>@blog ;fulltext;sort=a,name;group;snippet=10}}

The I get the expected 10 snippets, any number other than 0 seems OK, so I can work around the issue by setting a large number.

While I'm at it is there any way to set the maximum length of the snippet (or to get it to show only the first line/paragraph) and is there a way to get the snippet on the same line as the link?

Chris Green

Hi Chris, looks like you have some very specific needs there! As you can read in the help there are already many, many, options for pagequery (yes, it confusing as you say on th emailing list—if you have suggestions for improving it then this is a wiki after all. I've tried to do my best.) The snippet is based in the built-in Dokuwiki abstract meta-data. It would be possible to set the maximum length of the snippet and also to place it on the same line. However it is going to create yet more options (which the next person is going to find “confusing”… I'll see what I can do.

OK, thanks for the very prompt response! I'm also looking at the dir plugin which provides similar (but subtly different) functions. My requirement is that I want to be able to select entries from a blog which relate to a particular subject (engine/vehicle servicing) so I can display a service history. The idea is that I just blog some information when I service my 'bike (or do some work on the boat engine), I mark it in some unique way (specific string, tag or meta data) and the dir or pagequery plugin will allow me to display the service history. Thus my ideal is to present the output something like:-

    link_to_blog_page           Description of servicing done
    link_to_earlier_page        Description of servicing done
    link_to_another_page        Statutory test carried out
    link_to_another_page        Bought new tyre
    ...                         ...

Okay, I played around a little and have the inline snippet idea working, currently with a character limit. The option would be specified as follows: snippet=inline:50, where the 50 refers to the no. of characters to display. However based on what you are looking for which part of the page abstract would you want to display? Always the 1st line, or no. of words, or something else? As for tagging, well you could just use a unique word each time, e.g. bikeservice (note: no spaces, the Dokuwiki search indexer delimits based on spaces and ignores all other punctuation). Then do a fulltext search based on that word only. Would that achieve what you want?

If not then you'll need to build a plugin to add tags into the new meta-data index, and it would be relatively easy to add a meta-data search option to pagequery. BTW: did you look at the subjectindex plugin too?—Symon 2011-04-10 20:09

I'll check if there is a bug there on the snippet=0 option (actually snippet=all should work). Also as it says in the instructions, if you use a namespace parameter then you need a query for the page also (* is enough)—Symon 2011-04-09 21:38 FIXED in next release

Brilliant, thank you. I'd just want the first line of the abstract to be displayed.

I have the meta plugin and the tags plugin so I can insert both tags and meta-data, however I'd really prefer to use the fulltext search of the page without having to insert tags or meta data. The tags plugin in particular is a nuisance because the tag gets into the page description so appears in the abstract/snippet. I was hoping to be able to use ^[0-9][0-9][0-9][0-9][0-9] to match any page with a line starting with five digits but I can't get it to work at the moment.

By the way I keep getting the following error displayed, not always but quite often:-

Warning: Invalid argument supplied for foreach() in /var/www/wiki/lib/plugins/pagequery/inc/msort.php on line 118 

Sometimes I get hundreds of these. I get it with the following pagequery code:-

======ZZR1200 Service History======



====Using pagequery Plugin====
{{pagequery>@blog:bike :00000;fulltext}}

I think I have just realised why my attempt above didn't work. If I (now) understand correctly the regular expression search only works for searching in the name of the page (or in the page ID if you use fullregex). Using fulltext does a DokuWiki type search in the body of the page but that doesn't allow RE search, only 'word' search. So I'm a bit stuck, the options for me seem to be:-

• Use a word in the body of the page which I can search for, but that might be ambiguous and it's a bit of a nuisance to always have, say, 'bikeservice' written on a page which is obviously about servicing the bike
• Tag the page with a tag such as 'bs', the trouble with this is that the bs appears in the snippet/description and it just looks a bit odd there, it also requires that I put bs on every bike service page
• Use meta-data, very similar to tagging the page except that it's slightly better in that the 'bs' (or whatever) won't appear on the page.
• Put something unique in the page heading that pagequery can find

Hmmmm, I can see myself writing a plugin to do what I want!

Whatever you do you'll have to write something on the page to recognize it as part of your “group”; I think what you are looking for is hidden tagging. If you write a plugin to create the necessary meta-data it should be easy enough to search it as part of pagequery. For example I could add an option called meta, i.e. meta=tags:<tag-name>. It might be an option. It all depends how complex your needs are. Pagequery has some useful searching, sorting, and grouping functions that may not be needed, so you could just create a simpler plugin that does exactly what you need. It's good to hear that you are willing to write a plugin, but be prepared to spent some time writing it!—Symon 2011-04-11 07:55

I think I'm going to adapt the dir plugin to do what I want, it's pretty close already. I've already written a couple of other plugins so it's not too frightening! Thanks for all the help and comments so far.

Glad to hear to found what you need, all the good ideas start with a genuine need. Look forward to seeing the result soon.

I don't know if it is possible to add the search in the current namespace (of the page) like this example:

{{pagequery>@. ^mypage.*$;nostart}}

Perhaps there is another way than to completely write the namespace.

Not at the moment, but this sounds like a good idea, I will try to add it to the next release when I get a little time!—Symon 2011-05-13 08:35 EDIT: this now works in latest 0.7.3 version.

Hi Symon. Great plug-in!! This is actually 2 questions in one.. Firstly are you able to clarify how it is best to go about excluding certain pages in a namespace? For example I have a namespace where I only need to show around half the pages in the pagequery based index. So I have started all the “hidden” pages (page id's) with zz. So I would need something like:

{{pagequery>@. !zz.*;fullregex}}

Or can it be done without fullregex in a simpler way? Or is what I´ve done there just plain wrong ..

There is no facility for excluding certain pages except a regex query; any other solution (like lists of pages to exclude) would quickly get messy and hard to maintain. As for your regex something like this should work:

{{pagequery>@. ^(?!zz).*;fullregex}}
^ => start from beginning of pageid
(?!zz).* => any text not beginning with "zz"

Second smaller point, seems since I upgraded to the current version (0.7.3) the pagequery table insists on taking up much more than 100% of the screen (with IE8, not sure about other browsers..) leaving me with a horizontal scroll bar and lots of white space, did you change the CSS? Cheers! —Hans 2011-06-17 20:50

Hi Hans, this does sound like a IE8 issue; I do not have this problem in Firefox, Chrome or Opera… I'll try to find what the cause is. There is a change in the newer version, where no table is used if there is only one column—this works better with the TOC. Symon 2011-06-21 20:47

Hi Symon - Fantastic work - really appreciate it. However I recently upgraded to dokuwiki 2010-11-07 + PHP53 + pagequery current, building index page within namespaces is failing with 'No results for the search query' message. I was using:

 {{pagequery>@system_checklist:reports;sort=myear,mmonth;group;inwords;cols=2;border=both;nostart}} 

and is getting

 pagequeryNo results for the search query:   @system_checklist:reports 

where systemchecklist:reports is the namespae I am interested in searching. I have no problem build the index from the entire site:

 {{pagequery>}} 

I could not see any errors in any of the log files. If I put in @system_checklist:reports into the search box of the wiki, all the pages shows up. Would you please help?

thanks and regards Dickson

If you type:

 {{pagequery>@system_checklist:reports *;sort=myear,mmonth;group;inwords;cols=2;border=both;nostart}} 

it should work (notice the “*” at the end of the query). I'll also check if there is a problem here in the plugin.—Symon 2011-07-01 14:05

UPDATE: since the addition of relative namespace queries in 0.7.3 the syntax now matches the normal Dokuwiki namespace format. That means if you want to refer to a root namespace you'll need to change the query to @:system_checklist:reports otherwise the current namespace is assumed. Sorry for any frustration!—Symon 2011-07-09 18:54

Hi Symon. I just started using pagequery to add navigation to the sidebar of the starter template. I basically use

{{pagequery>@test;fulltext;sort=a,name;title}}

The list is generated fine, but it does not use page titles, only page names. I tried it in pages as well, same result. I also tried all settings of useheadings. The page titles (in the browser window) are good, as are the breadcrumbs. What am I doing wrong?

Thanks! Paul

Sorry Paul, there was a regression (error in previously working code) in the latest version which prevented the title option from working as intended. If you want a quick fix then download the latest version from source; I fixed the problem there already. My apologies for any frustration!—Symon 2011-08-22 20:24

Hi Symon. That did it. It's working correctly now. Thanks for the quick fix!—Paul 2011-080-23 11:25