|
Main sidebar
|
PITS /
00447Summary: Distinguish !Page and Category.Page in backlinks
Summary was: Categories Not Indexed Created: 2005-06-06 06:25
Status: Suspended - technical difficulties
Category: Feature
From: XES
Assigned:
Priority: 5544443 33
Version: 2.2
OS: pmwiki.org
Description: On PmWiki.org, I noticed that Category.Category is not showing many category entries. For example, "Blog", "Bundles", etc. which are used in the Cookbook area. In fact, it seems to be working backwards and only showing the items that are linking to pages, rather than items listed as in a category. "Search" is the category used on Cookbook/SearchExtensions, but it shows up under GroupFooter category -- because it has a link to Category.GroupFooter on the page, not because it's in the GroupFooter category. This means the site's nifty "indexing" feature is broken. The feature that was originally requested exists and can be enabled via Allow distinction between !Page and Category.Page in backlinksAdding to this PITS entry, rather than create a new one, since I think these are related 2010-01-10 reopened to see if we can achieve some action on the following: There is a clear distinction between
When referring to "categories" it would be useful to be able to distinguish between Consequently one could then create a pagelist of all declared (ie defined or categorised) pages,
or a pagelist of all pages on which a Category is referenced (ie the Unfortunately This change request is to provide a means of selecting between these two I second the need for a more nuanced category listing method. I would also like to see a category listing which includes "sub" categories... skumar? January 31, 2008, at 12:07 PM
Looks like there is a solution using intermap link, as discussed there :
This may be a work around, but it does not address the original issue of I agree with Simon that this is just a work around. It complicates the usage of this way to organize information. For example it requires a different intermap for every instance of PmWiki. At least one for pmwiki.org site CategoryPmWikiOrg: and one for your local site CategoryLocalSite:. This is not easy for, and lowers the value of this feature for, the entry level of users of PmWiki; a group of users that not directly will start and acquire the knowledge to use pagelists. -- SchreyP November 12, 2009, at 12:37 PM
I am experimenting towards adding this feature. I feel that the markups:
This would make sure that existing wikis using the current BTW, the required changes to the core are not trivial and we (especially Pm) may decide to not apply them for the moment. --Petko February 26, 2010, at 09:58 PM Petko, this is a most welcome development, and the solution is elegant, and fits the 'PmWiki way'™. I hope that we will see this in time, given the amount of work. simon February 27, 2010, at 12:32 PM Hi Petko, Nice to see you found a solution that up to some level is downwards compatible. I hope the amount of work is on an acceptable level too. I still believe in the value of this simple feature. -- SchreyP February 27, 2010, at 05:11 PM The changes are now available for testing, see PmWiki:ChangeLog and get them at PmWiki:Subversion. Feedback welcome, especially eventual bug reports, mess with other markups, etc. Note that you may need to remove your existing wiki.d/.pageindex file to allow PmWiki to re-index the wiki with the new functions. This should also allow very easy creation of link prefixes similar to !Category and ~Profile, like @Tag or *Project: $LinkPrefixGroup['@'] = 'Tags'; # [[@Link]] = [[Tags/Link]] $LinkPrefixGroup['*'] = 'Projects'; # [[*Link]] = [[Projects/Link]] And these pages are found the same way, link=@TagName finds only pages with [[@TagName]], link=Tags.Name finds pages with both [[@Name]] and [[Tags/Name]]. --Petko February 27, 2010, at 10:31 PM I have suspended this request because of technical difficulties for a globally logical solution, per [1]. We'll deal with it when we find a better way to do it. --Petko March 05, 2010, at 03:25 PM I'll just add that the more I think about it the more I think this markup: (:pagelist link=\!Mycat:)
is a pretty intuitive markup, particularly to anyone who has any technical background at all. If nothing else it is 100% consistent with *so* many other languages, scripts, syntax elements, etc from other technical areas. In C, Bash, Sh, Csh, PHP, PCRE regex, Perl, etc., etc. (even CSV format!) the backslash character is used to remove special meaning from a character and make it stand simply for itself. Right now the bang (!) has the special meaning of negating the current search element -- if we used this suggested markup then all we would be doing is using the backslash to remove that special meaning in that particular context. For anyone with any programming background (or even importing a CSV file) this markup is going to be very intuitive. For non-technical authors it may take a quick explanation. The advantage of going with a "proven" syntax like this is that we have good precedent for it being very extensible in the future -- if it works in languages as complex as the list above then we can be pretty confident it is a well-designed syntactical element that we're not going to regret later. Personally I think it's worth it for the small amount of documentation that would need to be added... But I'm biased, so I'll limit my thoughts to this PITS entry rather than the mailing list. Petko, are the changes that you had proposed available somewhere? I looked in SVN and didn't see any tags that looked relevant... --Peter Bowers March 06, 2010, at 06:53 AM You can get the intermediate revision 2531 via SVN. --Petko March 06, 2010, at 07:46 AM And what about following suggestion: (:pagelist link=!/Mycat:) - Putting the "/" after the symbol.
This suggests more intuitive that we are talking about a link and not a negation; better? -- SchreyP March 06, 2010, at 08:32 AM How about this: (:pagelist link=+!Mycat:) - using an explicit "+" if starting with !
--Peter Bowers March 06, 2010, at 03:57 PM To me, the markup I think the differentiation between marking a page as having a category, and referencing a page in the Category group is important, and some means of distinguishing the two should exist. How about a new pagelist property, DaveG March 07, 2010, at 10:43 AM The differentiation between membership creation and listing can be partially achieved with available PmWiki means - simply use two pages resp. groups:
In contrast to the interwiki workaround mentioned above, links to the listing page are still real wiki links, therefore you can find backlinks to this page IOW pages referring to the category but not being members of this category. How to do it: 1. In config.php, add: $CategoryGroup = 'CategoryLinks'; # just an example name $FmtPV['$CategoryGroup'] = '$GLOBALS["CategoryGroup"]'; 2. Adapt the page lists to This solution has a drawback, if the category listing page does not exist: Since only Neither Peter Bowers' extension below nor the This problem is not specific to this "virtual group" solution - it also applies to the request above to differentiate between the two link formats in pagelists! Another issue is that following a
<?php if (!defined('PmWiki')) exit();
Redirect('Category.' . PageVar($pagename, '$Name'));
Not exactly a beautiful solution till now. OliverBetz 2010-03-09 Possible solution to the above drawback: In config.php:
$CategoryGroup = 'CategoryLink';
$FmtPV['$CategoryGroup'] = '$GLOBALS["CategoryGroup"]';
if (preg_match("/^Category[.\/]/", $pagename)) {
$DefaultPageTextFmt = '';
SDV($PageNotFoundHeaderFmt, 'HTTP/1.1 200 Ok');
}
This allows non-existent pages in the group 'Category' to appear without error messages or "Create X" messages. (This is already accomplished for the CategoryLink group with almost identical code in scripts/stdmarkup.php.) All that remains, then, is to populate those pages with a pagelist via the footer. Then CategoryLink.GroupFooter needs to be created with this source (or something similar):
(:pagelist link={*$FullName} list=normal:)
and Category.GroupFooter needs to be altered to this (note the (:Summary:content generated for Category list pages:)
----
[--'''{*$:Summary}'''--]
(:pagelist link=CategoryLink.{*$Name} list=normal:)
This whole idea is a prototype currently... The proof-of-concept now exists... It is time to reopen and complete this issue. The blocker of the use of bang (!) in expressions should be removed by deprecating its use, since the feature only recently added and is unlikely to be used widely if at all. simon June 14, 2010, at 06:16 PM
Something Hans suggested back in March was a Or, alternatively, -Peter Bowers June 19, 2010, at 09:22 AM |