* 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
</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]]
+
>>> 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]]
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
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,
>> 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.
>> 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
>> I'll think about it soon.
>>
>> --[[intrigeri]]
+>>
+>>> Did you get a chance to? --[[Joey]]
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]]
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]]
srcdir => "doc",
destdir => "html",
templatedir => "templates",
+ underlaydirbase => "underlays",
underlaydir => "underlays/basewiki",
discussion => 0,
exclude => qr/\/discussion|bugs\/*|todo\/*/,
}
sub prefix_directives {
- my $setup=shift;
- if (! defined $setup) {
- usage();
- }
-
- require IkiWiki::Setup;
- require IkiWiki::Plugin::aggregate;
+ loadsetup(shift);
- %config = IkiWiki::defaultconfig();
- IkiWiki::Setup::load($setup);
IkiWiki::loadplugins();
IkiWiki::checkconfig();
IkiWiki::loadindex();
}
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
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};
}
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";
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;
}
sipb-www / ikiwiki.git / commitdiff
