Merge branch 'master' of ssh://git.ikiwiki.info/srv/git/ikiwiki.info
Joey Hess
commit
691d7ff827
|
|
@ -6,55 +6,3 @@ If sandbox/page.mdwn has been generated and sandbox/sidebar.mdwn is created, the
|
|||
# adding a new sidebar page. So adding such a page
|
||||
# currently requires a wiki rebuild.
|
||||
add_depends($page, $sidebar_page);
|
||||
|
||||
----
|
||||
Below is a patch for the bug. It's inspired by trying to solve [[todo/Post-compilation inclusion of the sidebar]].
|
||||
What do you think about it? I have a concern though. If a sidebar is removed, it takes two refreshes to update
|
||||
the affected pages. Is this a feature or a bug? --[[harishcm]]
|
||||
|
||||
--- sidebar.pm.orig 2009-11-21 17:40:02.000000000 +0800
|
||||
+++ sidebar_bugfix.pm 2009-11-21 18:16:11.000000000 +0800
|
||||
@@ -10,6 +10,7 @@
|
||||
|
||||
sub import {
|
||||
hook(type => "getsetup", id => "sidebar", call => \&getsetup);
|
||||
+ hook(type => "needsbuild", id => "sidebar", call => \&needsbuild);
|
||||
hook(type => "pagetemplate", id => "sidebar", call => \&pagetemplate);
|
||||
}
|
||||
|
||||
@@ -21,6 +22,22 @@
|
||||
},
|
||||
}
|
||||
|
||||
+sub needsbuild (@) {
|
||||
+ my $needsbuild=shift;
|
||||
+
|
||||
+ # Determine every pages' sidebar page
|
||||
+ foreach my $page (keys %pagesources) {
|
||||
+ my $sidebar_page='';
|
||||
+ $sidebar_page=bestlink($page, "sidebar");
|
||||
+
|
||||
+ # If a page's sidebar has changed, force rebuild
|
||||
+ if (!exists $pagestate{$page}{sidebar}{sidebar_page} || $pagestate{$page}{sidebar}{sidebar_page} ne $sidebar_page) {
|
||||
+ $pagestate{$page}{sidebar}{sidebar_page} = $sidebar_page;
|
||||
+ push @$needsbuild, $pagesources{$page};
|
||||
+ }
|
||||
+ }
|
||||
+}
|
||||
+
|
||||
sub sidebar_content ($) {
|
||||
my $page=shift;
|
||||
|
||||
@@ -29,9 +46,9 @@
|
||||
my $sidebar_type=pagetype($sidebar_file);
|
||||
|
||||
if (defined $sidebar_type) {
|
||||
- # FIXME: This isn't quite right; it won't take into account
|
||||
- # adding a new sidebar page. So adding such a page
|
||||
- # currently requires a wiki rebuild.
|
||||
+ # Record current sidebar page for rechecking bestlink
|
||||
+ # during wiki refresh. Also add depends on the sidebar page.
|
||||
+ $pagestate{$page}{sidebar}{sidebar_page}=$sidebar_page;
|
||||
add_depends($page, $sidebar_page);
|
||||
|
||||
my $content=readfile(srcfile($sidebar_file));
|
||||
|
|
|
|||
|
|
@ -3,3 +3,5 @@ I'm using firefox-3.0.8-alt0.M41.1 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1
|
|||
Only explicitly pressing "reload" helps.
|
||||
|
||||
Is it a bug? I haven't been noticing such problems usually on other sites. --Ivan Z.
|
||||
|
||||
This remains to be true now, with Epiphany 2.26.3 (Mozilla/5.0 (X11; U; Linux i686; en; rv:1.9.1.4pre) Gecko/20080528 Epiphany/2.22 Firefox/3.5). --Ivan Z.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,17 @@
|
|||
Looking at the discussion about [[todo/structured_page_data]], it looks a bit like folks are bogged down in figuring out what *markup* to use for structured page data, something I doubt that people will really agree on. And thus, little progress is made.
|
||||
|
||||
I propose that, rather than worry about what the data looks like, that we take a similar approach
|
||||
to the way Revision Control Systems are used in ikiwiki: a front-end + back-end approach.
|
||||
The front-end would be a common interface, where queries are made about the structured data,
|
||||
and there would be any number of back-ends, which could use whatever markup or format that they desired.
|
||||
|
||||
To that purpose, I've written the [[plugins/contrib/field]] plugin for a possible front-end.
|
||||
I called it "field" because each page could be considered a "record" where one could request the values of "fields" of that record.
|
||||
The idea is that back-end plugins would register functions which can be called when the value of a field is desired.
|
||||
|
||||
This is gone into in more depth on the plugin page itself, but I would appreciate feedback and improvements on the approach.
|
||||
I think it could be really powerful and useful, especially if it becomes part of ikiwiki proper.
|
||||
|
||||
--[[KathrynAndersen]]
|
||||
|
||||
> It looks like an interesting idea. I don't have time right now to look at it in depth, but it looks interesting. -- [[Will]]
|
||||
|
|
@ -7,3 +7,11 @@ but right now I have to have a look at the content, which I don't like so much.
|
|||
Is there a better hook to use for this? I need to transform the input before preprocessing.
|
||||
|
||||
[[DavidBremner]]
|
||||
|
||||
>You can check the type of the page without having to look at the content of the page:
|
||||
|
||||
my $page_file=$pagesources{$page};
|
||||
my $page_type=pagetype($page_file);
|
||||
|
||||
>Then you can check whether `$page_type` is "tex".
|
||||
>--[[KathrynAndersen]]
|
||||
|
|
|
|||
|
|
@ -1,3 +1,9 @@
|
|||
## 3.20091017 news item removed?
|
||||
Hi! Why have you [removed](http://git.ikiwiki.info/?p=ikiwiki;a=blobdiff;f=doc/news/version_3.20091017.mdwn;h=0000000000000000000000000000000000000000;hp=aba830a82f881bd97d11fe644eb2c78b99c2258d;hb=9fdd9af2db2bd21e543fa0f5f4bfa85b56b8dd5c;hpb=b74dceb884a60f6f7be395378a009ee414726d0b) the item for
|
||||
3.20091017? Perhaps, it's an error, isn't it? The corresponding code AFAIU is still there. --Ivan Z.
|
||||
|
||||
> I always remove old news items when making a new release. The info is still there in the changelog if needed. --[[Joey]]
|
||||
|
||||
## Ikiwiki 3.12
|
||||
|
||||
Joey, what about news for Ikiwiki 3.12? The changelog says is has been released
|
||||
|
|
|
|||
|
|
@ -0,0 +1,97 @@
|
|||
[[!template id=plugin name=field author="[[rubykat]]"]]
|
||||
[[!toc]]
|
||||
## NAME
|
||||
|
||||
IkiWiki::Plugin::field - front-end for per-page record fields.
|
||||
|
||||
## SYNOPSIS
|
||||
|
||||
# activate the plugin
|
||||
add_plugins => [qw{goodstuff field ....}],
|
||||
|
||||
# simple registration
|
||||
field_register => [qw{meta}],
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
This plugin is meant to be used in conjunction with other plugins
|
||||
in order to provide a uniform interface to access per-page structured
|
||||
data, where each page is treated like a record, and the structured data
|
||||
are fields in that record. This can include the meta-data for that page,
|
||||
such as the page title.
|
||||
|
||||
Plugins can register a function which will return the value of a "field" for
|
||||
a given page. This can be used in three ways:
|
||||
|
||||
* In page templates; all registered fields will be passed to the page template in the "pagetemplate" processing.
|
||||
* In PageSpecs; the "field" function can be used to match the value of a field in a page.
|
||||
* By other plugins, using the field_get_value function, to get the value of a field for a page, and do with it what they will.
|
||||
|
||||
## OPTIONS
|
||||
|
||||
The following options can be set in the ikiwiki setup file.
|
||||
|
||||
**field_register**
|
||||
|
||||
A list of plugin-IDs to register. This assumes that the plugins in
|
||||
question store data in the %pagestatus hash using the ID of that plugin,
|
||||
and thus the field values are looked for there.
|
||||
|
||||
This is the simplest form of registration, but the advantage is that it
|
||||
doesn't require the plugin to be modified in order for it to be
|
||||
registered with the "field" plugin.
|
||||
|
||||
## PageSpec
|
||||
|
||||
The "field" PageSpec function can be used to match the value of a field for a page.
|
||||
|
||||
field(*name* *glob*)
|
||||
|
||||
For example:
|
||||
|
||||
field(bar Foo*) will match if the "bar" field starts with "Foo".
|
||||
|
||||
## FUNCTIONS
|
||||
|
||||
### field_register
|
||||
|
||||
field_register(id=>$id);
|
||||
|
||||
Register a plugin as having field data. The above form is the simplest, where the field value
|
||||
is looked up in the %pagestatus hash under the plugin-id.
|
||||
|
||||
Additional Options:
|
||||
|
||||
**call=>&myfunc**
|
||||
|
||||
A reference to a function to call rather than just looking up the value in the %pagestatus hash.
|
||||
It takes two arguments: the name of the field, and the name of the page. It is expected to return
|
||||
the value of that field, or undef if there is no field by that name.
|
||||
|
||||
sub myfunc ($$) {
|
||||
my $field = shift;
|
||||
my $page = shift;
|
||||
|
||||
...
|
||||
|
||||
return $value;
|
||||
}
|
||||
|
||||
**first=>1**
|
||||
|
||||
Set this to be called first in the sequence of calls looking for values. Since the first found
|
||||
value is the one which is returned, ordering is significant.
|
||||
|
||||
**last=>1**
|
||||
|
||||
Set this to be called last in the sequence of calls looking for values. Since the first found
|
||||
value is the one which is returned, ordering is significant.
|
||||
|
||||
### field_get_value($field, $page)
|
||||
|
||||
Returns the value of the field for that page, or undef if none is found.
|
||||
|
||||
## DOWNLOAD
|
||||
|
||||
* browse at GitHub: <http://github.com/rubykat/ikiplugins/blob/master/IkiWiki/Plugin/field.pm>
|
||||
* git repo at git://github.com/rubykat/ikiplugins.git
|
||||
|
|
@ -62,6 +62,7 @@ This **SandBox** is also a [[blog]]!
|
|||
|
||||
----
|
||||
|
||||
What about [relative urls](../setup/byhand)?
|
||||
|
||||
[[!toggleable id="foobar" text="""
|
||||
foo
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
This is an idea from [[JoshTriplett]]. --[[Joey]]
|
||||
|
||||
* See further discussion at [[forum/an_alternative_approach_to_structured_data]].
|
||||
|
||||
Some uses of ikiwiki, such as for a bug-tracking system (BTS), move a bit away from the wiki end
|
||||
of the spectrum, and toward storing structured data about a page or instead
|
||||
of a page.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,66 @@
|
|||
Can we please have a very brief HOWTO?
|
||||
|
||||
I have a Moin wiki in /var/www/wiki and want to create an IkIwiki clone of it in /var/www/ikiwiki backed by a git repos in /data/ikiwiki.
|
||||
|
||||
I tried:
|
||||
|
||||
mkdir /var/www/ikiwiki
|
||||
mkdir /data/ikiwiki
|
||||
PATH=.:/usr/lib/git-core:$PATH ./moin2iki /data/ikiwiki http://localhost/wiki
|
||||
|
||||
Help please!but this failed. (BTW, I don't usually put . in my PATH). The failure appears to be that the converter doesn't actually create an ikiwiki instance, but appears to want to update one:
|
||||
|
||||
fatal: ambiguous argument 'master': unknown revision or path not in the working tree.
|
||||
Use '--' to separate paths from revisions
|
||||
fatal: ambiguous argument 'master': unknown revision or path not in the working tree.
|
||||
Use '--' to separate paths from revisions
|
||||
fatal: Not a valid object name master
|
||||
Traceback (most recent call last):
|
||||
File "/home/peterc/src/moin2iki/git-map", line 125, in <module>
|
||||
if __name__ == "__main__": sys.exit(main(sys.argv[1:]))
|
||||
File "/home/peterc/src/moin2iki/git-map", line 117, in main
|
||||
print git_map_file('commit', new_head)
|
||||
File "/home/peterc/src/moin2iki/git-map", line 33, in git_map_file
|
||||
f(inproc.stdout, outproc.stdin, sha, arg)
|
||||
File "/home/peterc/src/moin2iki/git-map", line 64, in handle_commit
|
||||
string, tree = lines.pop(0).split()
|
||||
IndexError: pop from empty list
|
||||
|
||||
OK, so I created one:
|
||||
|
||||
ikiwiki --setup /etc/ikiwiki/auto.setup
|
||||
.....
|
||||
This process created several files and directories in my home directory:
|
||||
|
||||
wiki.git/
|
||||
public_html/wiki/
|
||||
wiki.setup
|
||||
.ikiwiki/
|
||||
|
||||
Following the instructions on the setup page, I did:
|
||||
mv wiki.git /data/ikiwiki
|
||||
( cd /data/ikiwiki; git clone -l wiki.git wiki; )
|
||||
mv .ikiwiki /data/ikiwiki/ikiwiki
|
||||
mv ~/public_html/wiki /var/ikiwiki/
|
||||
|
||||
then did again
|
||||
|
||||
PATH=.:/usr/lib/git-core:$PATH ./moin2iki /data/ikiwiki/wiki http://www/wiki
|
||||
|
||||
and saw no output, and no change to the filesystem.
|
||||
|
||||
I'm totally confused. It looks as though the script calls moin2git iff the target directory isn't there, but the script fails in interesting ways if it is.
|
||||
|
||||
The other thing I saw was:
|
||||
|
||||
2009-12-04 09:00:31,542 WARNING MoinMoin.log:139 using logging configuration read from built-in fallback in MoinMoin.log module!
|
||||
Traceback (most recent call last):
|
||||
File "./moin2git", line 128, in <module>
|
||||
if __name__ == '__main__': main(*sys.argv[1:])
|
||||
File "./moin2git", line 43, in main
|
||||
r = request.RequestCLI()
|
||||
AttributeError: 'module' object has no attribute 'RequestCLI'
|
||||
|
||||
Moin version is 1.8.5
|
||||
|
||||
Help please!
|
||||
Loading…
Reference in New Issue