Recent Changes - Search:
Cookbook /

PageListMultiTargets-Talk

Summary: Talk page for PageListMultiTargets.
Maintainer: Petko
Users: +2 (View / Edit)

This space is for User-contributed commentary and notes. Please include your name and a date along with your comment.

Please add new questions at the top of the page.

Note: The following comments are about earlier versions of the cookbook recipe, before a similar function was added to the core.

Trying to find pages in the Main group orphaned from a trail on the Main/ManualTOC page of my site. (:pagelist group=Main links=-Main.ManualTOC fmt=#titlespaced:) Pretty sure it's failing because it returns 317 pages -- everything in the group lol. XES October 27, 2021, at 05:32 PM

You may be able to find pages that do not contain the string "ManualTOC", which is probably unique, with "Main/ -ManualTOC" in the search field. What is your trail markup in the pages? --Petko October 27, 2021, at 06:25 PM

I think all the trail markup on the pages is in the header/footer of the group. So the trailhead page uses (:nogroupheader:) — so searching for pages orphaned from the trail that way wouldn't work, they don't contain the ManualTOC markup themselves. I'm looking for pages in the group NOT linked-to on the ManualTOC page. We thought that's what this markup was supposed to do — find pages NOT linked on the "links=-NotLinkedToThisPage" Maybe we misunderstood? Thinking about it yeah, I think we misunderstood. Oops. We want pages in Main group that are not in the link list (trail) on the ManualTOC page. Basically check for orphaned pages not in the trail. XES November 07, 2021, at 03:34 PM

In that case you can use (:pagelist group=Main if="! ontrail Main.ManualTOC {=$FullName}":), see Test.OnTrail. The pagelist's link= or links= argument refers to links to the specified page. It does not refer to links from the specified page. It also only looks inside the page, that is with disabled headers, footers, and included pages, that's why a trail markup in a footer will only be found in the footer page (PmWiki philosophy #1 Favor writers over readers). --Petko November 07, 2021, at 03:52 PM

Oh that makes sense. That also almost works — but for some reason the 1st level ordered list links aren't being detected as being part of the trail? (i.e. they're still showing up in the results.) However it's much closer to what I was looking for. (https://kinhost.org/Main/ManualTOC is the page if that matters, I think wiki source is hidden on purpose.) XES November 18, 2021, at 11:32 PM

Pages are considered "on the trail" if the link is the first thing after the bullet or hash (and spaces) on the line: 

# [[Page 1]] is ON the trail ✅
#         [[Page 10]] is ON the trail ✅
# Text [[Page 11]]  NOT on the trail ❌
# [==] [[Page 12]]  NOT on the trail ❌
#   [[Page 13]]  NOT on the trail ❌

# [[Page 2]] %item style%  is ON the trail ✅
# %% [[Page 21]] NOT on the trail ❌
# %style% [[Page 3]] %% NOT on the trail ❌

# [[Page 4]] [[#intro]]  is ON the trail ✅
# [[#intro]] [[Page 5]] NOT on the trail ❌

You cannot place anything between the hash/bullet and the link, otherwise it is not on the trail, see WikiTrails#creating. Your "Introduction" link on the trail is preceded by an anchor. The link will be considered to be part of the trail if you place it before the anchor. Also, some pages in the first level are in other wikigroups (Crisses, not Main). "Not on your trail" are also redirects with different uppercase letters (Co-awareness!=Co-Awareness). You can start from there. --Petko November 19, 2021, at 03:59 AM

Thanks! the last point we understood already. And of course other groups makes sense too. It was the first point we didn't know. So we'll look through for that one. Thank you so much :) XES November 20, 2021, at 06:51 PM

This recipe looks really useful! Is it still "experimental"? Also, does it significantly slow down pagelist? I tried it today on a small scale, without problems. Ideally, I see this functionality as belonging in the core as part of the "link=" parameter, but then again I don't know the implications. -- RandyB August 09, 2016, at 08:47 AM

It shouldn't significantly slow down the pagelists for a link to a single page, in most cases it would be a bit slower but unlikely noticeable. For a complex search it would be a little slower than the current pagelist, but it really cannot be compared as the functionality is much more flexible. Unfortunately, I haven't had much use for this recipe and so I haven't used it or tested it extensively; it works a little differently than the core link= function so the change is not trivial - I'm not sure if it may negatively affect existing websites, and I haven't found enough free time and peace to review/investigate a core addition. There aren't any known unfixed bugs at this time. --Petko August 09, 2016, at 03:18 PM

Why is this a recipe, and not part of the core? Michael Paulukonis March 12, 2014, at 08:05 AM

Why there are about 1387 recipes in the Cookbook that are not part of the core? :-) --Petko March 12, 2014, at 02:53 PM

That's a good question -- why are some recipes recipes, and not part of the core? What is the determination that makes something "simple", and keeping with pmwiki-philosophy, and something else not? Just look at the complexity in the pagelist that you did use to generate that dynamic number, above! This is a meta question, though. And maybe more appropriate for mailing list than this talk page. --Michael Paulukonis March 13, 2014, at 09:04 AM

I think that the answer is that it is a very heavy workload (which is done extremely well) simply supporting PmWiki (email, website), enhancing the fundamentals (e.g. for PHP 5.5, UniCode), and the monthly bugfix release, for there to be have been much discussion about the road map (and here).
While the community can, and has, made suggestions for Core Candidates, there is also currently a strong philosophy, as I see it, that features and enhancements should be delivered as recipes, even where they involve minor changes to the base code and do not change the look and feel of PmWiki.
Obviously we do not want all recipes to be part of the core, on the other hand it is easy to find a dozen or so that would easily fit the definition of being functionality, or improvements to functionality, that most wikis would benefit from. I only have to look at the list of recipes I have found useful in running two community wikis to realise how hard it is for new users to build up a portfolio of recipes that give that extra usability from the UI that supports their contributions.
Its been a number of years since a recipe was added to the core (Cookbook:Blocklist3 or Cookbook:InlineDiff I think), so the reason why more recipes have not been added to the core is solely in the hands of the code committers, and the decisions they have made about the size of the core, the functionality of the core, and the way they allocate their scare and precious time/resources.

simon

Finar:
Wow! Greate! I was waiting for this for a long time! Thank you!

There is a question: what if I want to use another field instead of default "targets" to be processed? Is there any way to change what field to proceed? The root of my question is that I have a special field "tags" which format and data is similar to default "targets" (I made a separate field because of I need to fill it manually with different unlimited tags) When pagelisting, I have to use constructions like @ $tags=*mytag1*,*mytag2* but is not a very good idea. This solution could be perfect, if I could decide what field to parse.

The recipe benefits from the fact that PmWiki already keeps an index of all links in the wiki.d/.pageindex file, so the search for links is really very fast unless some files were modified out of PmWiki, in this case they are reindexed at that point. Your "tags" field is a page attribute, right? If you just modify the page attribute $page['tags'] instead of $page['targets'], it will not be better/faster than what you have now (and the recipe will need changes as now it expects Group.Page names). --Petko June 21, 2013, at 04:10 PM

Thank you for your answer! To start using default field 'targets' instead of my 'tags', I use the following code in config.php: PZZ(PCache($pagename, $zz=array('targets' => SetProperty($pagename, 'targets', PSS($ParamFromGet))))); . The problem is that it works over default pmwiki saving mechanism (I guess SaveAttributes function but I'm not sure ), which calculates targets from wikipage's body text. What is the correct way to sum target values calculated by pmwiki SaveAttributes, and my own target values? And second question: what is the right way to disable pmwiki core targets calculating and saving mechanism? Finar June 23, 2013, at 03:22 PM

I can't recommend placing your tags list into the 'targets' page attribute - many other things may break. There may be better/easier ways, for example considering all tags as links to pages in the Tags.* group. I'm passing exams now so if you can wait 2 weeks, we'll work on it after July 6. Just tell me how exactly you have configured the "tags" attribute: how you add tags, how you store, search and display them. And what you want to be improved, is it write tags=mytag1,mytag2 instead of $tags=*mytag1*,*mytag2* or is it something else. --Petko June 23, 2013, at 06:46 AM

Petko, thank you for your readiness to help. Yes, I can wait for 2 weeks, and I hope will finish my prototype-site at that moment. But if you don't mind I will describe my ideas now, because of now I'm in development process and can describe it clearly.

My main idea is to make a wikisite which can sort it's content by itself. It means:

  • every page can be tagged with unlimited count of tags
  • tags = any other pages of wiki
  • tags are sorted suitable by groups in edit mode and can be selected by clicking mouse
  • every page itself can become a "tag" for another page and can be "tagged" by other pages at the same time

Why I need it? That's because I write a blog about all my life and I do not know ahead, how I will need to sort it in future. So, I want any my of posts get ready to become a "tag" itself.

What I have done already:

0) Finishing watched-movies-dairy site as a prototype just to get enough experience and understanding.

1) I have developed a cookbook solution, that makes a html-form with all pmwiki sitemap selectable. So, for example I have "Movies" group with films. And I have "Actors","Directors","Years" groups and pages inside. When adding new Movie, I can easy select any pages of all that groups (html <select> was used ). Even if I will make new group "Type", this group and all it inside pages will automatically appear in EditForm-Movies.

2) All selected "tags" are stored as a text-line, exactly like default targets. There is a question, where to put them?

If I will put them in separate field "tags":

  • (-) I will need to write something like " pagelist $:Tags=*Actor1* " when trying to form backlinks on page Actors.Actor1
  • (-) Low performance

If I will put them in field "targets":

  • (-) conflictig with core wiki engine: either integrate with it, or disable it (?)
  • (+) working fast, can be used on "low level", like using PageListMultiTargets with good pagelist constructions like " pagelist links=Actor1,Actor2 " if I need it.

If I will put them inside page's text:

  • (-) I have a deep feeling that page content must be fully separated from anything
  • (-) now I have a GUI for selecting tags, it will be difficult to integrate it

Finar June 23, 2013, at 09:12 PM

Update 2013-07-07: Hi Petko, I've finished my site-prototype. Here you can look and even play with it: http://demo.memofilm.ru/ I'm sorry for russian language, please let me know if it need to be translated, but I believe it does not, because of all URLs are English. The edit pass is 39usdz38fj3k .

So, here on the main page we can see the Movies List. All movies are sorted by "MultiTags" from side bar on the left. The main feature is that site admin can add any new Tags Group just by creating new wiki-group from SideBar. After creating new Tag Group and filling it with Tags, we can use this new created Tags Group for sorting Movies.

All my tags are written to the "targets" field, and can be accessed by PageListMultiTargets: here we can find all Movies, which are NOT sorted by any Country.

The problem is that if I will use [[SomeLink]] inside Movie description field, it will conflict with my tags saving php-code.

As a matter of fact I don't need PmWiki's internal links saving mechanism, because of:

  1. this site is not a wiki
  2. in Russia, the correct SEO is to make English-transliterated keywords ( like example.ru/nazvanie/ ) and separate title ("название") for page's h1 and title. So, we don't really need wikiwords in Cyrillic wikis.

Finar July 07, 2013, at 02:49 PM

You say you don't need PmWiki's internal links saving mechanism. If you really don't need core backlinks and categories from the page content, and if all your pages are categorized with your "tags" line, the easiest thing may be to replace the content of the "targets" attribute with your "tags" line just before the page is saved. You insert a custom $EditFunctions entry before PostPage() which will replace the targets attribute. Something like this: 

  array_splice($EditFunctions, array_search('PostPage', $EditFunctions), 0, 'ChangeTargets');
  function ChangeTargets($pagename,&$page,&$new) {
    global $EnablePost;
    if (!$EnablePost) return;

    # !!! make sure you sanitize the input !!!
    $tags = implode(',', $_POST['phph-tags']);  # !!!

    $new['targets'] = $tags;
  }

This will take care of everything - the page index, the tag-backlinks and this recipe here will work like you want, but it will effectively disable the caching of links from a wiki page content. If in a page you have a link in the text, and not in the "tags" line, a pagelist will not find this page. If you require both features (tags AND targets), you'll need to write a much more complex recipe. --Petko July 07, 2013, at 05:02 PM

Note, when you install this, it will work on newly saved pages, so re-edit and save your existing pages. --Petko July 07, 2013, at 11:59 PM

Great! Thank you, Petko! It works for me and now I have a site with manual links creation! It gives me 2-level tags and content self-sorting. That is what I needed, thanks!

Finar July 08, 2013, at 04:14 AM

It it possible to have this recipe seamless replace the link= pagelist parameter

simon March 11, 2014, at 08:29 PM

Yes, with the latest version. --Petko March 12, 2014, at 02:53 PM

A belated thanks for this change. Definitely a recipe that should replace current core functionality.

simon April 10, 2015, at 04:30 PM

In config.php I have 

 $EnablePLMTLink = 1; # replace distribution link= parameter
include_once("$FarmD/cookbook/pagelistmultitargets.php");

I have a pagelist

(:pagelist link=+Category.Process,+Category.Business fmt=#titlesummary list=normal group={$Group} name=-Template* order=title:)

On a page I have

[[!Process]] [[!Business]]

The pagelist does not select the pages with Business AND Process categories. Any ideas on how to debug?

simon December 22, 2015, at 04:09 PM

Thanks for reporting, there was indeed a bug, replacing core link= parameter never worked. Should be fixed now. From your report I assume that nobody ever tried to use the recipe with link= in the last 21 months... :-) --Petko December 22, 2015, at 05:01 PM

Talk page for the PageListMultiTargets recipe (users).