Merge commit 'upstream/master' into pub/po
commit
df6f6a1d53
|
@ -18,6 +18,8 @@ ikiwiki (3.13) UNRELEASED; urgency=low
|
|||
* Allow curly braces to be used in pagespecs, and avoid a whole class
|
||||
of potential security problems, by avoiding performing any string
|
||||
interpolation on user-supplied data when translating pagespecs.
|
||||
* ikiwiki-transition: Allow setup files to be passed to all subcommands
|
||||
that need a srcdir.
|
||||
|
||||
-- Joey Hess <joeyh@debian.org> Wed, 06 May 2009 20:45:44 -0400
|
||||
|
||||
|
|
|
@ -127,3 +127,27 @@ dubious
|
|||
</pre>
|
||||
|
||||
>>>> I get this over and over... I haven't touched that AFAICT, at all. --[[simonraven]]
|
||||
|
||||
>>>>> Take a look at your `/usr/bin/ikiwiki`. The first
|
||||
>>>>> line should not contain -T. If it does, remove it,
|
||||
>>>>> and maybe try to work out or give details about how
|
||||
>>>>> you installed ikiwiki and why it got the -T in there,
|
||||
>>>>> which certianly doesn't happen by default when ikiwiki
|
||||
>>>>> is installed by the Makefile.PL or by any package I know of.
|
||||
>>>>> (If there's
|
||||
>>>>> no -T, then something *really* weird is going on..)
|
||||
>>>>> --[[Joey]]
|
||||
|
||||
>>>>>> nope, no -T in the hashbang line at all. Haven't added any;
|
||||
>>>>>> only thing I did there was change `use lib` to `/usr/share/perl5`,
|
||||
>>>>>> otherwise I'd get bogus errors about CGI::Cookie_al or some such thing.
|
||||
>>>>>>
|
||||
>>>>>> How I installed it was in non-public directories in various sites, then
|
||||
>>>>>> make it publish stuff to a public dir in the relevant site. Or do you
|
||||
>>>>>> mean installed, as in the whole thing? From a .deb I made based on the git tree, with `git-buildpackage`.
|
||||
>>>>>>
|
||||
>>>>>> This issue is recent, after a `git pull` IIRC. It has never happened before. It's also puzzling me.
|
||||
>>>>>>
|
||||
>>>>>> You can check it out for yourself by pulling my fork of this, at github or my local repo.
|
||||
>>>>>> github will probably be faster for you: git://github.com/kjikaqawej/ikiwiki-simon.git --[[simonraven]]
|
||||
|
||||
|
|
|
@ -272,3 +272,8 @@ So, looking at your meta branch: --[[Joey]]
|
|||
>>> it in a way that leaves room for #2.
|
||||
>>>
|
||||
>>> --[[intrigeri]]
|
||||
>>>
|
||||
>>>> I agree, we should concentrate on getting just enough functionality
|
||||
>>>> for the po plugin, because I want to merge the po plugin soon.
|
||||
>>>> If #2 gets tackled later, we will certianly have all kinds of fun.
|
||||
>>>> no matter what is done for the po plugin. --[[Joey]]
|
||||
|
|
|
@ -44,14 +44,14 @@ Moves values that used to be admin preferences into the setup file.
|
|||
Note that all comments and any unusual stuff like perl code in the setup
|
||||
file will be lost, as it is entirely rewritten by the move.
|
||||
|
||||
# indexdb srcdir
|
||||
# indexdb your.setup|srcdir
|
||||
|
||||
The `indexdb` mode handles converting a plain text `.ikiwiki/index` file to
|
||||
a binary `.ikiwiki/indexdb`. You do not normally need to run
|
||||
`ikiwiki-transition indexdb`; ikiwiki will automatically run it as
|
||||
necessary.
|
||||
|
||||
# hashpassword srcdir
|
||||
# hashpassword your.setup|srcdir
|
||||
|
||||
The `hashpassword` mode forces any plaintext passwords stored in the
|
||||
`.ikiwiki/userdb` file to be replaced with password hashes. (The
|
||||
|
@ -61,7 +61,7 @@ If this is not done explicitly, a user's plaintext password will be
|
|||
automatically converted to a hash when a user logs in for the first time
|
||||
after upgrade to ikiwiki 2.48.
|
||||
|
||||
# deduplinks srcdir
|
||||
# deduplinks your.setup|srcdir
|
||||
|
||||
In the past, bugs in ikiwiki have allowed duplicate link information
|
||||
to be stored in its indexdb. This mode removes such duplicate information,
|
||||
|
|
|
@ -372,6 +372,18 @@ daring a timid "please pull"... or rather, please review again :)
|
|||
>> should appear on the current page. That's why I'm testing
|
||||
>> `$template->param('discussionlink')`.
|
||||
>>
|
||||
>>> Maybe I was really wondering why it says it could lead to a broken
|
||||
>>> link if the cgiurl is disabled. I think I see why now: Discussionlink
|
||||
>>> will be set to a link to an existing disucssion page, even if cgi is
|
||||
>>> disabled -- but there's no guarantee of a translated discussion page
|
||||
>>> existing in that case. *However*, htmllink actually checks
|
||||
>>> for this case, and will avoid generating a broken link so AFAICS, the
|
||||
>>> comment is actually innacurate.. what will really happen in this case
|
||||
>>> is discussionlink will be set to a non-link translation of
|
||||
>>> "discussion". Also, I consider `$config{cgi}` and `%links` (etc)
|
||||
>>> documented parts of the plugin interface, which won't change; po could
|
||||
>>> rely on them to avoid this minor problem. --[[Joey]]
|
||||
>
|
||||
> * Is there any real reason not to allow removing a translation?
|
||||
> I'm imagining a spammy translation, which an admin might not
|
||||
> be able to fix, but could remove.
|
||||
|
@ -383,6 +395,11 @@ daring a timid "please pull"... or rather, please review again :)
|
|||
>> delete the spammy `.po` file by hand using whatever VCS is in use.
|
||||
>> Not that I'd really care, but I am slightly in favour of the way
|
||||
>> it currently works.
|
||||
>>
|
||||
>>> That would definitly be confusing. It sounds to me like if we end up
|
||||
>>> needing to allow web-based deletion of spammy translations, it will
|
||||
>>> need improvements to the deletion UI to de-confuse that. It's fine to
|
||||
>>> put that off until needed --[[Joey]]
|
||||
>>
|
||||
> * Re the meta title escaping issue worked around by `change`.
|
||||
> I suppose this does not only affect meta, but other things
|
||||
|
@ -404,3 +421,5 @@ daring a timid "please pull"... or rather, please review again :)
|
|||
>> I'll think about it soon.
|
||||
>>
|
||||
>> --[[intrigeri]]
|
||||
>>
|
||||
>>> Did you get a chance to? --[[Joey]]
|
||||
|
|
|
@ -18,3 +18,22 @@ This is not just an ugly workaround. The availability of this feature has some r
|
|||
So in a sense, in some or most cases, it would indeed be cleaner to "store" the definition of a class of pages referred to in complex pagespecs as a separate object. And the most natural representation for this definition of a class of pages (adhering to the principle of wiki that what you mean is entered/stored in its most natural representation, not through some hidden disconnected code) is making a page with an inline/map/or the like, so that at the same time you store the definition and you see what it is (the set of pages is displayed to you).
|
||||
|
||||
I would actually use it in my current "project" in ikiwiki: I actually edit a set of materials as a set of subpages `new_stuff/*`, and I also want to have a combined view of all of them (made through inline), and at another page, I want to list what has been linked to in `new_stuff/*` and what hasn't been linked to.--Ivan Z.
|
||||
|
||||
> I see where you're coming from, but let's think about
|
||||
> immplementation efficiency for a second.
|
||||
>
|
||||
> In order for inline inheritlinks=yes to work,
|
||||
> the inline directive would need to be processed
|
||||
> during the scan pass.
|
||||
>
|
||||
> When the directive was processed there, it would need
|
||||
> to determine which pages get inlined (itself a moderatly
|
||||
> expensive operation), and then determine which pages
|
||||
> each of them link to. Since the scan pass is unordered,
|
||||
> those pages may not have themselves been scanned yet.
|
||||
> So to tell what they link to, inline would have to load
|
||||
> each of them, and scan them.
|
||||
>
|
||||
> So there's the potential for this to slow
|
||||
> down a wiki build by about a factor of 2.
|
||||
> --[[Joey]]
|
||||
|
|
|
@ -7,3 +7,31 @@ And in general, it would be quite useful to be able to distinguish different kin
|
|||
It could distinguish the links by the `rel=` attribute. ([[Tags already receive a special rel-class|todo/rel_attribute_for_links]].) This means there is a general need for a syntax to specify user-defined rel-classes on wikilink (then bug deps would simply use their special rel-class, either directly, or through a special directive like `\[[!depends ]]`), and to refer to them in pagespecs (in forward and backward direction).
|
||||
|
||||
Besides pagespecs, the `rel=` attribute could be used for styles. --Ivan Z.
|
||||
|
||||
> FWIW, the `add_link` function introduced in a recent
|
||||
> release adds an abstraction that could be used to get
|
||||
> part of the way there to storing data about different types of
|
||||
> links. That function could easily be extended to take an optional
|
||||
> third parameter specifying the link type.
|
||||
>
|
||||
> Then there's the question of how to store and access the data. `%links`
|
||||
> does not offer a good way to add additional information about links.
|
||||
> Now, we could toss `%links` entirely and switch to an accessor function,
|
||||
> but let's think about not doing that..
|
||||
>
|
||||
> The data that seems to be needed is basically a deep hash, so
|
||||
> one could check `$linktype{$page}{tag}{$link}` to see if
|
||||
> the page contains a link of the given type. (Note that pages could
|
||||
> contain links that were duplicates except for their types.)
|
||||
>
|
||||
> There would be some data duplication, unfortuantly, but if `%linktype`
|
||||
> is not populated for regular wikilinks, it would at least be limited to
|
||||
> tags and other unusual link types, so not too bad.
|
||||
>
|
||||
> `%linktype` could be stored in `%pagestate`.. if so
|
||||
> the actual use might look like `$pagestate{$page}{linktype}{tag}{$link}`.
|
||||
> That could be implemented by the tag plugin right now
|
||||
> with no core changes. (BTW, then I originally wrote tag, pagestate
|
||||
> was not available, which is why I didn't make it differentiate from
|
||||
> normal links.) Might be better to go ahead and add the variable to
|
||||
> core though. --[[Joey]]
|
||||
|
|
|
@ -6,6 +6,7 @@ use IkiWiki::Setup::Standard {
|
|||
srcdir => "doc",
|
||||
destdir => "html",
|
||||
templatedir => "templates",
|
||||
underlaydirbase => "underlays",
|
||||
underlaydir => "underlays/basewiki",
|
||||
discussion => 0,
|
||||
exclude => qr/\/discussion|bugs\/*|todo\/*/,
|
||||
|
|
|
@ -42,16 +42,8 @@ sub handle_directive {
|
|||
}
|
||||
|
||||
sub prefix_directives {
|
||||
my $setup=shift;
|
||||
if (! defined $setup) {
|
||||
usage();
|
||||
}
|
||||
loadsetup(shift);
|
||||
|
||||
require IkiWiki::Setup;
|
||||
require IkiWiki::Plugin::aggregate;
|
||||
|
||||
%config = IkiWiki::defaultconfig();
|
||||
IkiWiki::Setup::load($setup);
|
||||
IkiWiki::loadplugins();
|
||||
IkiWiki::checkconfig();
|
||||
IkiWiki::loadindex();
|
||||
|
@ -114,31 +106,16 @@ sub hashpassword {
|
|||
}
|
||||
|
||||
sub aggregateinternal {
|
||||
my $setup=shift;
|
||||
if (! defined $setup) {
|
||||
usage();
|
||||
}
|
||||
|
||||
require IkiWiki::Setup;
|
||||
loadsetup(shift);
|
||||
require IkiWiki::Plugin::aggregate;
|
||||
|
||||
%config = IkiWiki::defaultconfig();
|
||||
IkiWiki::Setup::load($setup);
|
||||
IkiWiki::checkconfig();
|
||||
|
||||
IkiWiki::Plugin::aggregate::migrate_to_internal();
|
||||
}
|
||||
|
||||
sub setupformat {
|
||||
my $setup=shift;
|
||||
if (! defined $setup) {
|
||||
usage();
|
||||
}
|
||||
|
||||
require IkiWiki::Setup;
|
||||
|
||||
%config = IkiWiki::defaultconfig();
|
||||
IkiWiki::Setup::load($setup);
|
||||
loadsetup($setup);
|
||||
IkiWiki::checkconfig();
|
||||
|
||||
# unpack old-format wrappers setting into new fields
|
||||
|
@ -175,14 +152,8 @@ sub setupformat {
|
|||
|
||||
sub moveprefs {
|
||||
my $setup=shift;
|
||||
if (! defined $setup) {
|
||||
usage();
|
||||
}
|
||||
|
||||
require IkiWiki::Setup;
|
||||
|
||||
%config = IkiWiki::defaultconfig();
|
||||
IkiWiki::Setup::load($setup);
|
||||
loadsetup($setup);
|
||||
IkiWiki::checkconfig();
|
||||
|
||||
eval q{use IkiWiki::UserInfo};
|
||||
|
@ -224,22 +195,38 @@ sub deduplinks {
|
|||
}
|
||||
|
||||
sub setstatedir {
|
||||
my $dir=shift;
|
||||
my $dirorsetup=shift;
|
||||
|
||||
if (! defined $dir) {
|
||||
if (! defined $dirorsetup) {
|
||||
usage();
|
||||
}
|
||||
|
||||
if (! -d $dir) {
|
||||
error("ikiwiki-transition: $dir does not exist");
|
||||
if (-d $dirorsetup) {
|
||||
$config{wikistatedir}=$dirorsetup."/.ikiwiki";
|
||||
}
|
||||
elsif (-f $dirorsetup) {
|
||||
loadsetup($dirorsetup);
|
||||
}
|
||||
else {
|
||||
error("ikiwiki-transition: $dirorsetup does not exist");
|
||||
}
|
||||
|
||||
$config{wikistatedir}=$dir."/.ikiwiki";
|
||||
|
||||
if (! -d $config{wikistatedir}) {
|
||||
error("ikiwiki-transition: $config{wikistatedir} does not exist");
|
||||
}
|
||||
}
|
||||
|
||||
sub loadsetup {
|
||||
my $setup=shift;
|
||||
if (! defined $setup) {
|
||||
usage();
|
||||
}
|
||||
|
||||
require IkiWiki::Setup;
|
||||
|
||||
%config = IkiWiki::defaultconfig();
|
||||
IkiWiki::Setup::load($setup);
|
||||
}
|
||||
|
||||
sub usage {
|
||||
print STDERR "Usage: ikiwiki-transition type ...\n";
|
||||
|
@ -248,9 +235,9 @@ sub usage {
|
|||
print STDERR "\taggregateinternal setupfile\n";
|
||||
print STDERR "\tsetupformat setupfile\n";
|
||||
print STDERR "\tmoveprefs setupfile\n";
|
||||
print STDERR "\thashpassword srcdir\n";
|
||||
print STDERR "\tindexdb srcdir\n";
|
||||
print STDERR "\tdeduplinks srcdir\n";
|
||||
print STDERR "\thashpassword setupfile|srcdir\n";
|
||||
print STDERR "\tindexdb setupfile|srcdir\n";
|
||||
print STDERR "\tdeduplinks setupfile|srcdir\n";
|
||||
exit 1;
|
||||
}
|
||||
|
||||
|
|
Loading…
Reference in New Issue