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
Why is this a recipe, and not part of the core? Michael Paulukonis March 12, 2014, at 08:05 AM
Why there are about 1275 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).
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:
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
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:
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":
If I will put them in field "targets":
If I will put them inside page's text:
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.
The problem is that if I will use
As a matter of fact I don't need PmWiki's internal links saving mechanism, because of:
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
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
$EnablePLMTLink = 1; # replace distribution link= parameter include_once("$FarmD/cookbook/pagelistmultitargets.php");
I have a pagelist
On a page I have
The pagelist does not select the pages with
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