pm_to_blib
*.man
build-stamp
+po/po2wiki_stamp
+po/underlays/*/*.mdwn
+po/underlays/basewiki/*/*.mdwn
+po/underlays/basewiki/*/*/*.mdwn
+po/underlays/directives/ikiwiki/directive/*.mdwn
+po/underlays_copy_stamp
+underlays/locale
}
add_link($params{page}, $image);
+
# optimisation: detect scan mode, and avoid generating the image
if (! defined wantarray) {
return;
my $r;
if ($params{size} ne 'full') {
+ add_depends($params{page}, $image);
+
my ($w, $h) = ($params{size} =~ /^(\d*)x(\d*)$/);
error sprintf(gettext('wrong size format "%s" (should be WxH)'), $params{size})
unless (defined $w && defined $h &&
$imglink = $file;
}
- add_depends($imglink, $params{page});
-
my ($fileurl, $imgurl);
if (! $params{preview}) {
$fileurl=urlto($file, $params{destpage});
# Needs to update whenever a page is added or removed, so
# register a dependency.
add_depends($params{page}, $params{pages});
+ add_depends($params{page}, $params{among}) if exists $params{among};
my %counts;
my $max = 0;
foreach my $page (pagespec_match_list([keys %links],
$params{pages}, location => $params{page})) {
use IkiWiki::Render;
- $counts{$page} = scalar(IkiWiki::backlinks($page));
+
+ my @backlinks = IkiWiki::backlink_pages($page);
+
+ if (exists $params{among}) {
+ @backlinks = pagespec_match_list(\@backlinks,
+ $params{among}, location => $params{page});
+ }
+
+ $counts{$page} = scalar(@backlinks);
$max = $counts{$page} if $counts{$page} > $max;
}
my $res = "<div class='pagecloud'>\n";
foreach my $page (sort keys %counts) {
+ next unless $counts{$page} > 0;
+
my $class = $classes[$counts{$page} * scalar(@classes) / ($max + 1)];
$res .= "<span class=\"$class\">".
htmllink($params{page}, $params{destpage}, $page).
$backlinks_calculated=1;
}
-sub backlinks ($) {
+sub backlink_pages ($) {
my $page=shift;
calculate_backlinks();
+ return keys %{$backlinks{$page}};
+}
+
+sub backlinks ($) {
+ my $page=shift;
+
my @links;
- foreach my $p (keys %{$backlinks{$page}}) {
+ foreach my $p (backlink_pages($page)) {
my $href=urlto($p, $page);
# Trim common dir prefixes from both pages.
* Add further build machinery to generate translated underlays from
the po file, for use by wikis whose primary language is not English.
* Add Danish basewiki translation by Jonas Smedegaard.
+ * img: Fix adding of dependency from page to the image.
+ * pagestats: add `among` parameter, which only counts links from specified
+ pages (smcv)
+ * pagestats: when making a tag cloud, don't emit links where the tag is
+ unused (smcv)
-- Joey Hess <joeyh@debian.org> Tue, 02 Jun 2009 17:03:41 -0400
Either approach would require fully parsing the pagespec. And consider cases
like "!(foo and !bar)". Doesn't seem at all easy to solve. --[[Joey]]
+
+> It occurs to me that at least one place in ikiwiki optimizes by assuming
+> that pagespecs not mentioning the word "internal" never match internal
+> pages. I wonder whether this bug could be solved by making that part of
+> the definition of a pagespec, rather than a risky optimization
+> like it is now? That seems strange, though - having this special case
+> would make pagespecs significantly harder to understand. --[[smcv]]
safely supported by ikiwiki. There are [several differences between HTML4 and
HTML5](http://www.w3.org/TR/html5-diff/).
+[[!template id=gitbranch branch=hendry/html5 author="[[Kai_Hendry|hendry]]"]]
+
* [HTML5 branch](http://git.webconverger.org/?p=ikiwiki;h=refs/heads/html5)
* [ikiwiki instance with HTML5 templates](http://natalian.org)
* [HTML5 outliner tool](http://gsnedders.html5.org/outliner/) -- to check you have the structure of your markup correct
>>>> Thanks for pointing out the problem. I guess this patch should solve it.
>>>> --[[harishcm]]
+>>>>> Well, I suppose that's certainly a minimal patch for this bug :-)
+>>>>> I'm not the IkiWiki maintainer, but if I was, I'd apply it, so I've put
+>>>>> it in a git branch for Joey's convenience. Joey, Jon: any opinion?
+>>>>>
+>>>>> If you want to be credited for this patch under a name other than
+>>>>> "harishcm" (e.g. your real name), let me know and I'll amend the branch.
+>>>>> (Or, make a git branch of your own and replace the reference just below,
+>>>>> if you prefer.) --[[smcv]]
+
+>>>>>> The current arrangement looks fine to me. Thanks. --[[harishcm]]
+
+[[!template id=gitbranch author="[[harishcm]]" branch=smcv/ready/harishcm-map-fix]]
+
Patch:
--- /usr/local/share/perl/5.8.8/IkiWiki/Plugin/map.pm
* [[jonas|JonasSmedegaard]] `git://source.jones.dk/ikiwiki-upstream`
* [[arpitjain]] `git://github.com/arpitjain11/ikiwiki.git`
* [[chrysn]] `git://github.com/github076986099/ikiwiki.git`
-* [[kjikaqawej]] `git://github.com/kjikaqawej/ikiwiki-simon.git`
+* [[simonraven]] `git://github.com/kjikaqawej/ikiwiki-simon.git`
## branches
\[[!pagestats style="table"]]
+The optional `among` parameter limits counting to pages that match a
+[[ikiwiki/PageSpec]]. For instance, to display a cloud of tags used on blog
+entries, you could use:
+
+ \[[!pagestats pages="tags/*" among="blog/posts/*"]]
+
+or to display a cloud of tags related to Linux, you could use:
+
+ \[[!pagestats pages="tags/* and not tags/linux" among="tagged(linux)"]]
+
[[!meta robots="noindex, follow"]]
ikiwiki supports adding "History" links to the top of pages to browse the
-revison history of a page. This is enabled by the `historyurl` setting,
+revision history of a page. This is enabled by the `historyurl` setting,
which is used to specify the URL to a web interface such as [[ViewVC]]
(for Subversion) or [[Gitweb]]. In that url, "\[[file]]" is replaced with
the name of the file to view.
-The [[plugins/repolist]] plugin can suppliment this information with
+The [[plugins/repolist]] plugin can supplement this information with
urls to the underlying repository of the wiki.
Many plugins need to generate html links and add them to a page. This is
done by using the `htmllink` function. The usual way to call
-`htmlllink` is:
+`htmllink` is:
htmllink($page, $page, $link)
Passed a message, user, and ip address. Should commit all staged changes.
Returns undef on success, and an error message on failure.
-Changes can be staged by calls to `rcs_add, `rcs_remove`, and
+Changes can be staged by calls to `rcs_add`, `rcs_remove`, and
`rcs_rename`.
#### `rcs_add($)`
> Yes, ikiwiki does expect you to use your revision control system to check
> in changes. Otherwise, recentchanges cannot work right, since it uses the
> commit history from your revision control system. --[[Joey]]
+
+-----
+
+I'm working on an [[rcs]] plugin for CVS, adapted from `svn.pm`, in order to integrate ikiwiki at sites where that's all they've got. What's working so far: web commit (post-commit hook and all), diff, add (under certain conditions), and remove. What's not working: with rcs_add(), iff any of the new page's parent dirs aren't already under CVS control and the post-commit hook is enabled, the browser and ikiwiki stall for several seconds trying to add it, then time out. (If I kill ikiwiki when this is happening, it cvs adds the topmost parent that needed adding; if I wait for timeout, it doesn't. I think.) If I disable the post-commit hook and do the same kind of thing, the page is created and saved.
+
+In case you're lucky enough not to know, cvs adds on directories are weird -- they operate immediately against the repository, unlike file adds:
+
+ $ cvs add randomdir
+ Directory /Users/schmonz/Documents/cvswiki/repository/ikiwiki/randomdir added to the repository
+
+I was able to work out that when I'm seeing this page save misbehavior, my plugin is somewhere inside `system("cvs", "-Q", "add", "$file")`, which was never returning. If I changed it to anything other than cvs it iterated correctly over all the parent dirs which needed to be added to CVS, in the proper order. (cvs add isn't recursive, sadly.)
+
+Can you offer an educated guess what's going wrong here? --[[Schmonz]]
+
+> Got `rcs_recentchanges` working, believe it or not, thanks to [cvsps](http://www.cobite.com/cvsps/). If I can figure out this interaction between the post-commit hook and `cvs add` on directories, the CVS plugin is mostly done. Could it be a locking issue? Where should I be looking? Any suggestions appreciated. --[[Schmonz]]
</TMPL_LOOP><TMPL_VAR TITLE></h1>
This is what I do on my site for example. -- [[Jon]]
+
+> You don't actually need to fork the whole directory, "only" `page.tmpl` -
+> put `templatedir => "/foo/templates"` in your setup file, copy `page.tmpl`
+> to that directory, and modify it there. IkiWiki will look in `templatedir`
+> first, then fall back to its default templates if any are missing from
+> `templatedir`.
+>
+> (Admittedly, `page.tmpl` is the hardest to maintain a fork of, because it
+> tends to change whenever a new plugin is added...) --[[smcv]]
> Not that I'm opposed to the idea of a plugin that adds a Raw link
> --[[Joey]]
+>> In [[todo/source_link]], Will does this via the CGI instead of delegating
+>> to gitweb/etc. I think Will's patch is a good approach, and have improved
+>> on it a bit in a git branch.
+
[[!tag wishlist]]
>
> IMHO, what you really want is [[Moving_pages]]. :-) --[[Joey]]
+>> This sounds like WONTFIX to me? --[[smcv]]
+
[[!tag wishlist]]
> Nice idea, I'll try to find time to add a plugin doing this. --[[Joey]]
+>> [[done]] some time ago, as the [[plugins/404]] plugin --[[smcv]]
+
[[wishlist]]
srcdir. This would allow the admin to review them, and manually
add/delete them before they bloat history.
+> I'd be inclined to implement that one by writing them to a nominated
+> underlay, I think, rather than having them in the srcdir but not in
+> the VCS. My [[plugins/contrib/album]] plugin could benefit from this
+> functionality, although in that case the photos should probably just
+> stay in the underlay forever (I already use an underlay on my own
+> websites for photos and software releases, which are too big to want
+> them in the VCS permanently.) --[[smcv]]
+
[[!tag wishlist]]
[[!tag patch patch/core]]
-[[!template id=gitbranch branch=smcv/among author="[[smcv]]"]]
+[[!template id=gitbranch branch=smcv/ready/among author="[[smcv]]"]]
IkiWiki::backlinks returns a form of $backlinks{$page} that has undergone a
lossy transformation (to get it in the form that page templates want), making
(which returns the keys of $backlinks{$page}, and might be suitable for
exporting) and IkiWiki::backlinks (which calls backlink_pages, then performs
the same lossy transformation as before on the result).
+
+[[done]] --[[Joey]]
> like to have traditional `inline` functionality too. This would work great if there were a way to change the `do`
> parameter in the `blogpost` template's form; if I could change it to `datedblog` instead of `blog` then I could hook
> my datedblog module in nicely, without having to override anything. What would be the right way to do that? --[[neale]]
+
+> This is basically the same request as
+> [[todo/inline_postform_autotitles]]. --[[smcv]]
--- /dev/null
+[[!template id=gitbranch branch=smcv/gitignore author="[[smcv]]"]]
+[[!tag patch]]
+
+The recent merge of the po branch didn't come with a .gitignore.
+It eventually annoyed me enough to fix it :-) --[[smcv]]
+
+[[done]]
showing page locations on a map (Google Map, OpenStreetMap, etc). -- [[users/vibrog]]
[[!tag wishlist]]
+
+> [[!cpan Geo::Coordinates::UTM]] would probably be useful. --[[smcv]]
+[[!template id=gitbranch branch=smcv/ready/inline-pagenames author="[[smcv]]"]]
+
A [[!taglink patch]] in my git repository (the inline-pagenames branch) adds
the following parameter to the [[ikiwiki/directive/inline]] directive:
the second patch is actually a one-liner, filtering the title through strftime.
+> Something similar was requested in [[todo/more_customisable_titlepage_function]],
+> in which [[Joey]] outlined a similar solution.
+>
+> What's your use-case for not prompting for the title at all? I can see
+> [[madduck]]'s requirement for the title he typed in (say, "foo")
+> being transformed into 2009/07/26/foo or something (I name blog posts
+> like that myself), but I can't quite see the use for *entirely* automatic
+> titles.
+>
+> However, if that's really what you want, I suspect your code could be
+> extended so it also solves madduck's second request on
+> [[todo/more_customisable_titlepage_function]].
+>
+> --[[smcv]]
+
### potential user interaction issues
this has two side effects which have to be considered: first, the empty page
I imagine two things: a lookup hash and a template.
-Since `IkiWiki::titlepage` basically translates characters, it would be cool to be able to define a lookup hash in the configuration, which would be consulted before falling back to the generic `__xx__` `ord()` representation of a letter. For instance, in German, I might prefer to have 'Ã\83¤' become 'ae' instead of something illegible.
+Since `IkiWiki::titlepage` basically translates characters, it would be cool to be able to define a lookup hash in the configuration, which would be consulted before falling back to the generic `__xx__` `ord()` representation of a letter. For instance, in German, I might prefer to have 'ä' become 'ae' instead of something illegible.
+
+> This is [[todo/unaccent_url_instead_of_encoding]]. --[[smcv]]
Second, maybe a template could be honoured. The template could have a slot `%s` where the calculated title goes, and it could contain `strftime` symbols as well as variables, which get interpolated on use.
-- [[madduck]]
+> This somewhat resembles [[todo/inline_postform_autotitles]].
+> Another way to do this, suggested in that todo, would be to
+> pre-fill the title field with YYYY/MM/DD/ using Javascript.
+> --[[smcv]]
+
I don't think that changing titlepage is a good idea, there are
compatability problems.
confuse the user. The title could be passed on in a hidden field, and
prepended to the page when it's saved..
+--[[Joey]]
+
+> I'll pass on these comments to the two similar todo items. --[[smcv]]
+
[[wishlist]]
logical first step towards doing comment-like things with inlined pages).
-- [[Jon]]
+
+> Perhaps what we need is a `postform` plugin/directive that inline depends
+> on (automatically enables); its preprocess method could automatically be
+> invoked from preprocess_inline when needed. --[[smcv]]
[[!tag patch plugins/pagestats]]
-[[!template id=gitbranch branch=smcv/among author="[[smcv]]"]]
+[[!template id=gitbranch branch=smcv/ready/among author="[[smcv]]"]]
My `among` branch fixes [[todo/backlinks_result_is_lossy]], then uses that
to provide pagestats for links from a subset of pages. From the docs included
archive="yes" quick="yes" reverse="yes" timeformat="%x"]]
--[[smcv]]
+
+> [[merged|done]] thanks --[[Joey]]
>
> --[[Joey]]
-[[!template id=gitbranch branch=smcv/optimize-depends author="[[smcv]]"]]
+[[!template id=gitbranch branch=smcv/ready/optimize-depends author="[[smcv]]"]]
>> I've been looking at optimizing ikiwiki for a site using
>> [[plugins/contrib/album]] (which produces a lot of pages) and it seems
>>>> I haven't actually deleted it), because the "or" operation is now done in
>>>> the Perl code, rather than by merging pagespecs and translating. --[[smcv]]
+[[!template id=gitbranch branch=smcv/ready/remove-pagespec-merge author="[[smcv]]"]]
+
+>>>>> I've now added a patch to the end of that branch that deletes
+>>>>> `pagespec_merge` almost entirely (we do need to keep a copy around, in
+>>>>> ikiwiki-transition, but that copy doesn't have to be optimal or support
+>>>>> future features like [[tracking_bugs_with_dependencies]]). --[[smcv]]
+
[[!tag wishlist patch patch/core]]
> by loading the index with IkiWiki::loadindex, like [[plugins/goto]] does?
> --[[smcv]]
+[[!template id=gitbranch branch=smcv/ready/getsource
+ author="[[Will]]/[[smcv]]"]]
+
+>> I've applied the patch below in a git branch, fixed my earlier criticism,
+>> and also fixed a couple of other issues I noticed:
+>>
+>> * missing pages could be presented better as a real 404 page
+>> * the default Content-type should probably be UTF-8 since the rest of
+>> IkiWiki tends to assume that
+>> * emitting attachments (images, etc.) as text/plain isn't going to work :-)
+>>
+>> Any opinions on my branch? I think it's ready for merge, if Joey approves.
+>>
+>> --[[smcv]]
+
+>>> I need a copyright&license statement, so debian/copyright can be updated for
+>>> the plugin, before I can merge this. Otherwise ready. --[[Joey]]
+
+>>> That looks like a nice set of fixes. One more that might be worthwhile: instead of reading the page source into a var, and then writing it out later, it might be nice to just
+>>> `print readfile(srcfile(pagesources{$page}));` at the appropriate point. -- [[Will]]
+
+>>>> OK, I've committed that. --[[smcv]]
+
----
diff --git a/templates/page.tmpl b/templates/page.tmpl
>>>>> then the last definition (baz) takes precedence.
>>>>> In the process of writing this I think I've come up with a way to change this back the way it was, still using closures. -- [[Will]]
+>>> Alternatively, my [[remove-pagespec-merge|should_optimise_pagespecs]]
+>>> branch solves this, in a Gordian knot sort of way :-) --[[smcv]]
+
>> Secondly, it seems that there are two types of dependency, and ikiwiki
>> currently only handles one of them. The first type is "Rebuild this
>> page when any of these other pages changes" - ikiwiki handles this.
So I made a patch which unaccent chars: <http://users.itk.ppke.hu/~cstamas/code/ikiwiki/unaccentpagetitlenames/>
This is a one liner change, but requires a bit of reordering in the code.
-[[cstamas]]
+--[[cstamas]]
+
+> This was previously requested in [[todo/more_customisable_titlepage_function]],
+> in which [[Joey]] said "I don't think that changing titlepage is a good idea,
+> there are compatability problems".
+>
+> The problem is that altering titlepage changes the meaning of your wiki,
+> by resolving all wiki links to different page names. That means that:
+>
+> * unaccenting can't be automatic, it has to be a configuration option
+> (so you don't accidentally get different behaviour by installing
+> Text::Unaccent)
+> * upgrading Text::Unaccent becomes risky, as I doubt it guarantees to
+> have stable rules for how to transliterate into ASCII!
+>
+> --[[smcv]]
[[!tag wishlist patch patch/core]]
-New ikiwiki site at my personal site under /ikiwiki/ . This might move to /wiki/ or be on wiki.k.o depending on if I can import my MediaWiki stuff to it.
+## personal/site info
+
+New ikiwiki site at my web site, blog, kisikew.org home site, for indigenews, and our indigenous-centric wiki (mostly East Coast/Woodlands area). Mediawiki stuff was imported successfully (as noted on this web site).
+
+## ikiwiki branch at github
+
+Maintain my own branch, partly to learn about VCS, git, ikiwiki, Debian packaging, and Perl. I don't recommend anyone pull from it, as I use third-party plugins included on this site that people may not want in a default installation of ikiwiki. This is why I don't push to Joey's -- so it's nothing personal, I just don't want to mess things up for other people, from my mistakes and stumbles.
-Thought I'd try it out again and it grew on me.
projects / ikiwiki.git / commitdiff