diff options
Diffstat (limited to 'doc/forum')
81 files changed, 2181 insertions, 17 deletions
diff --git a/doc/forum/Can_OpenID_users_be_adminusers__63__.mdwn b/doc/forum/Can_OpenID_users_be_adminusers__63__.mdwn index 7599e71e5..17c60c423 100644 --- a/doc/forum/Can_OpenID_users_be_adminusers__63__.mdwn +++ b/doc/forum/Can_OpenID_users_be_adminusers__63__.mdwn @@ -62,7 +62,7 @@ index 0bf100a..77b467a 100644 >>>> So you can see if the two usernames/openids match. If the end is "0", >>>> they don't match. If nothing is logged, you have not enabled the websetup plugin. ->>>> If the end if "1" you should see the "Wiki Setup" button, if not the +>>>> If the end if "1" you should see the "Setup" button, if not the >>>> problem is not in determining if you're an admin, but elsewhere.. >>>> --[[Joey]] diff --git a/doc/forum/Can__39__t_get_comments_plugin_working.mdwn b/doc/forum/Can__39__t_get_comments_plugin_working.mdwn new file mode 100644 index 000000000..06b7fdd84 --- /dev/null +++ b/doc/forum/Can__39__t_get_comments_plugin_working.mdwn @@ -0,0 +1,7 @@ +I feel like I must be missing something. + +My blog is based on Ikiwiki, and uses /yyyy/mm/dd/title/ for blog posts. Because I use the plugin that generates index pages for subdirectories, I have to use /????/??/??/* to identify posts and avoid missing the index pages for years, months and days. + +I've enabled the comments plugin, but no matter what I do, I can't seem to make the comment form appear on my posts. I've removed the entire site and have rebuilt. I've set the pagespec to /????/??/??/* and ./????/??/??/*, but neither seems to work. I don't see any output, or anything else to indicate that pages aren't working. + +Are there any other plugins that need to be enabled for this to work? I think I've locked things down such that anonymous users can't edit by enabling signinedit and setting a lock, but this may be blocking the ability to comment (though I don't recall seeing anything in the docs about needing additional plugins.) diff --git a/doc/forum/Cannot_write_to_commitlock.mdwn b/doc/forum/Cannot_write_to_commitlock.mdwn new file mode 100644 index 000000000..05490a799 --- /dev/null +++ b/doc/forum/Cannot_write_to_commitlock.mdwn @@ -0,0 +1,28 @@ +I am following the laptop wiki with git tip page. I have set up my local and remote wiki as suggested. However, when I try to push my local changes back to the server I get the following error: + +Writing objects: 100% (4/4), 359 bytes, done. +Total 4 (delta 2), reused 0 (delta 0) +cannot write to /home/ian/ianbarton/.ikiwiki/commitlock: No such file or directory +To ian@wilkesley.org:~/ikiwiki/ianbarton.git + 5cf9054..16a871d master -> master + +The relevnt bit of my setup file is: + +git_wrapper => '/home/ian/ianbarton.git/hooks/post-commit', + +Now ~/ianbarton/.ikiwiki exists and is owned and writable by me. I have tried touching commitlock and also removing lock and commitlock before pushing. Any suggestions for further trouble shooting? + +Ian. + +> I'm guessing that this is some kind of permissions problem, +> and that the error message is just being misleading. +> +> When you push the changes to the server, what user is +> git logging into the server as? If that user is different +> than `ian` (possibly due to using git-daemon?), the post-commit +> wrapper needs to be setuid to `ian`. This ensures that ikiwiki +> runs as you and can see and write to the files. --[[Joey]] + +The user is logging as ian, the same user as the laptop. I can push and pull git repos on the same server owned by the same user via ssh with no problem. I have deleted and re-started from scratch several times. However, for my use case I think it's simpler to keep the repo on my local computer and just rsync the web pages to the server. + +Ian. diff --git a/doc/forum/Error:_bad_page_name.mdwn b/doc/forum/Error:_bad_page_name.mdwn new file mode 100644 index 000000000..70277a1e4 --- /dev/null +++ b/doc/forum/Error:_bad_page_name.mdwn @@ -0,0 +1,46 @@ +I'm trying to use ikiwiki for the first time. In the start, I had problems +with installing the package, because I don't have a root account on my +server. + +When I solved this, I finally set up my wiki, but whenever I try to edit a +page, I get an error: “Error: bad page name”. + +What am I doing wrong? The wiki is at +<http://atrey.karlin.mff.cuni.cz/~onderka/wiki/>, the setupfile I used at +<http://atrey.karlin.mff.cuni.cz/~onderka/wiki/ikiwiki.setup>. + +> This means that one of the checks that ikiwiki uses to prevent +> editing files with strange or insecure names has fired incorrectly. +> Your setup file seems fine. +> We can figure out what is going wrong through a series of tests: +> +> * Test if your perl has a problem with matching alphanumerics: +> `perl -le 'print int "index"=~/^([-[:alnum:]+\/.:_]+)$/'` +> * Check if something is breaking pruning of disallowed files: +> `perl -le 'use IkiWiki; %config=IkiWiki::defaultconfig(); print ! IkiWiki::file_pruned("index")'` +> --[[Joey]] + +>>Both seem to run fine: + + onderka@atrey:~$ perl -le 'print int "index"=~/^([-[:alnum:]+\/.:_]+)$/' + 1 + onderka@atrey:~$ perl -le 'use IkiWiki; %config=IkiWiki::defaultconfig(); print ! IkiWiki::file_pruned("index")' + 1 + +>>> Try installing this [instrumented +>>> version](http://kitenet.net/~joey/tmp/editpage.pm) of +>>> `IkiWiki/Plugin/editpage.pm`, which will add some debugging info +>>> to the error message. --[[Joey]] + +>>>>When I tried to `make` ikiwiki with this file, I got the error + + ../IkiWiki/Plugin/editpage.pm:101: invalid variable interpolation at "$" + +>>>>> Sorry about that, I've corrected the above file. --[[Joey]] + +>>>>>> Hmm, funny. Now that I reinstalled it with your changed file, it started working. I didn't remember how exactly did I install it the last time, so this time, it seems I did it correctly. Thank you very much for your help. + +>>>>>>> Well, this makes me suspect you installed an older version of +>>>>>>> ikiwiki and my file, which is from the latest version, included a +>>>>>>> fix for whatever bug you were seeing. If I were you, I'd ensure +>>>>>>> that I have a current version of ikiwiki installed. --[[Joey]] diff --git a/doc/forum/How_does_ikiwiki_remember_times__63__.mdwn b/doc/forum/How_does_ikiwiki_remember_times__63__.mdwn index 5522cbf45..6b7739fd0 100644 --- a/doc/forum/How_does_ikiwiki_remember_times__63__.mdwn +++ b/doc/forum/How_does_ikiwiki_remember_times__63__.mdwn @@ -20,15 +20,17 @@ Do I have it right? > Some VCS, like git, set the file mtimes to the current time > when making a new checkout, so they will be lost if you do that. > The creation times can be retrived using the `--getctime` option. -> I suppose it might be nice if there were a `--getmtime` that pulled -> true modification times out of the VCS, but I haven't found it a big -> deal in practice for the last modification times to be updated to the -> current time when rebuilding a wiki like this. --[[Joey]] +> --[[Joey]] > > > Thanks for the clarification. I ran some tests of my own to make sure I understand it right, and I'm satisfied > > that the order of posts in my blog can be retrieved from the VCS using the `--getctime` option, at least if I > > choose to order my posts by creation time rather than modification time. But I now know that I can't rely on > > page modification times in ikiwiki as these can be lost permanently. +> +> > > Update: It's now renamed to `--gettime`, and pulls both the creation +> > > and modification times. Also, per [[todo/auto_getctime_on_fresh_build]], +> > > this is now done automatically the first time ikiwiki builds a +> > > srcdir. So, no need to worry about this any more! --[[Joey]] > > > > I would suggest that there should at least be a `--getmtime` option like you describe, and perhaps that > > `--getctime` and `--getmtime` be _on by default_. In my opinion the creation times and modification times of @@ -87,3 +89,10 @@ Do I have it right? $EDITOR "$pagename" >>>>> -- [[Jon]] + +> A quick workaround for me to get modification times right is the following +> little zsh script, which unfortunately only works for git: + +>> Elided; no longer needed since --gettime does that, and much faster! --[[Joey]] + +> --[[David_Riebenbauer]] diff --git a/doc/forum/Ikiwiki_CGI_not_working_on_my_server__44___and_it__39__s_a_binary_file__63__.mdwn b/doc/forum/Ikiwiki_CGI_not_working_on_my_server__44___and_it__39__s_a_binary_file__63__.mdwn new file mode 100644 index 000000000..35db20dc8 --- /dev/null +++ b/doc/forum/Ikiwiki_CGI_not_working_on_my_server__44___and_it__39__s_a_binary_file__63__.mdwn @@ -0,0 +1,33 @@ +Hey, trying to get ikiwiki working on my account on a shared webserver. Actually installing ikiwiki on the server is phase 2. For now I'm running the latest ikiwiki (from source) locally, compiling the output with the ikiwiki command, then rsyncing the output dir up to the server. This works for the static HTML files, but the CGI file doesn't work, the server redirects to an error page. The error log on the server says "Premature end of script headers: /path/to/ikiwiki.cgi" + +My first thought was that this is a Perl CGI and I would need to change the shebang to point to the unusual location of Perl on this server, it's at /usr/pkg/bin/perl. But when I looked at ikiwiki.cgi I found it was a binary file. + +Why is it a binary? And what can I do about this error? + +> It's a binary because it's SUID, so that it has permission to write to the ikiwiki repository. See [[security]], under 'suid wrappers', for more on that. +> +> As to why you get 'premature end of script headers', that suggests there is a problem running +> the script (and there is output occurring before the HTTP headers are printed). Do you have access +> to the webserver logs for your host? They might contain some clues. Are you sure that the webserver +> is setup for CGI properly? -- [[Jon]] + +> Quite likely your laptop and your server do not run the same +> OS, so the wrapper binary cannot just be copied from one +> to the other and run. Also, the wrapper is just that, a +> thin wrapper which then runs ikiwiki. As ikiwiki is not +> yet installed on your server, that's another reason what +> you're trying can't work. +> +> If installing ikiwiki on the server is not possible or +> too much work right now, you could try building your wiki +> on your laptop with cgi disabled in the setup file. +> The result would be a static website that you could deploy to +> the server this way. Of course, it wouldn't be editable +> on the server, and other features that need the CGI would +> also be disabled. --[[Joey]] + +> > Ah, ok thanks. Yes the server runs a different OS and ikiwiki +> > is not installed on it. I've got it working as a static site, +> > so if I want the CGI I'll have to install ikiwiki on the server. +> > Ok. It might not work as I don't have root access, but I might +> > give it a try. Thanks diff --git a/doc/forum/Migrating_old_repository_to_new_ikiwiki_system__63__.mdwn b/doc/forum/Migrating_old_repository_to_new_ikiwiki_system__63__.mdwn index fe67e6aba..d7a33b526 100644 --- a/doc/forum/Migrating_old_repository_to_new_ikiwiki_system__63__.mdwn +++ b/doc/forum/Migrating_old_repository_to_new_ikiwiki_system__63__.mdwn @@ -20,10 +20,6 @@ How do I set up an ikiwiki system using a pre-existing repository (instead of cr > recreate the ikiwiki srcdir > 3. `git clone` from the bare git repository a second time, > to create a checkout you can manually edit (optional) -> 4. run `ikiwiki --getctime --setup your.setup` -> The getctime will ensure page creation times are accurate -> by putting the info out of the git history, -> and only needs to be done once. > > If you preserved your repository, but not the setup file, > the easiest way to make one is probably to run diff --git a/doc/forum/News_site_where_articles_are_submitted_and_then_reviewed_before_posting.mdwn b/doc/forum/News_site_where_articles_are_submitted_and_then_reviewed_before_posting.mdwn new file mode 100644 index 000000000..8dd755274 --- /dev/null +++ b/doc/forum/News_site_where_articles_are_submitted_and_then_reviewed_before_posting.mdwn @@ -0,0 +1,23 @@ +[[!meta date="2008-04-28 14:57:25 -0400"]] + +I am considering moving a news site to Ikiwiki. I am hoping that Ikiwiki has a feature where anonymous posters can submit a form that moderators can review and then accept for it to be posted on a news webpage (like front page of the website). + +> Well, you can have one blog that contains unreviewed articles, and +> moderators can then add a tag that makes the article show up in the main +> news feed. There's nothing stopping someone submitting an article +> pre-tagged though. If you absolutely need to lock that down, you could +> have one blog with unreviewed articles in one subdirectory, and reviewers +> then move the file over to another subdirectory when they're ready to +> publish it. (This second subdirectory would be locked to prevent others +> from writing to it.) --[[Joey]] + +Also it would be good if the news page would keep maybe just the latest 10 entries with links to an archive that make it easy to browse to old entries by date. (Could have over a thousand news articles.) + +> The inline plugin allows setting up things like this. + +Plus users be able to post feedback to news items. If anonymous, they must be approved first. I'd prefer to not use normal "wiki" editor for feedback. + +Any thoughts or examples on this? Any links to examples of news sites or blogs with outside feedback using ikiwiki? + +Thanks --[[JeremyReed]] + diff --git a/doc/forum/PERL5LIB__44___wrappers_and_homedir_install.mdwn b/doc/forum/PERL5LIB__44___wrappers_and_homedir_install.mdwn new file mode 100644 index 000000000..fba941efc --- /dev/null +++ b/doc/forum/PERL5LIB__44___wrappers_and_homedir_install.mdwn @@ -0,0 +1,38 @@ +What is the way to tell wrappers that PERL5LIB should include ~/bin directories? + +Having this in the wiki.setup doesn't help anymore: + + # environment variables + ENV => { + PATH => '/home/user/bin/bin:/usr/local/bin:/usr/bin:/bin:/usr/games:/home/user/ikiwiki/usr/bin/:/home/user/ikiwiki/usr/sbin/:/home/user/bin/bin/:~/bin/bin/', + PERL5LIB => '/home/user/bin/share/perl/5.10.0:/home/user/bin/lib/perl/5.10.0' + }, + +Or at least I get CGI errors and running ikiwiki.cgi manually fails too: + + Use of uninitialized value $tainted in pattern match (m//) at /usr/share/perl5/IkiWiki.pm line 233. + Argument "" isn't numeric in umask at /usr/share/perl5/IkiWiki.pm line 139. + Undefined subroutine &IkiWiki::cgierror called at /home/user/bin/bin/ikiwiki line 199. + +Server has an older ikiwiki installed but I'd like to use a newer version from git, and I don't have root access. + +> You can't set `PERL5LIB` in `ENV` in a setup file, because ikiwiki is already +> running before it reads that, and so it has little effect. Your error +> messages do look like a new bin/ikiwiki is using an old version of +> `IkiWiki.pm`. +> +> The thing to do is set `INSTALL_BASE` when you're installing ikiwiki from +> source. Like so: + + cd ikiwiki + perl Makefile.PL INSTALL_BASE=$HOME PREFIX= + make install + +> Then `$HOME/bin/ikiwiki` will have hardcoded into it to look +> for ikiwiki's perl modules in `$HOME/lib/perl5/` +> (This is documented in the README file by the way.) --[[Joey]] + +>> Ok, *perl Makefile.PL INSTALL_BASE=$HOME/bin PREFIX=* finally did it for me. I tried too many things with +>> these paths so I wasn't sure which actually worked. After that I did +>> *$ ikiwiki --setup www.setup --wrappers --rebuild*. Somehow in this update mess I seem to have lost the user +>> accounts, maybe the --rebuild was too much. diff --git a/doc/forum/Regex_for_Valid_Characters_in_Filenames.mdwn b/doc/forum/Regex_for_Valid_Characters_in_Filenames.mdwn new file mode 100644 index 000000000..618576f81 --- /dev/null +++ b/doc/forum/Regex_for_Valid_Characters_in_Filenames.mdwn @@ -0,0 +1,19 @@ +I'm sure that this is documented somewhere but I've ransacked the wiki and I can't find it. :-( What are the allowed characters in an ikiwiki page name? I'm writing a simple script to make updating my blog easier and need to filter invalid characters (so far I've found that # and , aren't allowed ;-)). Thanks for any pointers. -- [[AdamShand]] + +> The default `wiki_file_regexp` matches filenames containing only +> `[-[:alnum:]_.:/+]` +> +> The titlepage() function will convert freeform text to a valid +> page name. See [[todo/should_use_a_standard_encoding_for_utf_chars_in_filenames]] +> for an example. --[[Joey]] + +>> Perfect, thanks! +>> +>> In the end I decided that I didn't need any special characters in filenames and replaced everything but alphanumeric characters with underscores. In addition to replacing bad characters I also collapse multiple underscores into a single one, and strip off trailing and leading underscores to make tidy filenames. If it's useful to anybody else here's a sed example: +>> +>> # echo "++ Bad: ~@#$%^&*()_=}{[];,? Iki: +_-:./ Num: 65.5 ++" | sed -e 's/[^A-Za-z0-9_]/_/g' -e 's/__*/_/g' -e 's/^_//g' -e 's/_$//g' +>> Bad_Iki_Num_65_5 +>> +>>--[[AdamShand]] + +[[!meta date="2008-01-18 23:40:02 -0500"]] diff --git a/doc/forum/Render_more_than_one_dest_page_from_same_source_page.mdwn b/doc/forum/Render_more_than_one_dest_page_from_same_source_page.mdwn new file mode 100644 index 000000000..e7362c903 --- /dev/null +++ b/doc/forum/Render_more_than_one_dest_page_from_same_source_page.mdwn @@ -0,0 +1,51 @@ +Is it possible to render more than one destination page from the same source page? +That is, same source, slightly different presentation at the other end, needing a different output file. + +> It's possible to render more than one output _file_ from a given source +> page. See, for example, the inline plugin's generation of rss files. +> This is done by calling `will_render()` and using `writefile()` to +> generate the additional files. Probably in a format hook if you want +> to generate html files. + +>> Thanks for the tip, I'll take a look at that. -- [[KathrynAndersen]] + +> It's not possible for one source file to represent multiple wiki pages. +> There is a 1:1 mapping between source filenames and page names. The +> difference between wiki pages and output files is that you can use +> wikilinks to link to wiki pages, etc. --[[Joey]] + +I have two problems that would be solved by being able to do this. + +[[!toc startlevel=2]] + +##"full" and "print" versions of a page. + +One has a page "foo", which is rendered into foo.html. +One also wants a foo-print.html page, which uses "page-print.tmpl" rather than "page.tmpl" as its template. + +I want to do this for every page on the site, automatically, so it isn't feasible to do it by hand. + +> Did you know that ikiwiki's `style.css` arranges for pages to display +> differently when printed out? Things like the Action bar are hidden in +> printouts (search for `@media print`). So I don't see a reason to need +> whole files for printing when you can use these style sheet tricks. +> --[[Joey]] + +>>Fair enough. --[[KathrynAndersen]] + +##"en" and "en-us" versions of a page. + +My site is in non-US English. However, I want US-English people to find my site when they search for it when they use US spelling on certain search terms (such as "optimise" versus "optimize"). This requires a (crude) US-English version of the site where the spellings are changed automatically, and the LANG is "en-us" rather than "en". (No, don't tell me to use keywords; Google ignores keywords and has for a number of years). + +So I want the page "foo" to render to "foo.en.html" and "foo.en-us.html" where the content is the same, just some automated word-substitution applied before foo.en-us.html is written. And do this for every page on the site. + +I can't do this with the "po" plugin, as it considers "en-us" not to be a valid language. And the "po" plugin is probably overkill for what I want anyway. + +But I'm not sure how to achieve the result I need. + +-- [[KathrynAndersen]] + +> Sounds like this could be considered a single page that generates two +> html files, so could be handled per above. --[[Joey]] + +>>Thanks! --[[KathrynAndersen]] diff --git a/doc/forum/Should_not_create_an_existing_page.mdwn b/doc/forum/Should_not_create_an_existing_page.mdwn new file mode 100644 index 000000000..b9500757f --- /dev/null +++ b/doc/forum/Should_not_create_an_existing_page.mdwn @@ -0,0 +1,15 @@ +[[!meta date="2007-01-08 14:55:31 +0000"]] + +This might be a bug, but will discuss it here first. +Clicking on an old "?" or going to a create link but new Markdown content exists, should not go into "create" mode, but should do a regular "edit". + +> I belive that currently it does a redirect to the new static web page. +> At least that's the intent of the code. --[[Joey]] + +>> Try at your site: `?page=discussion&from=index&do=create` +>> It brings up an empty textarea to start a new webpage -- even though it already exists here. --reed + +>>> Ah, right. Notice that the resulting form allows saving the page as +>>> discussion, or users/discussion, but not index/discussion, since this +>>> page already exists. If all the pages existed, it would do the redirect +>>> thing. --[[Joey]] diff --git a/doc/forum/Sidebar_with_links__63__.mdwn b/doc/forum/Sidebar_with_links__63__.mdwn new file mode 100644 index 000000000..790ee85a2 --- /dev/null +++ b/doc/forum/Sidebar_with_links__63__.mdwn @@ -0,0 +1,58 @@ +I'm trying to create a template to use as a sidebar with links. The template will be static +(no variables are used). I first created a page with this directive: \[[!template id=sidebar]], +and then created the template with the web interface. + +This is the code I put in the template: + + <div class="infobox"> + <ul> + <li>\[[Existing internal link|exists]]</li> + <li>\[[Non-existing internal link|doesnotexist]]</li> + <li>[External link](http://google.com/)</li> + </ul> + <http://google.com/> + </div> + +This is the relevant part of the resulting html file `template/sidebar.html`: + + <div class="infobox"> + <ul> + <li><a href="../exists.html">Existing internal link</a></li> + <li><span class="createlink"><a href="http://localhost/cgi-bin/itesohome.cgi?page=doesnotexist&from=templates%2Fsidebar&do=create" rel="nofollow">?</a>Non-existing internal link</span></li> + <li>[External link](http://google.com/)</li> + </ul> + </div> + +Note that the `<http://google.com/>` link has disappeared, and that `[External link](http://google.com/)` +has been copied literally instead of being converted to a link, as I expected. + +> Templates aren't Markdown page. [[ikiwiki/WikiLink]] only are expanded. --[[Jogo]] + +>> Thanks for the help Jogo. Looking at the [[templates]] page, it says that +"...you can include WikiLinks and all other forms of wiki markup in the template." I read this +to mean that a template may indeed include Markdown. Am I wrong in my interpratation? --[[buo]] + +>> I discovered that if I eliminate all html from my sidebar.mdwn template, the links are +rendered properly. It seems that the mix of Markdown and html is confusing some part of +Ikiwiki. --[[buo]] + +Worse, this is the relevant part of the html file of the page that includes the template: + + <div class="infobox"> + <ul> + <li><span class="selflink">Existing internal link</span></li> + <li><span class="createlink"><a href="http://localhost/cgi-bin/itesohome.cgi?page=doesnotexist&from=research&do=create" rel="nofollow">?</a>Non-existing internal link</span></li> + <li>[External link](http://google.com/)</li> + </ul> + </div> + +Note that the `Existing internal link` is no longer a link. It is only text. + +What am I doing wrong? Any help or pointers will be appreciated. --[[buo]] + +----- + +I think I have figured this out. I thought the template was filled and then +processed to convert Markdown to html. Instead, the text in each variable is +processed and then the template is filled. I somehow misunderstood the +[[templates]] page. -- [[buo]] diff --git a/doc/forum/Spaces_in_wikilinks.mdwn b/doc/forum/Spaces_in_wikilinks.mdwn new file mode 100644 index 000000000..9326ac448 --- /dev/null +++ b/doc/forum/Spaces_in_wikilinks.mdwn @@ -0,0 +1,104 @@ +[[!meta date="2007-07-02 13:21:29 +0000"]] + +# Spaces in WikiLinks? + +Hello Joey, + +I've just switched from ikiwiki 2.0 to ikiwiki 2.2 and I'm really surprised +that I can't use the spaces in WikiLinks. Could you please tell me why the spaces +aren't allowed in WikiLinks now? + +My best regards, + +--[[PaweB|ptecza]] + +> See [[bugs/Spaces_in_link_text_for_ikiwiki_links]] + +---- + +# Build in OpenSolaris? + +Moved to [[bugs/build_in_opensolaris]] --[[Joey]] + +---- + +# Various ways to use Subversion with ikiwiki + +I'm playing around with various ways that I can use subversion with ikiwiki. + +* Is it possible to have ikiwiki point to a subversion repository which is on a different server? The basic checkin/checkout functionality seems to work but there doesn't seem to be any way to make the post-commit hook work for a non-local server? + +> This is difficult to do since ikiwiki's post-commit wrapper expects to +> run on a machine that contains both the svn repository and the .ikiwiki +> state directory. However, with recent versions of ikiwiki, you can get +> away without running the post-commit wrapper on commit, and all you lose +> is the ability to send commit notification emails. + +> (And now that [[recentchanges]] includes rss, you can just subscribe to +> that, no need to worry about commit notification emails anymore.) + +* Is it possible / sensible to have ikiwiki share a subversion repository with other data (either completely unrelated files or another ikiwiki instance)? This works in part but again the post-commit hook seems problematic. + +--[[AdamShand]] + +> Sure, see ikiwiki's subversion repository for example of non-wiki files +> in the same repo. If you have two wikis in one repository, you will need +> to write a post-commit script that calls the post-commit wrappers for each +> wiki. + +---- + +# Regex for Valid Characters in Filenames + +I'm sure that this is documented somewhere but I've ransacked the wiki and I can't find it. :-( What are the allowed characters in an ikiwiki page name? I'm writing a simple script to make updating my blog easier and need to filter invalid characters (so far I've found that # and , aren't allowed ;-)). Thanks for any pointers. -- [[AdamShand]] + +> The default `wiki_file_regexp` matches filenames containing only +> `[-[:alnum:]_.:/+]` +> +> The titlepage() function will convert freeform text to a valid +> page name. See [[todo/should_use_a_standard_encoding_for_utf_chars_in_filenames]] +> for an example. --[[Joey]] + +>> Perfect, thanks! +>> +>> In the end I decided that I didn't need any special characters in filenames and replaced everything but alphanumeric characters with underscores. In addition to replacing bad characters I also collapse multiple underscores into a single one, and strip off trailing and leading underscores to make tidy filenames. If it's useful to anybody else here's a sed example: +>> +>> # echo "++ Bad: ~@#$%^&*()_=}{[];,? Iki: +_-:./ Num: 65.5 ++" | sed -e 's/[^A-Za-z0-9_]/_/g' -e 's/__*/_/g' -e 's/^_//g' -e 's/_$//g' +>> Bad_Iki_Num_65_5 +>> +>>--[[AdamShand]] + +# Upgrade steps from RecentChanges CGI to static page? + +Where are the upgrade steps for RecentChanges change from CGI to static feed? +I run multiple ikiwiki-powered sites on multiple servers, but today I just upgraded one to 2.32.3. +Please have a look at +<http://bsdwiki.reedmedia.net/wiki/recentchanges.html> +Any suggestions? + +> There are no upgrade steps required. It does look like you need to enable +> the meta plugin to get a good recentchanges page though.. --[[Joey]] + +# News site where articles are submitted and then reviewed before posting? + +I am considering moving a news site to Ikiwiki. I am hoping that Ikiwiki has a feature where anonymous posters can submit a form that moderators can review and then accept for it to be posted on a news webpage (like front page of the website). + +> Well, you can have one blog that contains unreviewed articles, and +> moderators can then add a tag that makes the article show up in the main +> news feed. There's nothing stopping someone submitting an article +> pre-tagged though. If you absolutely need to lock that down, you could +> have one blog with unreviewed articles in one subdirectory, and reviewers +> then move the file over to another subdirectory when they're ready to +> publish it. (This second subdirectory would be locked to prevent others +> from writing to it.) --[[Joey]] + +Also it would be good if the news page would keep maybe just the latest 10 entries with links to an archive that make it easy to browse to old entries by date. (Could have over a thousand news articles.) + +> The inline plugin allows setting up things like this. + +Plus users be able to post feedback to news items. If anonymous, they must be approved first. I'd prefer to not use normal "wiki" editor for feedback. + +Any thoughts or examples on this? Any links to examples of news sites or blogs with outside feedback using ikiwiki? + +Thanks --[[JeremyReed]] + diff --git a/doc/forum/The_requested_URL___47____126__jean__47__blog__47__ikiwiki.cgi_was_not_found_on_this_server..mdwn b/doc/forum/The_requested_URL___47____126__jean__47__blog__47__ikiwiki.cgi_was_not_found_on_this_server..mdwn new file mode 100644 index 000000000..4061a7348 --- /dev/null +++ b/doc/forum/The_requested_URL___47____126__jean__47__blog__47__ikiwiki.cgi_was_not_found_on_this_server..mdwn @@ -0,0 +1,11 @@ +Hi, +Installed ikiwiki on my ubuntu (04.10) box; after creating a blog according to your setup instructions I cannot edit files on the web interface, and I get this errer «The requested URL /~jean/blog/ikiwiki.cgi was not found on this server.» +I have no idea what to do (sorry for my ignorance) + +tia, + +> Make sure you have a `~/public_html/ikiwiki.cgi`. Your setup +> file should generate that via the `cgi_wrapper` option. +> +> Maybe you need to follow the [[tips/dot_cgi]] tip to make apache see it. +> --[[Joey]] diff --git a/doc/forum/The_requested_URL___47____126__jean__47__blog__47__ikiwiki.cgi_was_not_found_on_this_server./comment_1_d36ce6fab90e0a086ac84369af38d205._comment b/doc/forum/The_requested_URL___47____126__jean__47__blog__47__ikiwiki.cgi_was_not_found_on_this_server./comment_1_d36ce6fab90e0a086ac84369af38d205._comment new file mode 100644 index 000000000..f95972c4f --- /dev/null +++ b/doc/forum/The_requested_URL___47____126__jean__47__blog__47__ikiwiki.cgi_was_not_found_on_this_server./comment_1_d36ce6fab90e0a086ac84369af38d205._comment @@ -0,0 +1,16 @@ +[[!comment format=mdwn + username="jeanm" + subject="comment 1" + date="2010-06-19T13:35:37Z" + content=""" +OK, I followed the dot cgi tip and this error diappears, thanks a lot! So ubuntu doesn't provide a \"working out of the box\" ikiwiki. + +But I get a new error message now when trying to edit a page: + +Error: \"do\" parameter missing + +My plugins now: +add_plugins => [qw{goodstuff websetup comments blogspam 404 muse}], + + +"""]] diff --git a/doc/forum/The_requested_URL___47____126__jean__47__blog__47__ikiwiki.cgi_was_not_found_on_this_server./comment_2_5836bba08172d2ddf6a43da87ebb0332._comment b/doc/forum/The_requested_URL___47____126__jean__47__blog__47__ikiwiki.cgi_was_not_found_on_this_server./comment_2_5836bba08172d2ddf6a43da87ebb0332._comment new file mode 100644 index 000000000..0a544eeb1 --- /dev/null +++ b/doc/forum/The_requested_URL___47____126__jean__47__blog__47__ikiwiki.cgi_was_not_found_on_this_server./comment_2_5836bba08172d2ddf6a43da87ebb0332._comment @@ -0,0 +1,7 @@ +[[!comment format=mdwn + username="http://joey.kitenet.net/" + subject="do parameter missing" + date="2010-06-23T17:03:12Z" + content=""" +That's an unusual problem. Normally the url or form that calls ikiwiki.cgi includes a \"do\" parameter, like \"do=edit\". I'd have to see the site to debug why it is missing for you. +"""]] diff --git a/doc/forum/The_requested_URL___47____126__jean__47__blog__47__ikiwiki.cgi_was_not_found_on_this_server./comment_3_4eec15c8c383275db5401c8e3c2d9242._comment b/doc/forum/The_requested_URL___47____126__jean__47__blog__47__ikiwiki.cgi_was_not_found_on_this_server./comment_3_4eec15c8c383275db5401c8e3c2d9242._comment new file mode 100644 index 000000000..faf3ad31b --- /dev/null +++ b/doc/forum/The_requested_URL___47____126__jean__47__blog__47__ikiwiki.cgi_was_not_found_on_this_server./comment_3_4eec15c8c383275db5401c8e3c2d9242._comment @@ -0,0 +1,9 @@ +[[!comment format=mdwn + username="jeanm" + ip="81.56.145.104" + subject="do parameter missing" + date="2010-06-30T07:30:08Z" + content=""" +the site address is piaffer.org, with a link to blog just over the picture. +tia, +"""]] diff --git a/doc/forum/The_requested_URL___47____126__jean__47__blog__47__ikiwiki.cgi_was_not_found_on_this_server./comment_4_43ac867621efb68affa6ae2b92740cad._comment b/doc/forum/The_requested_URL___47____126__jean__47__blog__47__ikiwiki.cgi_was_not_found_on_this_server./comment_4_43ac867621efb68affa6ae2b92740cad._comment new file mode 100644 index 000000000..d8b516f5f --- /dev/null +++ b/doc/forum/The_requested_URL___47____126__jean__47__blog__47__ikiwiki.cgi_was_not_found_on_this_server./comment_4_43ac867621efb68affa6ae2b92740cad._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://joey.kitenet.net/" + nickname="joey" + subject="comment 4" + date="2010-07-04T18:16:26Z" + content=""" +What is the muse plugin that you have enabled? I am not familiar with it. + +Apparently your ikiwiki is not seeing cgi parameters that should be passed to it. This appears to be some kind of web server misconfiguration, or possibly a broken ikiwiki wrapper or broken CGI.pm. +"""]] diff --git a/doc/forum/The_requested_URL___47____126__jean__47__blog__47__ikiwiki.cgi_was_not_found_on_this_server./comment_5_e098723bb12adfb91ab561cae21b492b._comment b/doc/forum/The_requested_URL___47____126__jean__47__blog__47__ikiwiki.cgi_was_not_found_on_this_server./comment_5_e098723bb12adfb91ab561cae21b492b._comment new file mode 100644 index 000000000..b832d64f4 --- /dev/null +++ b/doc/forum/The_requested_URL___47____126__jean__47__blog__47__ikiwiki.cgi_was_not_found_on_this_server./comment_5_e098723bb12adfb91ab561cae21b492b._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://joey.kitenet.net/" + nickname="joey" + subject="do parameter missing" + date="2010-07-08T06:04:44Z" + content=""" +I just debugged this problem with someone else who was using ngix-fcgi. There was a problem with it not passing CGI environment variables properly. If you're using that, it might explain your problem. +"""]] diff --git a/doc/forum/The_requested_URL___47____126__jean__47__blog__47__ikiwiki.cgi_was_not_found_on_this_server./comment_6_101183817ca4394890bd56a7694bedd9._comment b/doc/forum/The_requested_URL___47____126__jean__47__blog__47__ikiwiki.cgi_was_not_found_on_this_server./comment_6_101183817ca4394890bd56a7694bedd9._comment new file mode 100644 index 000000000..25a4e8bae --- /dev/null +++ b/doc/forum/The_requested_URL___47____126__jean__47__blog__47__ikiwiki.cgi_was_not_found_on_this_server./comment_6_101183817ca4394890bd56a7694bedd9._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="jeanm" + ip="81.56.145.104" + subject="comment 6" + date="2010-07-12T17:43:31Z" + content=""" +I'm using apache and mostly firefox. +I've tried some changes in my config but still the same problem, then I fell ill and unable to try anything more. Now I seem to be better and I will go back to the problem soon. +Thx +"""]] diff --git a/doc/forum/Upgrade_steps_from_RecentChanges_CGI_to_static_page.mdwn b/doc/forum/Upgrade_steps_from_RecentChanges_CGI_to_static_page.mdwn new file mode 100644 index 000000000..298ff49f1 --- /dev/null +++ b/doc/forum/Upgrade_steps_from_RecentChanges_CGI_to_static_page.mdwn @@ -0,0 +1,10 @@ +Where are the upgrade steps for RecentChanges change from CGI to static feed? +I run multiple ikiwiki-powered sites on multiple servers, but today I just upgraded one to 2.32.3. +Please have a look at +<http://bsdwiki.reedmedia.net/wiki/recentchanges.html> +Any suggestions? + +> There are no upgrade steps required. It does look like you need to enable +> the meta plugin to get a good recentchanges page though.. --[[Joey]] + +[[!meta date="2008-02-23 21:10:42 -0500"]] diff --git a/doc/forum/Various_ways_to_use_Subversion_with_ikiwiki.mdwn b/doc/forum/Various_ways_to_use_Subversion_with_ikiwiki.mdwn new file mode 100644 index 000000000..8eed30cd8 --- /dev/null +++ b/doc/forum/Various_ways_to_use_Subversion_with_ikiwiki.mdwn @@ -0,0 +1,23 @@ +[[!meta date="2007-08-17 03:54:10 +0000"]] + +I'm playing around with various ways that I can use subversion with ikiwiki. + +* Is it possible to have ikiwiki point to a subversion repository which is on a different server? The basic checkin/checkout functionality seems to work but there doesn't seem to be any way to make the post-commit hook work for a non-local server? + +> This is difficult to do since ikiwiki's post-commit wrapper expects to +> run on a machine that contains both the svn repository and the .ikiwiki +> state directory. However, with recent versions of ikiwiki, you can get +> away without running the post-commit wrapper on commit, and all you lose +> is the ability to send commit notification emails. + +> (And now that [[recentchanges]] includes rss, you can just subscribe to +> that, no need to worry about commit notification emails anymore.) + +* Is it possible / sensible to have ikiwiki share a subversion repository with other data (either completely unrelated files or another ikiwiki instance)? This works in part but again the post-commit hook seems problematic. + +--[[AdamShand]] + +> Sure, see ikiwiki's subversion repository for example of non-wiki files +> in the same repo. If you have two wikis in one repository, you will need +> to write a post-commit script that calls the post-commit wrappers for each +> wiki. --[[Joey]] diff --git a/doc/forum/an_alternative_approach_to_structured_data.mdwn b/doc/forum/an_alternative_approach_to_structured_data.mdwn new file mode 100644 index 000000000..6e6af8adb --- /dev/null +++ b/doc/forum/an_alternative_approach_to_structured_data.mdwn @@ -0,0 +1,63 @@ +## First Pass + +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]] + +> I agree such a separation makes some sense. But note that the discussion on [[todo/structured_page_data]] +> talks about associating data types with fields for a good reason: It's hard to later develop a good UI for +> querying or modifying a page's data if all the data has an implicit type "string". --[[Joey]] + +>> I'm not sure that having an implicit type of "string" is really such a bad thing. After all, Perl itself manages with just string and number, and easily converts from one to the other. Strong typing is generally used to (a) restrict what can be done with the data and/or (b) restrict how the data is input. The latter could be done with some sort of validated form, but that, too, could be decoupled from looking up and returning the value of a field. --[[KathrynAndersen]] + +## Second Pass + +I have written additional plugins which integrate with the [[plugins/contrib/field]] plugin to both set and get structured page data. + +* [[plugins/contrib/getfield]] - query field values inside a page using {{$*fieldname*}} markup +* [[plugins/contrib/ftemplate]] - like [[plugins/template]] but uses "field" data as well as passed-in data +* [[plugins/contrib/ymlfront]] - looks for YAML-format data at the front of a page; this is just one possible back-end for the structured data + +--[[KathrynAndersen]] + +> I'm not an IkiWiki committer ([[Joey]] is the only one I think) +> but I really like the look of this scheme. In particular, +> having `getfield` interop with `field` without being *part of* +> `field` makes me happy, since I'm not very keen on `getfield`'s +> syntax (i.e. "ugh, yet another mini-markup-language without a +> proper escaping mechanism"), but this way people can experiment +> with different syntaxes while keeping `field` for the +> behind-the-scenes bits. +> +>> I've started using `field` on a private site and it's working +>> well for me; I'll try to do some code review on its +>> [[plugins/contrib/field/discussion]] page. --s +> +> My [[plugins/contrib/album]] plugin could benefit from +> integration with `field` for photos' captions and so on, +> probably... I'll try to work on that at some point. +> +> [[plugins/contrib/report]] may be doing too much, though: +> it seems to be an variation on `\[[inline archive="yes"]]`, +> with an enhanced version of sorting, a mini version of +> [[todo/wikitrails]], and some other misc. I suspect it could +> usefully be divided up into discrete features? One good way +> to do that might be to shuffle bits of its functionality into +> the IkiWiki distribution and/or separate plugins, until there's +> nothing left in `report` itself and it can just go away. +> +> --[[smcv]] diff --git a/doc/forum/appear_if_you_are_login_or_not_in_a_page.mdwn b/doc/forum/appear_if_you_are_login_or_not_in_a_page.mdwn index e50eb4e1c..be9854a08 100644 --- a/doc/forum/appear_if_you_are_login_or_not_in_a_page.mdwn +++ b/doc/forum/appear_if_you_are_login_or_not_in_a_page.mdwn @@ -3,3 +3,34 @@ Hi, Can you give me a hint for showing if one user is logged or not. If user is logged, then I want to display the user name, as wikipedia or dokuwiki for example. Regards, Xan. + +> ikiwiki doesn't serve pages, so this can't be done inside ikiwiki. +> For certain kinds of authentication it might be possible anyway. +> For instance, if you're using [[plugins/httpauth]] exclusively and +> your server has PHP, you could put `<?php print("$REMOTE_USER"); +> ?>` in all the relevant ikiwiki [[templates]] and arrange for the +> generated HTML pages to get run through the PHP interpreter. The trick +> would work differently with other [[plugins/type/auth]] plugins, +> if at all. --[[Schmonz]] + +>> Thanks a lot, Xan. + +>>> Another possible trick would be to use some Javascript to make a +>>> "who am I?" AJAX request to the CGI (the CGI would receive the +>>> session cookie, if any, and be able to answer). Obviously, this +>>> wouldn't work for users who've disabled Javascript, but since it's +>>> non-essential, that's not so bad. You'd need to +>>> [[write_a_plugin|plugins/write]] to add a suitable CGI action, +>>> perhaps ?do=whoami, and insert the Javascript. --[[smcv]] + +>>>> It's an idea, but you're trading off a serious speed hit for a very +>>>> minor thing. --[[Joey]] + +>>>> Cool idea. A similar trick (I first saw it +>>>> [here](http://www.peej.co.uk/articles/http-auth-with-html-forms.html)) +>>>> could be used to provide a [[plugins/passwordauth]]-like login form +>>>> for [[plugins/httpauth]]. --[[Schmonz]] + +>>>>> I always assumed the entire reason someone might want to use the +>>>>> httpauth plugin is to avoid nasty site-specific login forms.. +>>>>> --[[Joey]] diff --git a/doc/forum/cleaning_up_discussion_pages_and_the_like.mdwn b/doc/forum/cleaning_up_discussion_pages_and_the_like.mdwn new file mode 100644 index 000000000..35ceae59b --- /dev/null +++ b/doc/forum/cleaning_up_discussion_pages_and_the_like.mdwn @@ -0,0 +1,11 @@ +For example in [[forum/ikiwiki__39__s_notion_of_time]], should one remove the +text about the implementation bug that has been fixed, or should it stay there, +for reference? --[[tschwinge]] + +> I have no problem with cleaning up obsolete stuff in the forum, tips, etc. +> --[[Joey]] + +That's also what I think: such discussions or comments on [[forum]] discussion +pages, or generally on all pages' [[Discussion]] subpages, can be removed if +either they're simply not valid / interesting / ... anymore, or if they've been +used to improve the *real* documentation. --[[tschwinge]] diff --git a/doc/forum/cutpaste.pm_not_only_file-local.mdwn b/doc/forum/cutpaste.pm_not_only_file-local.mdwn new file mode 100644 index 000000000..3563e3e01 --- /dev/null +++ b/doc/forum/cutpaste.pm_not_only_file-local.mdwn @@ -0,0 +1,14 @@ +I'd like to use the cutpaste plugin, but not only on a file-local basis: fileA +has \[[!cut id=foo text="foo"]], and fileB does \[[!absorb pagenames=fileA]], +and can then use \[[!paste id=foo]]. + +Therefore, I've written an [*absorb* directive / +plugin](http://www.thomas.schwinge.homeip.net/tmp/absorb.pm), which is meant to +absorb pages in order to get hold of their *cut* and *copy* directives' +contents. This does work as expected. But it also absorbs page fileA's *meta* +values, like a *meta title*, etc. How to avoid / solve this? + +Alternatively, do you have a better suggestion about how to achieve what I +described in the first paragraph? + +--[[tschwinge]] diff --git a/doc/forum/cutpaste.pm_not_only_file-local/comment_1_497c62f21fd1b87625b806407c72dbad._comment b/doc/forum/cutpaste.pm_not_only_file-local/comment_1_497c62f21fd1b87625b806407c72dbad._comment new file mode 100644 index 000000000..8cc724a72 --- /dev/null +++ b/doc/forum/cutpaste.pm_not_only_file-local/comment_1_497c62f21fd1b87625b806407c72dbad._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://kerravonsen.dreamwidth.org/" + ip="60.241.8.244" + subject="field and getfield and ymlfront" + date="2010-08-12T02:33:54Z" + content=""" +Have you considered trying the [[plugins/contrib/field]] plugin, and its associated plugins? [[plugins/contrib/ymlfront]] can give you the source (\"cut\") and [[plugins/contrib/getfield]] and/or [[plugins/contrib/report]] can get you the value (\"paste\") including the values from other pages. +"""]] diff --git a/doc/forum/debian_backports_update_someone_please.mdwn b/doc/forum/debian_backports_update_someone_please.mdwn new file mode 100644 index 000000000..7102d12a1 --- /dev/null +++ b/doc/forum/debian_backports_update_someone_please.mdwn @@ -0,0 +1,18 @@ +I'm just in the process of deploying ikiwiki and I'd love to use it in the html5 mode instead of in XHTML. Any chance that the ikiwiki's .deb in debian backports will be updated any time soon? + +> Formerer does a good job keeping the backport up-to-date with whatever is in Debian testing. +> Which is the policy of what Backports should contain. So, I just need to stop releasing ikiwiki +> for 2 weeks. :) --[[Joey]] + +>> And are there any chances you doing it... or rather not doing it? + +>>> Sure, I'm busily not doing it right now. Should reach testing in 3 +>>> days. I generally schedule things so a new ikiwiki reaches testing +>>> every 2 weeks to month. Getting important new features and bugfixes out +>>> can take priority though. --[[Joey]] + +>>>> Great! Thanks. + +>>>> Still not available in the backports; did you break the silence on the wire and got back to work [[Joey]]? + +>>>> I was blinded by my stupidity... thanks! diff --git a/doc/forum/double_forward_slash___39____47____47____39___in_the_address_bar.mdwn b/doc/forum/double_forward_slash___39____47____47____39___in_the_address_bar.mdwn new file mode 100644 index 000000000..b5fb2aa18 --- /dev/null +++ b/doc/forum/double_forward_slash___39____47____47____39___in_the_address_bar.mdwn @@ -0,0 +1,3 @@ +Why do all the pages are preceded with a double forward slash in the address bar... ie. http://example.org//ikiwiki/pagespec/ .. maybe someone knows? + +> Sorted, base url in the .setup file had the unnecessary '/' suffix. diff --git a/doc/forum/editing_a_comment.mdwn b/doc/forum/editing_a_comment.mdwn new file mode 100644 index 000000000..8bddab3fb --- /dev/null +++ b/doc/forum/editing_a_comment.mdwn @@ -0,0 +1 @@ +Is it possible to edit a comment? I did not find any button for it. diff --git a/doc/forum/editing_the_style_sheet.mdwn b/doc/forum/editing_the_style_sheet.mdwn new file mode 100644 index 000000000..b4aa8c89b --- /dev/null +++ b/doc/forum/editing_the_style_sheet.mdwn @@ -0,0 +1,18 @@ +[[!meta date="2006-12-29 04:19:51 +0000"]] + +It would be nice to be able to edit the stylesheet by means of the cgi. Or is this possible? I wasn't able to achieve it. +Ok, that's my last 2 cents for a while. --[Mazirian](http://mazirian.com) + +> I don't support editing it, but if/when ikiwiki gets [[todo/fileupload]] support, +> it'll be possible to upload a style sheet. (If .css is in the allowed +> extensions list.. no idea how safe that would be, a style sheet is +> probably a great place to put XSS attacks and evil javascript that would +> be filtered out of any regular page in ikiwiki). --[[Joey]] + +>> I hadn't thought of that at all. It's a common feature and one I've +>> relied on safely, because the wikis I am maintaining at the moment +>> are all private and restricted to trusted users. Given that the whole +>> point of ikiwiki is to be able to access and edit via the shell as +>> well as the web, I suppose the features doesn't add a lot. By the +>> way, the w3m mode is brilliant. I haven't tried it yet, but the idea +>> is great. diff --git a/doc/forum/ever-growing_list_of_pages.mdwn b/doc/forum/ever-growing_list_of_pages.mdwn new file mode 100644 index 000000000..9920e34bb --- /dev/null +++ b/doc/forum/ever-growing_list_of_pages.mdwn @@ -0,0 +1,29 @@ +What is overyone's idea about the ever-growing list of pages in bugs/ etc.? +Once linked to `done`, they're removed from the rendered [[bugs]] page -- but +they're still present in the repository. + +Shouldn't there be some clean-up at some point for those that have been +resolved? Or should all of them be kept online forever? + +--[[tschwinge]] + +> To answer a question with a question, what harm does having the done bugs +> around cause? At some point in the future perhaps the number of done pages +> will be large enough to be a time or space concern. Do you think we've +> reached a point now? One advantage of having them around is that people +> running older versions of the Ikiwiki software may find the page explaining +> that the bug is fixed if they perform a search. -- [[Jon]] + +> I like to keep old bugs around. --[[Joey]] + +So, I guess it depends on whether you want to represent the development of the +software (meaning: which bugs are open, which are fixed) *(a)* in a snapshot of +the repository (a checkout; that is, what you see rendered on +<http://ikiwiki.info/>), or *(b)* if that information is to be contained in the +backing repository's revision history only. Both approaches are valid. For +people used to using Git for accessing a project's history, *(b)* is what +they're used to, but for those poor souls ;-) that only use a web browser to +access this database, *(a)* is the more useful approach indeed. For me, using +Git, it is a bit of a hindrance, as, when doing a full-text search for a +keyword on a checkout, I'd frequently hit pages that reported a bug, but are +tagged `done` by now. --[[tschwinge]] diff --git a/doc/forum/formating:_how_to_align_text_to_the_right.mdwn b/doc/forum/formating:_how_to_align_text_to_the_right.mdwn new file mode 100644 index 000000000..2b56bd70b --- /dev/null +++ b/doc/forum/formating:_how_to_align_text_to_the_right.mdwn @@ -0,0 +1,15 @@ +as in title, how to align text to the right? + +> Add to your local.css a class that aligns text to the right: + + .alignright { text-align: right; } + +> And then you just just use `<span class="alignright">` around +> other html. +> +> You can refine that, and allow right-aligning markdowned text +> by using the [[ikiwiki/directive/template]] +> directive, with a template that contains the html. The +> [[templates/note]] template does something similar. --[[Joey]] + +>> Thanks! diff --git a/doc/forum/google_openid_broken__63__.mdwn b/doc/forum/google_openid_broken__63__.mdwn new file mode 100644 index 000000000..96ba2d791 --- /dev/null +++ b/doc/forum/google_openid_broken__63__.mdwn @@ -0,0 +1,79 @@ +Now that google supports using thier profiles as OpenIDs, that can be used +directly to sign into ikiwiki. Just use, for example, +<http://www.google.com/profiles/joeyhess> . Tested and it works. --[[Joey]] + +> This seems to work fine if you use the profile directly as an OpenID. It doesn't seem to work with delegation. From that I can see, this is a deliberate decision by Google for security reasons. See the response [here](http://groups.google.com/group/google-federated-login-api/browse_thread/thread/825067789537568c/23451a68c8b8b057?show_docid=23451a68c8b8b057). -- [[Will]] + +## historical discussion + +when I login via to this wiki (or ours) via Google's OpenID, I get this error: + +Error: OpenID failure: no_identity_server: The provided URL doesn't declare its OpenID identity server. + +Any idea how to fix this?? + +> Google is [doing things with openid that are not in the spec](http://googledataapis.blogspot.com/2008/10/federated-login-for-google-account.html) +> and it's not clear to me that they intend regular openid to work at all. +> What is your google openid URL so I can take a look at the data they are +> providing? --[[Joey]] + + +http://openid-provider.appspot.com/larrylud + +> I've debugged this some and filed +> <https://rt.cpan.org/Ticket/Display.html?id=48728> on the Openid perl +> module. It's a pretty easy fix, so I hope upstream will fix it quickly. +> --[[Joey]] + +>> A little more information here: I'm using that same openid provider at the moment. Note that +>> that provider isn't google - it is someone using the google API to authenticate. I normally have it +>> set up as a redirect from my home page (which means I can change providers easily). + + <link rel="openid.server" href="http://openid-provider.appspot.com/will.uther"> + <link rel="openid.delegate" href="http://openid-provider.appspot.com/will.uther"> + +>> In that mode it works (I used it to log in to make this edit). However, when I try the openid +>> URL directly, it doesn't work. I think there is something weird with re-direction. I hope this +>> isn't a more general security hole. +>> -- [[Will]] + +---- + +So, while the above bug will probably get fixed sooner or later, +the best approach for those of you needing a google openid now is +to use gmail. + + +Just a note that someone has apparently figured out how to use a google +openid, and not a third-party provider either, to edit this site. +The openid is +<https://www.google.com/accounts/o8/id?id=AItOawltlTwUCL_Fr1siQn94GV65-XwQH5XSku4> +(what a mouthfull!), and I don't know who that is or how to use it since it +points to a fairly useless xml document, rather than a web page. --[[Joey]] + +> That string is what's received via the discovery protocol. The user logging in with a Google account is not supposed to write that when logging in, but rather <https://www.google.com/accounts/o8/id>. The OpenID client library will accept that and redirect the user to a sign in page, which will return that string as the OpenID. It's not really usable as an identifier for edits and whatnots, but an alternative would be to use the attribute exchange extension to get the email address and display that. See <http://code.google.com/apis/accounts/docs/OpenID.html#Parameters>. + +> Yahoo's OpenID implementation works alike, but I haven't looked at it as much. It uses <https://me.yahoo.com/> to receive the endpoint. + +> I've added buttons that submit the two above URLs for logging in with a Google and Yahoo OpenID, respectively, to my locally changed OpenID login plugin. + +> Using the Google profile page as the OpenID is really orthogonal to the above. --[[kaol]] + +>> First, I don't accept that the openid google returns from their +>> generic signin url *has* to be so freaking ugly. For contrast, +>> look at the openid you log in as if you use the yahoo url. +>> <https://me.yahoo.com/joeyhess#35f22>. Nice and clean, now +>> munged by ikiwiki to "joeyhess [me.yahoo.com]". +>> +>> Displaying email addresses is not really an option, because ikiwiki +>> can't leak user email addresses like that. Displaying nicknames or +>> usernames is, see [[todo/Separate_OpenIDs_and_usernames]]. +>> +>> It would probably be good if the openid plugin could be configured with +>> a list of generic openid urls, so it can add quick login buttons using +>> those urls. +>> +>> The ugly google url will still be exposed here and there where +>> a unique user id is needed. That can be avoided by not using the generic +>> <https://www.google.com/accounts/o8/id>, but instead your own profile +>> like <http://www.google.com/profiles/joeyhess>. --[[Joey]] diff --git a/doc/forum/how_do_I_revert_edits_in_the_web_mode__63__.mdwn b/doc/forum/how_do_I_revert_edits_in_the_web_mode__63__.mdwn new file mode 100644 index 000000000..7686a7a08 --- /dev/null +++ b/doc/forum/how_do_I_revert_edits_in_the_web_mode__63__.mdwn @@ -0,0 +1,35 @@ +Puzzled a bit :-/ + +> There is no explicit interface for reverting edits. Most of us use `git revert`. --[[Joey]] + +>> That's a blow; I was planning on appointing no techies to keep law and order on our pages :-/ Is there a plugin or at least a plan to add such a 'in demand' feature? + +>>> A lot of things complicate adding that feature to the web interface. +>>> +>>> First, ikiwiki happily uses whatever the VCS's best of breed web +>>> history interface is. (ie, viewvcs, gitweb). To allow reverting +>>> past the bottom of the RecentChanges page, it would need to have its +>>> own history browser. Not sure I want to go there. +>>> +>>> And the mechanics of handling reverting can quickly get complex. +>>> Web reverting should only allow users to revert things they can edit, +>>> but reverting a whole commit in git might touch multiple files. +>>> Some files may not be editable over the web at all. (The +>>> [[tips/untrusted_git_push]] also has to deal with those issues.) +>>> Finally, a revert can fail with a conflict. The revert could touch +>>> multiple files, and multiple ones could conflict. The conflict may +>>> involve non-page files that can't be diffed. So an interface for +>>> resolving such a conflict could be hard. +>>> +>>> Probably web-based reverting would need to be limited to reverting +>>> single file changes, not whole commits, and not having very good +>>> conflict handling. And maybe only being accessible for changes +>>> still visible on RecentChanges. With those limitations, it's certianly +>>> doable (as a plugin even), but given how excellent `git revert` is in +>>> comparison, I have not had a real desire to do so. --[[Joey]] + +>>>> Web edits are single-file anyway, so I wouldn't expect web reverts +>>>> to handle the multi-file case. OTOH, I've sometimes wished ikiwiki +>>>> had its own history browser (somewhere down my todo list). --[[schmonz]] + +>>>> Yup, having a possibility to revert a single file would suffice. diff --git a/doc/forum/how_do_I_translate_a_TWiki_site.mdwn b/doc/forum/how_do_I_translate_a_TWiki_site.mdwn new file mode 100644 index 000000000..5bfdbb86c --- /dev/null +++ b/doc/forum/how_do_I_translate_a_TWiki_site.mdwn @@ -0,0 +1,44 @@ +[[!meta date="2006-12-19 09:56:21 +0000"]] + +# Excellent - how do I translate a TWiki site? + +I just discovered ikiwiki quite by chance, I was looking for a console/terminal +menu system and found pdmenu. So pdmenu brought me to here and I've found ikiwiki! +It looks as if it's just what I've been wanting for a long time. I wanted something +to create mostly text web pages which, as far as possible, have source which is human +readable or at least in a standard format. ikiwiki does this twice over by using +markdown for the source and producing static HTML from it. + +I'm currently using TWiki and have a fair number of pages in that format, does +anyone have any bright ideas for translating? I can knock up awk scripts fairly +easily, perl is possible (but I'm not strong in perl). + +> Let us know if you come up with something to transition from the other +> format. Another option would be writing a ikiwiki plugin to support the +> TWiki format. --[[Joey]] + +> Jamey Sharp and I have a set of scripts in progress to convert other wikis to ikiwiki, including history, so that we can migrate a few of our wikis. We already have support for migrating MoinMoin wikis to ikiwiki, including conversion of the entire history to Git. We used this to convert the [XCB wiki](http://xcb.freedesktop.org/wiki/) to ikiwiki; until we finalize the conversion and put the new wiki in place of the old one, you can browse the converted result at <http://xcb.freedesktop.org/ikiwiki>. We already plan to add support for TWiki (including history, since you can just run parsecvs on the TWiki RCS files to get Git), so that we can convert the [Portland State Aerospace Society wiki](http://psas.pdx.edu) (currently in Moin, but with much of its history in TWiki, and with many of its pages still in TWiki format using Jamey's TWiki format for MoinMoin). +> +> Our scripts convert by way of HTML, using portions of the source wiki's code to render as HTML (with some additional code to do things like translate MoinMoin's `\[[TableOfContents]]` to ikiwiki's `\[[!toc ]]`), and then using a modified [[!cpan HTML::WikiConverter]] to turn this into markdown and ikiwiki. This produces quite satisfactory results, apart from things that don't have any markdown equivalent and thus remain HTML, such as tables and definition lists. Conversion of the history occurs by first using another script we wrote to translate MoinMoin history to Git, then using our git-map script to map a transformation over the Git history. +> +> We will post the scripts as soon as we have them complete enough to convert our wikis. +> +> -- [[JoshTriplett]] + +>> Thanks for an excellent Xmas present, I will appreciate the additional +>> users this will help switch to ikiwiki! --[[Joey]] + + +>> Sounds great indeed. Learning from [here](http://www.bddebian.com/~wiki/AboutTheTWikiToIkiwikiConversion/) that HTML::WikiConverter needed for your conversion was not up-to-date on Debian I have now done an unofficial package, including your proposed Markdown patches, apt-get'able at <pre>deb http://debian.jones.dk/ sid wikitools</pre> +>> -- [[JonasSmedegaard]] + + +>>I see the "We will post the scripts ...." was committed about a year ago. A current site search for "Moin" does not turn them up. Any chance of an appearance in the near (end of year) future? +>> +>> -- [[MichaelRasmussen]] + +>>> It appears the scripts were never posted? I recently imported my Mediawiki site into Iki. If it helps, my notes are here: <http://iki.u32.net/Mediawiki_Conversion> --[[sabr]] + +>>>>> The scripts have been posted now, see [[joshtriplett]]'s user page, +>>>>> and I've pulled together all ways I can find to [[convert]] other +>>>>> systems into ikiwiki. --[[Joey]] diff --git a/doc/forum/how_to_add_post_titles_in_ikiwiki_blog__63__.mdwn b/doc/forum/how_to_add_post_titles_in_ikiwiki_blog__63__.mdwn new file mode 100644 index 000000000..68eb06c4c --- /dev/null +++ b/doc/forum/how_to_add_post_titles_in_ikiwiki_blog__63__.mdwn @@ -0,0 +1,28 @@ +Look at these two blogs: + +1) http://ciffer.net/~svend/blog/ + +2) http://upsilon.cc/~zack/blog/ + +Well, i set up successfully my blog (i am using inline function in a wiki page) but i have manually to insert blog pos titles and the result is that of blog #2. +Instead i would like to have blog post titles automatically inserted like blog #1 (and they are links too! I want them that way). +I looked in git repo of the two blogs but i couldn't find the answer. +Any help would be really appreciated. + +Thanks! + +Raf + +> Either name the blog post files with the full title you want them to +> have, or use [[ikiwiki/directive/meta]] title to set the title of a blog post. +> +> \[[!meta title="this is my blog post"]] +> +> Either way, the title will automatically be displayed, clickable, at the top. +> (zack has hacked his templates not to do that). --[[Joey]] + +>> Thanks for your answer.<br/> +>> I looked in the [templates](http://git.upsilon.cc/cgi-bin/gitweb.cgi?p=zack-homepage.git;a=tree;f=templates;h=824100e62a06cee41b582ba84fcb9cdd982fe4be;hb=HEAD) folder of zack but couldn't see any hack of that kind.<br/> +>> Anyway, I didn't hack my template...<br/> +>> I will follow your suggestion of using \[[ikiwiki/directive/meta]] title to set titles.<br/> +>> Thanks a lot. --Raf diff --git a/doc/forum/how_to_enable_multimarkdown__63__.mdwn b/doc/forum/how_to_enable_multimarkdown__63__.mdwn new file mode 100644 index 000000000..208aadcb0 --- /dev/null +++ b/doc/forum/how_to_enable_multimarkdown__63__.mdwn @@ -0,0 +1,9 @@ +I enabled multimarkdown in my setup file but I get this message 'remote: multimarkdown is enabled, but Text::MultiMarkdown is not installed'. +I also installed multimarkdown-git for my distro (archlinux), which should take care of installing all required perl modules, I believe. +What am I missing? + +Thanks. + +> You are apparently still missing the [[!cpan Text::MultiMarkdown]] +> perl module. Not being familiar with arch linux, I don't know what +> multimarkdown-git is, so I can't say more than that.. --[[Joey]] diff --git a/doc/forum/how_to_enable_multimarkdown__63__/comment_1_037f858c4d0bcbb708c3efd264379500._comment b/doc/forum/how_to_enable_multimarkdown__63__/comment_1_037f858c4d0bcbb708c3efd264379500._comment new file mode 100644 index 000000000..6045a4a3f --- /dev/null +++ b/doc/forum/how_to_enable_multimarkdown__63__/comment_1_037f858c4d0bcbb708c3efd264379500._comment @@ -0,0 +1,14 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawlzADDUvepOXauF4Aq1VZ4rJaW_Dwrl6xE" + nickname="Dário" + subject="comment 1" + date="2010-07-15T15:37:31Z" + content=""" +multimarkdown-git is a package build that fetches the git version of multimarkdown. +It should install Text::Markdown I believe. +I tried to install it by hand on the cpan command line but it didn't work either: +perl -MCPAN -e shell +install Text::MultiMarkdown + +says couldn't run make file or something. +"""]] diff --git a/doc/forum/how_to_enable_multimarkdown__63__/comment_2_b7d512a535490dabf8d6ce55439741c7._comment b/doc/forum/how_to_enable_multimarkdown__63__/comment_2_b7d512a535490dabf8d6ce55439741c7._comment new file mode 100644 index 000000000..804b71c67 --- /dev/null +++ b/doc/forum/how_to_enable_multimarkdown__63__/comment_2_b7d512a535490dabf8d6ce55439741c7._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://joey.kitenet.net/" + nickname="joey" + subject="comment 2" + date="2010-07-16T19:44:55Z" + content=""" +All I can tell you is that, if multimarkdown is correctly installed (ie, if `perl -e 'use Text::MultiMarkdown'` runs successfully), ikiwiki can use it. +"""]] diff --git a/doc/forum/how_to_load_an_external_page_and_still_have_it_under_ikiwiki_template.mdwn b/doc/forum/how_to_load_an_external_page_and_still_have_it_under_ikiwiki_template.mdwn new file mode 100644 index 000000000..a747911a5 --- /dev/null +++ b/doc/forum/how_to_load_an_external_page_and_still_have_it_under_ikiwiki_template.mdwn @@ -0,0 +1,3 @@ +OK, probably title is bit confusing. Basically I'd like to be able to keep my left hand side menu, which is part of the template, and at the same time load let's say forum on the right hand side, which sits on a separate domain. Is it possible then to construct template that for some special links it runs as lets say in *frameset* mode? + +> I think I'll have to use [[ikiwiki/directive/pagetemplate]] and this <http://stackoverflow.com/questions/153152/resizing-an-iframe-based-on-content> solution diff --git a/doc/forum/how_to_login_as_admin.mdwn b/doc/forum/how_to_login_as_admin.mdwn new file mode 100644 index 000000000..807f82501 --- /dev/null +++ b/doc/forum/how_to_login_as_admin.mdwn @@ -0,0 +1,18 @@ +I even managed to set up ikiwiki so it works fine with git; but how on earth do +I log in as an administrator? In the .setup file the admin user is set to +'zimek' but when I go and register 'zimek' on the web it appears as normal user +not the administrator. What am I missing? + +> That's really all there is to it. The [[automatic_setup|setup]] script +> registers the admin user for you before the wiki goes live. If you didn't +> use it, registering the right account name will get you the admin account. +> +> The name is case sensative, perhaps you really spelled one of them `Zimek`? +> +> Or maybe you're the admin, and don't know it? Everything looks the same for the admin, +> except they can edit even locked pages, and can access the websetup interface from their +> Preferences page, if you have that plugin enabled. --[[Joey]] + +>> Maybe I'm indeed. I know that I've disabled all the plugins while installing ikiwiki. Checking it now ;-) + +>> Yup, I'm the God of my ikiwiki. (Thanks) diff --git a/doc/forum/how_to_setup_ikiwiki_on_a_remote_host.mdwn b/doc/forum/how_to_setup_ikiwiki_on_a_remote_host.mdwn new file mode 100644 index 000000000..1c0f8f561 --- /dev/null +++ b/doc/forum/how_to_setup_ikiwiki_on_a_remote_host.mdwn @@ -0,0 +1,35 @@ +Hi all! +I really like ikiwiki and i tested it on my local machine but i have one question that i can't answer reading documentation (my fault of course)... +I have an account and some space on a free hosting service. +Now, i want to put my ikiwiki on this remote web space so that i can browse it from wherever i want. +I have my source dir and my git dir on my local machine. +How can i upload my ikiwiki on the remote host and manage it via git as i can do when i test it locally? +Where is specified? Where can i find documentation about it? + +Thanks in advance! + +Pab + +> There are several ways to accomplish this, depending on what you really +> want to do. +> +> If your goal is to continue generating the site locally, but then +> transfer it to the remote host for serving, you could use the +> [[plugins/rsync]] plugin. +> +> If your goal is to install and run the ikiwiki software on the remote host, +> then you would follow a similar path to the ones described in these tips: +> [[tips/nearlyfreespeech]] [[tips/DreamHost]]. Or even [[install]] ikiwiki +> from a regular package if you have that kind of access. Then you could +> push changes from your local git to git on the remote host to update the +> wiki. [[tips/Laptop_wiki_with_git]] explains one way to do that. +> --[[Joey]] + +Thanks a lot for your answer. +rsync plugin would be perfect but... how would i manage blog post? +I mean... is it possible to manage ikiwiki blog too with rsync plugin in the way you told me? --Pab + +> If you want to allow people to make comments on your blog, no, the rsync plugin will not help, since it will upload a completely static site where nobody can make comments. Comments require a full IkiWiki setup with CGI enabled, so that people add content (comments) from the web. --[[KathrynAndersen]] + +Ok, i understand, thanks. +Is there any hosting service that permits to have a full installation of iwkiwiki or i am forced to get a vps or to mantain a personal server for that? --Pab diff --git a/doc/forum/html_source_pages_in_version_3.20100704.mdwn b/doc/forum/html_source_pages_in_version_3.20100704.mdwn new file mode 100644 index 000000000..7a620fd57 --- /dev/null +++ b/doc/forum/html_source_pages_in_version_3.20100704.mdwn @@ -0,0 +1,8 @@ +Is this different from using the html/rawhtml plugins? + +> I suppose you're talking about this: + + * po: Added support for .html source pages. (intrigeri) + +> That means the [[plugins/po]] plugin is able to translate html pages +> used by the [[plugins/html]] plugin. --[[Joey]] diff --git a/doc/forum/ikiwiki_and_big_files.mdwn b/doc/forum/ikiwiki_and_big_files.mdwn new file mode 100644 index 000000000..cd41d9fce --- /dev/null +++ b/doc/forum/ikiwiki_and_big_files.mdwn @@ -0,0 +1,102 @@ +My website has 214 hand written html, 1500 of pictures and a few, err sorry, 114 +video files. All this takes around 1.5 GB of disk space at the moment. +Plain html files take 1.7 MB and fit naturally into git. + +But what about the picture and video files? + +Pictures are mostly static and rarely need to be edited after first upload, +wasting a megabyte or two after an edit while having them in git doesn't really matter. +Videos on the other hand are quite large from megabytes to hundreds. Sometimes +I re-encode them from the original source with better codec parameters and just +replace the files under html root so they are accessible from the same URL. +So having a way to delete a 200 MB file and upload a new one with same name and access URL +is what I need. And it appears git has trouble erasing commits from history, or requires +some serious gitfoo and good backups of the original repository. + +So which ikiwiki backend could handle piles of large binary files? Or should I go for a separate +data/binary blob directory next to ikiwiki content? + +Further complication is my intention to keep URL compatibility with old handwritten and ikiwiki +based site. Sigh, tough job but luckily just a hobby. + +[-Mikko](http://mcfrisk.kapsi.fi) + +ps. here's how to calculate space taken by html, picture and video files: + + ~/www$ unset sum; for size in $( for ext in htm html txt xml log; \ + do find . -iname "*$ext" -exec stat -c "%s" \{\} \; ; done | xargs ); \ + do sum=$(( $sum + $size )); done ; echo $sum + 1720696 + ~/www$ unset sum; for size in $( for ext in jpg gif jpeg png; \ + do find . -iname "*$ext" -exec stat -c "%s" \{\} \; ; done | xargs ); \ + do sum=$(( $sum + $size )); done ; echo $sum + 46032184 + ~/www$ unset sum; for size in $( for ext in avi dv mpeg mp4; \ + do find . -iname "*$ext" -exec stat -c "%s" \{\} \; ; done | xargs ); \ + do sum=$(( $sum + $size )); done ; echo $sum + 1351890888 + +> One approach is to use the [[plugins/underlay]] plugin to +> configure a separate underlay directory, and put the large +> files in there. Those files will then be copied to the generated +> wiki, but need not be kept in revision control. (Or could be +> revision controlled in a separate repository -- perhaps one using +> a version control system that handles large files better than git; +> or perhaps one that you periodically blow away the old history to +> in order to save space.) +> +> BTW, the `hardlink` setting is a good thing to enable if you +> have large files, as it saves both disk space and copying time. +> --[[Joey]] + +Can underlay plugin handle the case that source and destination directories +are the same? I'd rather have just one copy of these underlay files on the server. + +> No, but enabling hardlinks accomplishes the same effect. --[[Joey]] + +And did I goof in the setup file since I got this: + + $ ikiwiki -setup blog.setup -rebuild --verbose + Can't use string ("/home/users/mcfrisk/www/blog/med") as an ARRAY ref while + "strict refs" in use at + /home/users/mcfrisk/bin/share/perl/5.10.0/IkiWiki/Plugin/underlay.pm line 41. + $ grep underlay blog.setup + add_plugins => [qw{goodstuff websetup comments blogspam html sidebar underlay}], + underlaydir => '/home/users/mcfrisk/bin/share/ikiwiki/basewiki', + # underlay plugin + # extra underlay directories to add + add_underlays => '/home/users/mcfrisk/www/blog/media', + $ egrep "(srcdir|destdir)" blog.setup + srcdir => '/home/users/mcfrisk/blog', + destdir => '/home/users/mcfrisk/www/blog', + # allow symlinks in the path leading to the srcdir (potentially insecure) + allow_symlinks_before_srcdir => 1, + # directory in srcdir that contains directive descriptions + +-Mikko + +> The plugin seems to present a bad default value in the setup file. +> (Fixed in git.) A correct configuration would be: + + add_underlays => ['/home/users/mcfrisk/www/blog/media'], + +Umm, doesn't quite fix this yet: + + $ ikiwiki -setup blog.setup -v + Can't use an undefined value as an ARRAY reference at /home/users/mcfrisk/bin/share/perl/5.10.0/IkiWiki + /Plugin/underlay.pm line 44. + $ grep underlay blog.setup + add_plugins => [qw{goodstuff websetup comments blogspam html sidebar underlay}], + underlaydir => '/home/users/mcfrisk/bin/share/ikiwiki/basewiki', + # underlay plugin + # extra underlay directories to add + add_underlays => ['/home/users/mcfrisk/www/blog/media'], + $ ikiwiki --version + ikiwiki version 3.20091032 + +-Mikko + +> Yeah, I've fixed that in git, but you can work around it with this: +> --[[Joey]] + + templatedirs => [], diff --git a/doc/forum/ikiwiki_development_environment_tips.mdwn b/doc/forum/ikiwiki_development_environment_tips.mdwn new file mode 100644 index 000000000..91ccc6d6e --- /dev/null +++ b/doc/forum/ikiwiki_development_environment_tips.mdwn @@ -0,0 +1,44 @@ +I haven't settled on a comfortable/flexible/quick development environment for hacking on ikiwiki. The VM I host my web pages on is not fast enough to use for RAD and ikiwiki. For developing plugins, it seems a bit heavy-weight to clone the entire ikiwiki repository. I haven't managed to get into a habit of running a cloned version of ikiwiki from it's own dir, rather than installing it (If that's even possible). The ikiwiki site source (source ./doc) is quite large and not a great testbed for hacking (e.g. if you are working on a plugin you need a tailored test suite for that plugin). + +Does anyone have a comfortable setup or tips they would like to share? -- [[Jon]] + +> I've just been setting `libdir` in an existing wiki's setup file. When the plugin's in a decent state, I copy it over to a git checkout and commit. For the plugins I've been working on (auth and VCS), this has been just fine. Are you looking for something more? --[[schmonz]] + +>> I think this suffers from two problems. Firstly, unless you are tracking git +>> master in your existing wiki, there's the possibility that your plugin will +>> not work with a more modern version of ikiwiki (or that it would benefit +>> from using a newly added utility subroutine or similar). + +>>> Unlikely. I don't make changes to the plugin interface that break +>>> existing plugins. (Might change non-exported `IkiWiki::` things +>>> from time to time.) --[[Joey]] + +>> Second, sometimes I +>> find that even writing a plugin can involve making minor changes outside of +>> the plugin code (bug fixes, or moving functionality about). So, I think +>> having some kind of environment built around a git checkout is best. +>> +>> However, this does not address the issue of the tedium writing/maintaining a +>> setup file for testing things. +>> +>> I think I might personally benefit from a more consistent environment (I +>> move from machine-to-machine frequently). -- [[Jon]] + +> If you set `libdir` to point to a checkout of ikiwiki's git repository, +> it will override use of the installed version of ikiwiki, so ikiwiki will +> immediatly use any changed or new `.pm` files (with the exception of +> IkiWiki.pm), and you can use git to manage it all without an installation +> step. If I am modifying IkiWiki.pm, I generally symlink it from +> `/usr/share/perl5/IkiWiki.pm` to my git reporisitory. Granted, not ideal. +> +> I often use my laptop's local version of my personal wiki for testing. +> It has enough stuff that I can easily test most things, and if I need +> a test page I just dump test cases on the sandbox. I can make +> any changes necessary during testing and then `git reset --hard +> origin/master` to avoid publishing them. +> +> If the thing I'm testing involves templates, or underlays, +> I will instead use ikiwiki's `docwiki.setup` for testing, modifying it as +> needed, since it is preconfigured to use the templates and underlays +> from ikiwiki's source repository. +> --[[Joey]] diff --git a/doc/forum/ikiwiki_over_database__63__.wiki b/doc/forum/ikiwiki_over_database__63__.wiki index ff123e98d..a70f9c989 100644 --- a/doc/forum/ikiwiki_over_database__63__.wiki +++ b/doc/forum/ikiwiki_over_database__63__.wiki @@ -1 +1,11 @@ Is there here any possibility to modifying ikiwiki (via plugin) for store pages in database. I'm thinking about storing pages in sqlite or mysql for serving it much faster. The idea is from sputnik.org [http://sputnik.freewisdom.org/] but with perl ;-). Could we integrate the sputnik code in ikiwiki as a solution? + +----- + +ikiwiki generates static pages in a filesystem. It's responsible for editing and regenerating them, but they're served by any old web server. If you go to the trouble of stuffing the generated pages into a database, you'll need to go to further trouble to serve them back out somehow: write your own web server, perhaps, or a module for a particular web server. Either way you'll have sacrificed ikiwiki's interoperability, and it's not at all clear (since you're adding, in the best case, one layer of indirection reading the generated files) you'll have gained any improved page-serving performance. If it's source pages you want to store in a database, then you lose the ability to do random Unixy things to source pages, including managing them in a revision control system. + +Static HTML pages in a filesystem and the ability to do random Unixy things are two of the uniquely awesome features of ikiwiki. It's probably possible to do what you want, but it's unlikely that you really want it. I'd suggest you either get to know ikiwiki better, or choose one of the many wiki implementations that already works as you describe. --[[Schmonz]] + +--- + +Thanks, [[Schmonz]]. You clarify me much things,.... Xan. diff --git a/doc/forum/ikiwiki_vim_syntaxfile.mdwn b/doc/forum/ikiwiki_vim_syntaxfile.mdwn new file mode 100644 index 000000000..e6942cd2d --- /dev/null +++ b/doc/forum/ikiwiki_vim_syntaxfile.mdwn @@ -0,0 +1,26 @@ +See the new syntax file [[here|tips/vim_syntax_highlighting]]. It fixes both of +the problems reported below. + +---- + +Hi all, + +I'm teaching myself how to write syntax files for vim by fixing several issues +(and up to certain extent, taking over the maintenance) of the vim syntax +(highlighting) file for ikiwiki. + +I'd like you to document here which problems you have found, so I can hunt them +and see if I can fix them. + +## Problems Found + + * Arguments of directives with a value of length 1 cause the following text to + be highlighted incorrectly. Example: + + [[!directive param1="val1" param2="1"]] more text ... + + * A named wikilink in a line, followed by text, and then another wikilink, + makes the text in between the links to be incorrectly highlighted. Example: + + \[[a link|alink]] text that appears incorrectly .... \[[link]] + diff --git a/doc/forum/installation_and_setup_questions.mdwn b/doc/forum/installation_and_setup_questions.mdwn new file mode 100644 index 000000000..50633ec3f --- /dev/null +++ b/doc/forum/installation_and_setup_questions.mdwn @@ -0,0 +1,52 @@ +[[!meta date="2007-03-02 00:57:08 +0000"]] + +Ikiwiki creates a .ikiwiki directory in my wikiwc working directory. Should I +"svn add .ikiwiki" or add it to svn:ignore? + +> `.ikiwiki` is used by ikiwiki to store internal state. You can add it to +> svn:ignore. --[[Joey]] +> > Thanks a lot. + +Is there an easy way to log via e-mail to some webmaster address, instead +of via syslog? + +> Not sure why you'd want to do that, but couldn't you use a tool like +> logwatch to mail selected lines from the syslog? --[[Joey]] + +> > The reason is that I'm not logged in on the web server regularly to +> > check the log files. I'll see whether I can install a logwatch instance. + +I'm trying to install from scratch on a CentOS 4.6 system. I installed perl 5.8.8 from source and then added all the required modules via CPAN. When I build ikiwiki from the tarball, I get this message: + + rendering todo/calendar_--_archive_browsing_via_a_calendar_frontend.mdwn + *** glibc detected *** double free or corruption (!prev): 0x0922e478 *** + make: *** [extra_build] Aborted + +I'm kind of at a loss how to track this down or work around it. Any suggestions? --Monty + +> All I can tell you is that it looks like a problem with your C library or +> perl. Little perl programs like ikiwiki should only be able to trigger +> such bugs, not contain them. :-) Sorry I can't be of more help. +> --[[Joey]] + +> I had a similar problem after upgrading to the latest version of +> Text::Markdown from CPAN. You might try either looking for a Markdown +> package for CentOS or using the latest version of John Gruber's +> Markdown.pl: +> <http://daringfireball.net/projects/downloads/Markdown_1.0.2b8.tbz> +> --[[JasonBlevins]], April 1, 2008 18:22 EDT + +>> Unfortunately I couldn't find a CentOS package for markdown, and I +>> couldn't quite figure out how to use John Gruber's version instead. +>> I tried copying it to site_perl, etc., but the build doesn't pick +>> it up. For now I can just play with it on my Ubuntu laptop for which +>> the debian package installed flawlessly. I'll probably wait for an +>> updated version of Markdown to see if this is fixed in the future. +>> --Monty + +>I suggest that you pull an older version of Text::Markdown from CPAN. I am using <http://backpan.perl.org/authors/id/B/BO/BOBTFISH/Text-Markdown-1.0.5.tar.gz> and that works just fine. +>There is a step change in version and size between this version (dated 11Jan2008) and the next version (1.0.12 dated 18Feb2008). I shall have a little look to see why, in due course. +>Ubuntu Hardy Heron has a debian package now, but that does not work either. +> --Dirk 22Apr2008 + +> This might be related to [Text::Markdown bug #37297](http://rt.cpan.org/Public/Bug/Display.html?id=37297).--ChapmanFlack 9Jul2008 diff --git a/doc/forum/installation_as_non-root_user.mdwn b/doc/forum/installation_as_non-root_user.mdwn new file mode 100644 index 000000000..4997af2ac --- /dev/null +++ b/doc/forum/installation_as_non-root_user.mdwn @@ -0,0 +1,7 @@ +I'd like to install ikiwiki as a non-root user. I can plow through getting all the +perl dependencies installed because that's well documented in the perl world, +but I don't know how to tell ikiwiki to install somewhere other than / --BrianWilson + +> Checkout the tips section for [[tips/DreamHost]]. It should do the trick. --MattReynolds + +[[!meta date="2008-01-13 16:02:52 -0500"]] diff --git a/doc/forum/installation_of_selected_docs.mdwn b/doc/forum/installation_of_selected_docs.mdwn new file mode 100644 index 000000000..81dd1ee00 --- /dev/null +++ b/doc/forum/installation_of_selected_docs.mdwn @@ -0,0 +1,29 @@ +[[!meta date="2007-09-06 19:47:23 +0000"]] + +# Installation of selected docs (html) + +The latest release has around 560 files (over 2MB) in html. + +Any suggestions or ideas on limiting what html is installed? + +For example, I don't see value in every ikiwiki install out there to also install personal "users" ikiwiki pages. + +For now I copy ikiwiki.setup. And then use pax with -L switch to copy the targets of the symlinks of the basewiki. + +I was thinking of making a list of desired documents from the html directory to install. + +--JeremyReed + +> You don't need any of them, unless you want to read ikiwiki's docs locally. +> +> I don't understand why you're installing the basewiki files manually; +> ikiwiki has a Makefile that will do this for you. --[[Joey]] + +>> The Makefile's install doesn't do what I want so I use different installer for it. +>> It assumes wrong location for man pages for me. (And it should consider using INSTALLVENDORMAN1DIR and +>> MAN1EXT but I don't know about section 8 since I don't know of perl value for that.) +>> I don't want w3m cgi installed; it is optional for my package. +>> I will just patch for that instead of using my own installer. +>> Note: I am working on the pkgsrc package build specification for this. This is for creating +>> packages for NetBSD, DragonFly and other systems that use pkgsrc package system. +>> --JeremyReed diff --git a/doc/forum/link_autocompletion_in_vim.mdwn b/doc/forum/link_autocompletion_in_vim.mdwn new file mode 100644 index 000000000..7d3ed8b02 --- /dev/null +++ b/doc/forum/link_autocompletion_in_vim.mdwn @@ -0,0 +1,17 @@ +I extended the functionality of the [ikiwiki-nav plugin](http://www.vim.org/scripts/script.php?script_id=2968) +(see [[here|tips/follow_wikilinks_from_inside_vim]]) to allow completion of +wikilinks from inside vim, through the omnicompletion mechanism. + +It still has some bugs, but is usable, and will not destroy your data. It can +only complete links whose definition (text) is on a single line, and still can't +handle "named links" (`\[\[text|link\]\]`). + +I'd love to hear suggestions for improvement for it, and bug reports ;) For +example, regarding how are sorted and presented the available completions +(dates, alphabetically, etc). + +You can find a tarball for it +[here](http://devnull.li/~jerojasro/ikiwiki-nav-dev.tar.gz). To install it, +extract the tarball contents in your `.vim` directory. + +--[[jerojasro]] diff --git a/doc/forum/link_to_an_image_inside_the_wiki_without_inlining_it.mdwn b/doc/forum/link_to_an_image_inside_the_wiki_without_inlining_it.mdwn new file mode 100644 index 000000000..e92cc1b1c --- /dev/null +++ b/doc/forum/link_to_an_image_inside_the_wiki_without_inlining_it.mdwn @@ -0,0 +1,69 @@ +how can I create a link to an image which is part of the wiki, without having it inserted in my page? + +I tought this: + + \[[look at this|img/lolcat.png]] + +would work, but it doesn't. + +Any hints? --[[jerojasro]] + +> Well, currently the syntax above will display the image +> inline with the specified link text used as an alt attribute. Although +> that does not seem to be documented anywhere. +> +> A few places that use that (found with `git grep '\[\[' | egrep 'png|gif|jpeg|jpg' |grep \|`): +> +> * [[logo]] uses it to provide useful alt texts for the logos. (This +> could easily be changed to use [[ikiwiki/directive/img]] though.) +> * The `change.tmpl` template uses it to display +> the [[diff|wikiicons/diff.png]] with a very useful "diff" alt text. +> Using [[ikiwiki/directive/img]] here would mean that the +> [[plugins/recentchanges]] plugin would depend upon the img +> plugin. +> +> I do like your suggestion, it makes more sense than the current behavior. +> I'm not sure the transition pain to get from here to there is worth it, +> though. +> +> More broadly, if I were writing ikiwiki now, I might choose to leave out the +> auto-inlining of images altogether. In practice, it has added a certian level +> of complexity to ikiwiki, with numerous plugins needing to specify +> `noimageinline` to avoid accidentially inlining an image. And there has not +> been a lot of payoff from having the auto-inlining feature implicitly +> available most places. And the img directive allows much needed control over +> display, so it would be better for users to not have to worry about its +> lesser cousin. But the transition from here to *there* would be another order +> of pain. +> +> Anyway, the cheap and simple answer to your question is to use html +> or markdown instead of a [[ikiwiki/wikilink]]. Ie, +> `[look at this](img/lolcat.jpg)`. --[[Joey]] + +> > thanks a lot, that's a quite straightforward solution. I actually wrote a +> > broken plugin to do that, and now I can ditch it --[[jerojasro]] + +>>> The plugin approach is not a bad idea if you want either the ability +>>> to: +>>> +>>> * Have things that are wikilink-aware (like [[plugins/brokenlinks]] +>>> treat your link to the image as a wikilink. +>>> * Use standard wikilink path stuff (and not have to worry about +>>> a relative html link breaking if the page it's on is inlined, for +>>> example). +>>> +>>> I can help you bang that plugin into shape if need be. --[[Joey]] + +>>>> both my plugin and your suggestion yield broken html links when inlining the page (although probably that's what is expected from your suggestion (`[]()`)) +>>>> +>>>> I thought using the `bestlink` function would take care of that, but alas, it doesn't. +>>>> Get the "plugin" [here](http://devnull.li/~jerojasro/files/linktoimgonly.pm), see the broken +>>>> links generated [here](http://devnull.li/~jerojasro/blog/posts/job_offers/) and the source +>>>> file for that page [here](http://git.devnull.li/cgi-bin/gitweb.cgi?p=blog-jerojasro.git;a=blob;f=posts/job_offers.mdwn;hb=HEAD) --[[jerojasro]] + +>>>>> Use this --[[Joey]] + + return htmllink($params{page}, $params{destpage}, $params{"img"}, + linktext => $params{text}, + noimageinline => 1); + diff --git a/doc/forum/missing_pages_redirected_to_search-SOLVED.mdwn b/doc/forum/missing_pages_redirected_to_search-SOLVED.mdwn new file mode 100644 index 000000000..3af83396c --- /dev/null +++ b/doc/forum/missing_pages_redirected_to_search-SOLVED.mdwn @@ -0,0 +1,36 @@ +Is it possible to have any missing pages(404's) redirected to the search(omega) ? +So if someone comes to my site with http://example.com/foo_was_here it would result in 'foo_was_here' being passed as a search parameter to omega ? --[Mick](http://www.lunix.com.au) + +##DONE + +I use nginx instead of apache. +Just add the following to the `server` block outside of any location block in nginx.conf +You must also make sure you have setup and enabled the search plugin(omega) + + error_page 404 /ikiwiki.cgi?P=$uri; + + +My full nginx.conf + + server { + listen [::]:80; #IPv6 capable + server_name www.lunix.com.au; + access_log /var/log/nginx/www.lunix.com.au-access.log main; + error_log /var/log/nginx/www.lunix.com.au-error.log warn; + error_page 404 /ikiwiki.cgi?P=$uri; + + location / { + root /home/lunix/public_html/lunix; + index index.html index.htm; + } + + location ~ ikiwiki\.cgi$ { + root /home/lunix/public_html/lunix; + include /etc/nginx/fastcgi_params.cgi; + + fastcgi_pass 127.0.0.1:9999; + fastcgi_param SCRIPT_FILENAME /home/lunix/public_html/lunix$fastcgi_script_name; # same path as above + } + } + + diff --git a/doc/forum/multi-user_setup_of_ikiwiki__44___gitosis_and_apache2_in_Debian_Sid.mdwn b/doc/forum/multi-user_setup_of_ikiwiki__44___gitosis_and_apache2_in_Debian_Sid.mdwn index fa8b5010e..b8e28e0a3 100644 --- a/doc/forum/multi-user_setup_of_ikiwiki__44___gitosis_and_apache2_in_Debian_Sid.mdwn +++ b/doc/forum/multi-user_setup_of_ikiwiki__44___gitosis_and_apache2_in_Debian_Sid.mdwn @@ -65,3 +65,32 @@ Could you please enlighten me. It should be possible seeing for example this sit Thanks in advance, --[[PaulePanter]] + +--- + +## Current Working Notes + +I've spent a little time getting this working and I wanted to share my notes on this, for those that come after me. + +### My Setup + +- Debian Lenny + +- Gitosis (hand compiled, for no good reason, but it's the same version as in the repository) + +- Ikiwiki 3.12 installed using packages from Sid + +### What Works + +- Everything needs to be chowned git:git (or gitosis:gitosis) by whatever gitosis runs with. This includes: + - the bare repository (as always) + - the srcdir + - the destdir + +- Ikiwiki needs to run in gitosis' group (eg. git in my case, but probably gitosis in yours) + +- ikiwiki.cgi needs be set with the wrapper mode 6755. + +-- [[tychoish]] + + diff --git a/doc/forum/multi_domain_setup_possible__63__.mdwn b/doc/forum/multi_domain_setup_possible__63__.mdwn new file mode 100644 index 000000000..01b31aafb --- /dev/null +++ b/doc/forum/multi_domain_setup_possible__63__.mdwn @@ -0,0 +1,15 @@ +Hi! I am searching for a replacement of my blog and webpages made off static HTML with just some custom PHP around it for years already. ikiwiki seems to be one of the hot candidates, since it uses a RCS. + +I would like to have a multi domain setup like this: + +- myname.private.de => more of a personal page +- professional.de => more of my professional work related page +- and possibly others + +Now when I write a blog entry about some Linux, Debian or KDE stuff, I possibly would like to have it shown on my private and my professional domain. + +And I might like to use some kind of inter wiki links now and then. + +Is such a setup possible? I thought about have a big wiki with Apache serving sub directories from it under different domains, but then wiki links like would not work. + +Maybe having the same blog entry, same content on several domains is not such a hot idea, but as long as I do not see a problem with it, I'd like to do it. diff --git a/doc/forum/multi_domain_setup_possible__63__/comment_1_43f5df30d09046ccc4f7c44703979a11._comment b/doc/forum/multi_domain_setup_possible__63__/comment_1_43f5df30d09046ccc4f7c44703979a11._comment new file mode 100644 index 000000000..5b00272b3 --- /dev/null +++ b/doc/forum/multi_domain_setup_possible__63__/comment_1_43f5df30d09046ccc4f7c44703979a11._comment @@ -0,0 +1,17 @@ +[[!comment format=mdwn + username="http://joey.kitenet.net/" + nickname="joey" + subject="branches" + date="2010-08-15T16:06:43Z" + content=""" +This is where the git backend (or bzr if you prefer) shines. Make a site, and then branch it to a second site, and put your personal type stuff on the branch. cherry-pick or merge changes from one branch to another. + +The possibility to do this kind of thing is why our recently launched Ikiwiki hosting service is called +[Branchable.com](http://branchable.com). It makes it easy to create branches of a Ikiwiki site hosted +there: <http://www.branchable.com/tips/branching_an_existing_site/> +(Merging between branches need manual git, for now.) + +BTW, for links between the branched wikis you can just use the [[plugins/shortcut]] plugin. + +--[[Joey]] +"""]] diff --git a/doc/forum/multi_domain_setup_possible__63__/comment_2_75d6581f81b71fb8acbe3561047ea759._comment b/doc/forum/multi_domain_setup_possible__63__/comment_2_75d6581f81b71fb8acbe3561047ea759._comment new file mode 100644 index 000000000..473f52f5c --- /dev/null +++ b/doc/forum/multi_domain_setup_possible__63__/comment_2_75d6581f81b71fb8acbe3561047ea759._comment @@ -0,0 +1,16 @@ +[[!comment format=mdwn + username="http://claimid.com/helios" + nickname="helios" + subject="branches" + date="2010-08-15T16:18:35Z" + content=""" +So I I just put a blog entry, which is just a file on both branches. Seems I have to learn cherry-picking and merging only some changes. + +Still I am duplicating files then and when I edit one file I have to think to also edit the other one or merge the change to it. I thought of a way to tag a blog entry on which site it should appear. And then I just have to edit one file and contents changes on all sites that share it. + +But then I possibly can do some master blog / shared content branch, so that shared content is only stored once. Then I need to find a way to automatically replicate the changes there to all sites it belongs too. But how do I store it. + +I also thought about just using symlinks for files. Can I have two sites in one repository and symlink shared files stuff around? I know bzr can version control symlinks. + +Hmmm, I think I better read more about branching, cherry-picking and merging before I proceed. I used bzr and git, but from the user interface side of things prefer bzr, which should be fast enough for this use case. +"""]] diff --git a/doc/forum/navigation_of_wiki_pages_on_local_filesystem_with_vim.mdwn b/doc/forum/navigation_of_wiki_pages_on_local_filesystem_with_vim.mdwn new file mode 100644 index 000000000..7bfcf3088 --- /dev/null +++ b/doc/forum/navigation_of_wiki_pages_on_local_filesystem_with_vim.mdwn @@ -0,0 +1,130 @@ +**UPDATE** I have created a [[page|tips/follow_wikilinks_from_inside_vim]] in +the tips section about the plugin, how to get it, install it and use it. Check +that out. --[[jerojasro]] + +I wrote a vim function to help me navigate the wiki when I'm editing it. It extends the 'gf' (goto file) functionality. Once installed, you place the cursor on a wiki page name and press 'gf' (without the quotes); if the file exists, it gets loaded. + +This function takes into account the ikiwiki linking rules when deciding which file to go to. + +> 'gf' gets in the way when there are directories with the same name of a wiki page. The +> function below doesn't implement the linking rules properly (test the link (ignoring case), +> if there is no match ascend the dir. hierarchy and start over, until we reach the root of +> the wiki). I'm rewriting it to follow these rules properly +> +> I think the page for [[LinkingRules|ikiwiki/subpage/linkingrules]] should say that ikiwiki **ascends** +> the dir. hierarchy when looking for a wikilink, not that it **descends** it. Am I correct? --[[jerojasro]] + +>> Conventionally, the root directory is considered to be lower than other +>> directories, so I think the current wording is correct. --[[Joey]] + +let me know what you think + +> " NOTE: the root of the wiki is considered the first directory that contains a +> " .ikiwiki folder, except $HOME/.ikiwiki (the usual ikiwiki libdir) +> +> That's not going to work in all situations; for example, with an ikiwiki which uses git as the backend, the normal setup is that one has +> +> * a bare git repository +> * a git repository which ikiwiki builds the wiki from (which has a .ikiwiki directory in it) +> * an *additional* git repository cloned from the bare repository, which is used for making changes from the command-line rather than the web. It is this repository in which one would be editing files with vim, and *this* repository does not have a .ikiwiki directory in it. It does have a .git directory in the root, however, so I suppose you could use that as a method of detection of a root directory, but of course that would only work for git repositories. +> +> -- [[KathrynAndersen]] +> +>> You are completely right; all of my wikis are compiled both locally and +>> remotely, and so the local repo also has a `.ikiwiki` folder. And that's not the +>> "usual" setup. +>> +>> checking for a `.git` dir would not work when the wiki's source files aren't +>> located at the root of the repo. +>> +>> So, besides of doing a `touch .ikiwiki` at the root of the wiki in your local +>> repo, do you see any alternative? +>> +>> -- [[jerojasro]] + +well. I've rewritten the whole thing, to take into account: + + * file matching ignoring case (MyPage matches mypage.mdwn) + * checking all the way down (up) to the root of the wiki (if there is a link `\[[foo]]` on `a/b/page`), + try `a/b/page/foo`, then `a/b/foo`, and so on, up to `foo` + * the alternate name for a page: when looking for the file for `\[[foo]]`, try both `foo.mdwn` and `foo/index.mdwn` + +you can find the file [here](http://git.devnull.li/cgi-bin/gitweb.cgi?p=vim-jerojasro.git;a=blob;f=.vim/ftplugin/ikiwiki_nav.vim;hb=HEAD). To use it, place it in `$HOME/.vim/ftplugin`. After that, hitting `<CR>` (Enter) in normal mode over a wikilink will take you to that page, if it exists. + +the plugin has, as of now, two problems: + + * doesn't work with wikilinks that take more than one line (though this isn't really that bad) + * it assumes that the root of the wiki is the first directory down the filesystem hierarchy that + has a `.ikiwiki` folder on it. If your copy of the wiki doesn't have it, you must create it for + the plugin to work + +-- [[jerojasro]] + +> Interesting. I was at one point looking at "potwiki.vim", which implements a local wiki and follows CamelCase links, creating new files where necessary etc., to see if it could be adapted for ikiwiki (See [[tips/vim syntax highlighting/discussion]]). I didn't get anywhere. -- [[Jon]] + +>> when I wrote the plugin I also considered the possibility of creating files (and their dirs, if necessary) +>> from new wikilinks; the changes needed to get that working are fairly small -- [[jerojasro]] + +> Seems about ready for me to think about pulling it into ikiwiki +> alongside [[tips/vim_syntax_highlighting/ikiwiki.vim]]. If you'll +> please slap a license on it. :) --[[Joey]] +> +>> GPL version 2 or later (if that doesn't cause any problems here). I'll add it +>> to the file --[[jerojasro]] +>> +>>> I see you've put the plugin on vim.org. Do you think it makes sense to +>>> also include a copy in ikiwiki? --[[Joey]] +>>> +>>>> mmm, no. There would be two copies of it, and the git repo. I'd rather have +>>>> a unique place for the "official" version (vim.org), and another for the dev +>>>> version (its git repo). +>>>> +>>>> actually, I would also suggest to upload the [[`ikiwiki.vim`|tips/vim_syntax_highlighting]] file to vim.org --[[jerojasro]] +>>>>> +>>>>> If you have any interest in maintaining the syntax highlighting +>>>>> plugin and putting it there, I'd be fine with that. I think it needs +>>>>> some slight work to catch up with changes to ikiwiki's directives +>>>>> (!-prefixed now), and wikilinks (able to have spaces now). --[[Joey]] + +<a id='syn-maintenance'> + +>>>>> +>>>>>> I don't really know too much about syntax definitions in vim. But I'll give it a stab. I know it fails when there are 2 \[[my text|link]] wikilinks in the same page. +>>>>>> I'm not promising anything, though ;) --[[jerojasro]] +> +> Also, I have a possible other approach for finding ikiwiki's root. One +> could consider that any subdirectory of an ikiwiki wiki is itself +> a standalone wiki, though probably one missing a toplevel index page. +> The relative wikilinks work such that this assumption makes sense; +> you can build any subdirectory with ikiwiki and probably get something +> reasonable with links that work, etc. +> +> So, if that's the case, then one could say that the directory that the +> user considers to be the toplevel of their wiki is really also a subwiki, +> enclosed in a succession of parents that go all the way down to the root +> directory (or alternatively, to the user's home directory). I think that +> logically makes some sense. +> +> And if that's the case, you can resolve an absolute link by looking for +> the page closest to the root that matches the link. +> +>> I like your idea; it doesn't alter the matching of the relative links, and +>> should work fine with absolute links too. I'll implement it, though I see +>> some potential (but small) issues with it --[[jerojasro]] +> +> It may even make sense to change ikiwiki's own handling of "absolute" +> links to work that way. But even without changing ikiwiki, I think it +> would be a reasonable thing for vim to do. It would only fail in two +> unusual circumstances: +> +> 1. There is a file further down, outside what the user considers +> the wiki, that matches. Say a `$HOME/index.mdwn` +> 2. An absolute link is broken in that the page linked to does +> not exist in the root of the wiki. But it does exist in a subdir, +> and vim would go to that file. +> +> --[[Joey]] +> +>> your approach will add more noise when the plugin grows the page-creation +>> feature, since there will be no real root to limit the possible locations for +>> the new page. But it is far better than demanding for a `.ikiwiki` dir --[[jerojasro]] diff --git a/doc/forum/recentchanges_dir_should_be_under_control_of_RCS__63__.mdwn b/doc/forum/recentchanges_dir_should_be_under_control_of_RCS__63__.mdwn new file mode 100644 index 000000000..2fe97366b --- /dev/null +++ b/doc/forum/recentchanges_dir_should_be_under_control_of_RCS__63__.mdwn @@ -0,0 +1,105 @@ +Hello Joey, + +I noticed that my Ikiwiki started to rebuild pages very slowly after my last changes +when I upgraded Ikiwiki to version 3.20100623. Now I have the latest release 3.20100704, +but it doesn't help me. + +I started to debug the problem and I found that I can see a lot of messages +like below when I try to rebuild my wiki manually: + + svn: '/path/to/ikiwiki/trunk/pages/ostatnie_zmiany' is not a working copy + svn: Can't open file '/path/to/ikiwiki/trunk/pages/ostatnie_zmiany/.svn/entries': No such file or directory + svn log exited 256 + +"ostatnie_zmiany" is a value of `recentchangespage` parameter in my +`ikiwiki.setup` file. It is not under control Subversion I use for Ikiwiki: + + $ svn status pages/ostatnie_zmiany + ? pages/ostatnie_zmiany + + $ ls pages/ostatnie_zmiany/*._change |wc -l + 100 + +`recentchangesnum` parameter has value 100 for me and I noticed that my Ikiwiki +takes a lot of time to parse all `._change` files. Finally it doesn't refresh +/ostatnie_zmiany.html page. + +Do you think I should add `ostatnie_zmiany` directory under control of my +Subversion repo? If it's not necessary, could you please give me any hint +to find a reason of problem with my Ikiwiki? + +My best regards, +Pawel + +> No, the recentchanges pages are automatically generated and should not +> themselves be in revision control. +> +> Ikiwiki has recently started automatically enabing `--gettime`, but +> it should not do it every time, but only on the initial build +> of a wiki. It will print "querying svn for file creation and modification +> times.." when it does this. If it's doing it every time, something +> is wrong. (Specifically, `.ikiwiki/indexdb` must be missing somehow.) +> +> The support for svn with --gettime is rather poor. (While with git it is +> quite fast.) But as it's only supposed to happen on the first build, +> I haven't tried to speed it up. It would be hard to do it fast with svn. +> It would be possible to avoid the warning message above, or even skip +> processing files in directories not checked into svn -- but I'd much +> rather understand why you are seeing this happen on repeated builds. +> --[[Joey]] + +>> Thanks a lot for your reply! I've just checked my `rebuild-pages.sh` +>> script and discovered that it contains +>> `/usr/bin/ikiwiki --setup ikiwiki.setup --gettime` command... :D +>> The warnings disappeared when I removed `--gettime` parameter. +>> Sorry for confusing! :) +>> +>> I have `.ikiwiki/indexdb` file here, but I noticed that it has been +>> modified about 1 minute **after** last Subversion commit: +>> +>> $ LANG=C svn up +>> At revision 5951. +>> +>> $ LANG=C svn log -r 5951 +>> ------------------------------------------------------------------------ +>> r5951 | svn | 2010-07-06 09:02:30 +0200 (Tue, 06 Jul 2010) | 1 line +>> +>> web commit by xahil +>> ------------------------------------------------------------------------ +>> +>> $ LANG=C stat pages/.ikiwiki/indexdb +>> File: `pages/.ikiwiki/indexdb' +>> Size: 184520 Blocks: 368 IO Block: 131072 regular file +>> Device: 2bh/43d Inode: 1931145 Links: 1 +>> Access: (0644/-rw-r--r--) Uid: ( 1005/ svn) Gid: ( 1005/ svn) +>> Access: 2010-07-06 12:06:24.000000000 +0200 +>> Modify: 2010-07-06 09:03:38.000000000 +0200 +>> Change: 2010-07-06 09:03:38.000000000 +0200 +>> +>> I believe it's the time I have to wait to see that my wiki page has been rebuilt. +>> Do you have any idea how to find a reason of that delay? --[[Paweł|ptecza]] + +>>> Well, I hope that your svn post-commit hook is not running your +>>> `rebuild-pages.sh`. That script rebuilds everything, rather than just +>>> refreshing what's been changed. +>>> +>>> Using subversion is not asking for speed. Especially if your svn +>>> repository is on a remote host. You might try disabling +>>> recentchanges and see if that speeds up the refreshes (it will avoid +>>> one `svn log`). +>>> +>>> Otherwise, take a look at [[tips/optimising_ikiwiki]] +>>> for some advice on things that can make ikiwiki run slowly. --[[Joey]] + +>>>> Thanks for the hints! I don't understand it, but it seems that refreshing +>>>> all pages has resolved the problem and now my wiki works well again :) +>>>> +>>>> No, I use `rebuild-pages.sh` script only when I want to rebuild +>>>> my wiki manually, for example when you release new Ikiwiki version +>>>> then I need to update my templates. Some of them have been translated +>>>> to Polish by me. +>>>> +>>>> Fortunately my wiki and its Subversion repo are located on the same host. +>>>> We have a lot of Subversion repos for our projects and I don't want to +>>>> change only wiki repo for better performance. I'm rather satisfied with +>>>> its speed. --[[Paweł|ptecza]] diff --git a/doc/forum/remove_css__63__.mdwn b/doc/forum/remove_css__63__.mdwn new file mode 100644 index 000000000..80da621d6 --- /dev/null +++ b/doc/forum/remove_css__63__.mdwn @@ -0,0 +1,5 @@ +I removed a local.css file and pushed the changes to git but the 'compiled' wiki still shows the same css. +Is this a bug or you are supposed to remove the css by hand? +ikiwiki version 3.20100705 + +> It's a [[bug|bugs/underlaydir_file_expose]]. --[[Joey]] diff --git a/doc/forum/report_pagination.mdwn b/doc/forum/report_pagination.mdwn new file mode 100644 index 000000000..d609fd502 --- /dev/null +++ b/doc/forum/report_pagination.mdwn @@ -0,0 +1,11 @@ +I am thinking of adding pagination to the [[plugins/contrib/report]] plugin, but I'm not sure which is the best approach to take. (By "pagination" I mean breaking up a report into multiple pages with N entries per page.) + +Approaches: + +1. generate additional HTML files on the fly which are placed in the sub-directory for the page the report is on. These are not "pages", they are not under revision control, they aren't in the %pagesources hash etc. But using the `will_render` mechanism assures that they will be removed when they are no longer needed. + +2. create new pages which each have a report directive which shows a subset of the full result; add them to revision control, treat them as full pages. Problems with this are: (a) trying to figure out when to create these new pages and when not to, (b) whether or not these pages can be deleted automatically. + +3. some other approach I haven't thought of. + +I'm afraid that whatever approach I take, it will end up being a kludge. diff --git a/doc/forum/speeding_up_ikiwiki.mdwn b/doc/forum/speeding_up_ikiwiki.mdwn index 0b2164238..799186cf8 100644 --- a/doc/forum/speeding_up_ikiwiki.mdwn +++ b/doc/forum/speeding_up_ikiwiki.mdwn @@ -56,7 +56,7 @@ number is still too large to really visualize: the graphviz PNG and PDF output engines segfault for me, the PS one works but I can't get any PS software to render it without exploding. -Now, the relations in the links hash are not the same thing as IkiWiki's notion of dependencies. Can anyone point me at that data structure / where I might be able to add some debugging foo to generate a graph of it? +Now, the relations in the links hash are not the same thing as Ikiwiki's notion of dependencies. Can anyone point me at that data structure / where I might be able to add some debugging foo to generate a graph of it? Once I've figured out that I might be able to optimize some pagespecs. I understand pagespecs are essentially translated into sequential perl code. I @@ -77,15 +77,14 @@ wrapper. > Dependencies go in the `%IkiWiki::depends` hash, which is not exported. It > can also be dumped out as part of the wiki state - see [[tips/inside_dot_ikiwiki]]. > -> It's a map from page name to increasingly complex pagespec, although -> the `optimize-depends` branch in my git repository changes that to a -> map from a page name to a *list* of pagespecs which are automatically -> or'd together for use (this at least means duplicates can be weeded out). -> -> See [[todo/should_optimise_pagespecs]] for more on that. +> Nowadays, it's a hash of pagespecs, and there +> is also a `IkiWiki::depends_simple` hash of simple page names. > > I've been hoping to speed up IkiWiki too - making a lot of photo albums > with my [[plugins/contrib/album]] plugin makes it pretty slow. > > One thing that I found was a big improvement was to use `quick=yes` on all > my `archive=yes` [[ikiwiki/directive/inline]]s. --[[smcv]] + +> Take a look at [[tips/optimising_ikiwiki]] for lots of helpful advice. +> --[[Joey]] diff --git a/doc/forum/square_brackets_inside_backticks_generates_incorrect_html___40__interpreted_as_wikilinks__41____63__.html b/doc/forum/square_brackets_inside_backticks_generates_incorrect_html___40__interpreted_as_wikilinks__41____63__.html new file mode 100644 index 000000000..fe20a05b1 --- /dev/null +++ b/doc/forum/square_brackets_inside_backticks_generates_incorrect_html___40__interpreted_as_wikilinks__41____63__.html @@ -0,0 +1,19 @@ +the following markdown code +`foo \[["bar"]]` generates the following output: + +foo <span class="createlink"><a href="http://euler/~dabd/wiki/ikiwiki.cgi?page=__34__bar__34__&from=foo&do=create" rel="nofollow">?</a>"bar"</span> + +Perhaps this is a bug in the markdown processor? + +<blockquote> +This has nothing to do with markdown; wikilinks and directives +are not part of markdown, and just get expanded to html before +markdown processing. + +There is a bug open about this: +[[bugs/wiki_links_still_processed_inside_code_blocks]] + +Note that escaping the wikilink with a slash will avoid it being expanded +to html. +--[[Joey]] +</blockquote> diff --git a/doc/forum/suppressing_output_of_pages_included_only_for_their_side_effects.mdwn b/doc/forum/suppressing_output_of_pages_included_only_for_their_side_effects.mdwn new file mode 100644 index 000000000..99784cdd2 --- /dev/null +++ b/doc/forum/suppressing_output_of_pages_included_only_for_their_side_effects.mdwn @@ -0,0 +1,16 @@ +In particular, it's kind of annoying that using the sidebar plugin results in the creation of a free-standing sidebar.html (which in the simplest case of course includes a copy of *its own content* as a sidebar). It would be nice if there were a way to tell Ikiwiki to treat a file like sidebar.mdwn as "inline only": allow its content to be inlined but not to render it separately nor allow linking to it. + +In reading through the code and associated docs, it appears that the ideal method is for the file to be removed from the $changed array by plugin's "needsbuild" hook. Either the sidebar plugin could define such a hook, or perhaps a more general solution is the creation of a meta variable or config file regexp that would handle it according to the user's wishes. + +I'm about ready to code up such a change but want to find out if I'm thinking along the right lines. --[[blipvert]] + +> Internal pages should be able to be used for this, as they are used for +> comments. So you'd have +> `sidebar._mdwn`. However, mwdn would need to be changed to register a +> htmlize hook for the `_mdwn` extension for that to really work. +> +> But, if there's no rendered sidebar page, how can users easily edit the page +> in the web interface? In the specific case of the sidebar, It seems +> better to have the page display something different when built standalone +> than when built as the sidebar. +> --[[Joey]] diff --git a/doc/forum/tag_plugin:_rebuilding_autocreated_pages.mdwn b/doc/forum/tag_plugin:_rebuilding_autocreated_pages.mdwn new file mode 100644 index 000000000..114837031 --- /dev/null +++ b/doc/forum/tag_plugin:_rebuilding_autocreated_pages.mdwn @@ -0,0 +1,11 @@ +I have a bunch of tag pages autogenerated by the tag plugin. As part of a redesign for my wiki, I have changed the `autotag.tmpl` template, but IkiWiki refuses to rebuild existing tag pages using the updated template. I understand that existing tag pages are not rebuilt because they have been marked as "created" in `.ikiwiki/indexdb`. Is there a way to purge all tag pages from `indexdb`? --dkobozev + +> Well, you can delete the indexdb and rebuild, and that will do it. +> The tag plugin is careful not to replace existing pages or even recreate +> tag pages if you delete them, which does cause a problem if you need to +> update them. --[[Joey]] + +>> Thanks. I thought about deleting `indexdb`, but hesitated to do that. According to [[tips/inside dot ikiwiki]], `indexdb` stores "all persistent state about pages". I didn't know if it's harmless to lose all persistent state. --dkobozev + +>>> The persistant state is best thought of as a cache, +>>> so it's safe to delete it. --[[Joey]] diff --git a/doc/forum/transition_from_handwritten_html_to_ikiwiki.mdwn b/doc/forum/transition_from_handwritten_html_to_ikiwiki.mdwn new file mode 100644 index 000000000..a8d04a0ad --- /dev/null +++ b/doc/forum/transition_from_handwritten_html_to_ikiwiki.mdwn @@ -0,0 +1,90 @@ +I'm trying to convert hand written html site to ikiwiki and maintain url compatibility. html plugin with indexpages=1 converts all dir_name/index.html correctly to dir_name urls with wiki/css based content, but somedir/somefile.html files are only accessible as somedir/somefile/. Non .html files seem to accessible with their full paths, for example somedir/pic.jpg from hand written html can be accessed by same path under ikiwiki. + +How to make somedir/somefile.html accessible as somedir/somefile.html under ikiwiki? + +Thanks, + +-Mikko + +> Hello! The options you need to investigate are `--usedirs` and +> `--no-usedirs`. The default `--usedirs` takes any source page foo +> (regardless of its format, be it markdown or html) and converts it into a +> destination page foo/index.html (URL foo/). By comparison, `--no-usedirs` +> maps the source file onto a destination file directly: src/foo.html becomes +> dest/foo.html, src/bar.mdwn becomes dest/bar.html, etc. +> +> It sounds like you want `--no-usedirs`, or the corresponding `usedirs => 0,` +> option in your setup file. See [[usage]] for more information. -- [[Jon]] + +Thanks, usedirs seems to be just the thing I need. + +-Mikko + +Actually usedirs didn't do exactly what I want. The old site contains both +somedir/index.html and somedir/somename.html files. With html plugin and +indexpages=1 the somedir/index.html pages are accessed correctly but +somedir/somefile.html files not. + +With usedirs => 0, somedir/somename.html pages are accessed correctly but +somedir/index.html pages are not. Actually the handwritten somedir/index.html +files were removed on a rebuild: + + $ ikiwiki -setup blog.setup -rebuild -v + ... + removing test2/index.html, no longer built by test2 + +Is there a way for both index.html and somename.html raw html files to show up through ikiwki? + +-Mikko + +> I think you want usedirs => 0 and indexpages => 0? +> +> What IkiWiki does is to map the source filename to an abstract page name +> (indexpages alters how this is done), then map the abstract page name +> to an output filename (usedirs alters how this is done). +> +> The three columns here are input, abstract page name, output: +> +> usedirs => 0, indexpages => 0: +> a/index.html -> a/index -> a/index.html +> a/b.html -> a/b -> a/b.html +> usedirs => 1, indexpages => 0: +> a/index.html -> a/index -> a/index/index.html +> a/b.html -> a/b -> a/b/index.html +> usedirs => 0, indexpages => 1: +> a/index.html -> a -> a.html +> a/b.html -> a/b -> a/b.html +> usedirs => 1, indexpages => 1: +> a/index.html -> a -> a/index.html +> a/b.html -> a/b -> a/b/index.html +> +> The abstract page name is what you use in wikilinks and pagespecs. +> +> What I would suggest you do instead, though, is break your URLs once +> (but put in Apache redirections), to get everything to be consistent; +> I strongly recommend usedirs => 1 and indexpages => 0, then always +> advertising URLs that look like <http://www.example.com/a/b/>. This is +> what ikiwiki.info itself does, for instance. --[[smcv]] + +Thanks for the explanation. usedirs => 0 and indexpages => 0 does the trick, +but I'll try to setup mod_rewrite from foo/bar.html to foo/bar in the final +conversion. + +-Mikko + +> That's roughly what I do, but you can do it with `Redirect` and `RedirectMatch` from `mod_alias`, rather than fire up rewrite. Mind you I don't write a generic rule, I have a finite set of pages to redirect which I know. -- [[Jon]] + +I'm getting closer. Now with usedirs => 1 and raw html pages, ikiwiki transforms foo/index.html to foo/index/index.html. +Can ikiwiki be instructed map foo/index.html to page foo instead that foo/index? + +-Mikko + +> If you don't already have a foo.html in your source, why not just rename foo/index.html to foo.html? With usedirs, it will then map to foo/index.html. Before, you had 'foo/' and 'foo/index.html' as working URLS, and they will work after too. +> +> If you did have a foo.html and a foo/index.html, hmm, that's a tricky one. -- [[Jon]] + +> We may be going round in circles - that's what indexpages => 1 does :-) +> See the table I constructed above, which explains the mapping from input +> files to abstract page names, and then the mapping from abstract page +> names to output files. (I personally think that moving your source pages +> around like Jon suggested is a better solution, though. --[[smcv]] diff --git a/doc/forum/understanding_filter_hooks.mdwn b/doc/forum/understanding_filter_hooks.mdwn index 061d6d295..e6ddc91cc 100644 --- a/doc/forum/understanding_filter_hooks.mdwn +++ b/doc/forum/understanding_filter_hooks.mdwn @@ -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]] diff --git a/doc/forum/upgrade_steps.mdwn b/doc/forum/upgrade_steps.mdwn new file mode 100644 index 000000000..1c85e6402 --- /dev/null +++ b/doc/forum/upgrade_steps.mdwn @@ -0,0 +1,147 @@ +[[!meta date="2007-08-27 21:52:18 +0000"]] + +I upgrades from 1.40 to 2.6.1. I ran "ikiwiki --setup" using my existing ikiwiki.setup configuration. +I had many errors like: + + /home/bsdwiki/www/wiki/wikilink/index.html independently created, not overwriting with version from wikilink + BEGIN failed--compilation aborted at (eval 5) line 129. + +and: + + failed renaming /home/bsdwiki/www/wiki/smileys.ikiwiki-new to /home/bsdwiki/www/wiki/smileys: Is a directory + BEGIN failed--compilation aborted at (eval 5) line 129. + +Probably about six errors like this. I worked around this by removing the files and directories it complained about. +Finally it finished. + +> As of version 2.0, ikiwiki enables usedirs by default. See +> [[tips/switching_to_usedirs]] for details. --[[Joey]] + +>> I read the config wrong. I was thinking that it showed the defaults even though commented out +>> (like ssh configs do). I fixed that part. --JeremyReed + +My next problem was that ikiwiki start letting me edit without any password authentication. It used to prompt +me for a password but now just goes right into the "editing" mode. +The release notes for 2.0 say password auth is still on by default. + +> It sounds like you have the anonok plugin enabled? + +>> Where is the default documented? My config doesn't have it uncommented. + +The third problem is that when editing my textbox is empty -- no content. + +This is using my custom rcs.pm which has been used thousands of times. + +> Have you rebuilt the cgi wrapper since you upgraded ikiwiki? AFAIK I +> fixed a bug that could result in the edit box always being empty back in +> version 2.3. The only other way it could happen is if ikiwiki does not +> have saved state about the page that it's editing (in .ikiwiki/index). + +>> Rebuilt it several times. Now that I think of it, I think my early problem of having +>> no content in the textbox was before I rebuilt the cgi. And after I rebuilt the whole webpage was empty. + +Now I regenerated my ikiwiki.cgi again (no change to my configuration, +and I just get an empty HTML page when attempting editing or "create". + +> If the page is completly empty then ikiwiki is crashing before it can +> output anything, though this seems unlikely. Check the webserver logs. + +Now I see it created directories for my data. I fixed that by setting +usedirs (I see that is in the release notes for 2.0) and rerunning ikiwiki --setup +but I still have empty pages for editing (no textbox no html at all). + +> Is IkiWiki crashing? If so, it would probably leave error text in the apache logs. --[[TaylorKillian]] + +>> Not using apache. Nothing useful in logs other thn the HTTP return codes are "0" and bytes is "-" +>> on the empty ikiwiki.cgi output (should say " 200 " followed by bytes). + +>>> You need to either figure out what your web server does with stderr +>>> from cgi programs, or run ikiwiki.cgi at the command line with an +>>> appropriate environment so it thinks it's being called from a web +>>> server, so you can see how it's failing. --[[Joey]] + +(I am posting this now, but will do some research and post some more.) + +Is there any webpage with upgrade steps? + +> Users are expected to read [[news]], which points out any incompatible +> changes or cases where manual action is needed. + +>> I read it but read the usedirs option wrong :(. +>> Also it appears to be missing the news from between 1.40 to 2.0 unless they dont' exist. +>> If they do exist maybe they have release notes I need? + +>>> All the old ones are in the NEWS file. --[[Joey]] + +--JeremyReed + +My followup: I used a new ikiwiki.setup based on the latest version. But no changes for me. + +Also I forgot to mention that do=recentchanges works good for me. It uses my +rcs_recentchanges in my rcs perl module. + +The do=prefs does nothing though -- just a blank webpage. + +> You need to figure out why ikiwiki is crashing. The webserver logs should +> tell you. + +I also set verbose => 1 and running ikiwiki --setup was verbose, but no changes in running CGI. +I was hoping for some output. + +I am guessing that my rcs perl module stopped working on the upgrade. I didn't notice any release notes +on changes to revision control modules. Has something changed? I will also look. + +> No, the rcs interface has not needed to change in a long time. Also, +> nothing is done with the rcs for do=prefs. + +>> Thanks. I also checked differences between 1.40 Rcs plugins and didn't notice anything significant. + +--JeremyReed + +Another Followup: I created a new ikiwiki configuration and did the --setup to +create an entirely different website. I have same problem there. No prompt for password +and empty webpage when using the cgi. +I never upgraded any perl modules so maybe a new perl module is required but I don't see any errors so I don't know. + +The only errors I see when building and installing ikiwiki are: + + Can't exec "otl2html": No such file or directory at IkiWiki/Plugin/otl.pm line 66. + + gettext 0.14 too old, not updating the pot file + +I don't use GNU gettext on here. + +I may need to revert back to my old ikiwiki install which has been used to thousands of times (with around +1000 rcs commits via ikiwiki). + +--JeremyReed + +I downgraded to version 1.40 (that was what I had before I wrote wrong above). +Now ikiwiki is working for me again (but using 1.40). I shouldn't have tested on production system :) + +--JeremyReed + +I am back. On a different system, I installed ikiwiki 2.6.1. Same problem -- blank CGI webpage. + +So I manually ran with: + + REQUEST_METHOD=GET QUERY_STRING='do=create&page=jcr' kiwiki.cgi + +And clearly saw the error: + + [IkiWiki::main] Fatal: Bad template engine CGI::FormBuilder::Template::div: Can't locate CGI/FormBuilder/Template/div.pm + +So I found my version was too old and 3.05 is the first to provide "Div" support. I upgraded my p5-CGI-FormBuilder to 3.0501. +And ikiwiki CGI started working for me. + +The Ikiwiki docs about this requirement got removed in Revision 4367. There should be a page that lists the requirements. +(I guess I could have used the debian/control file.) + +> There is a page, [[install]] documents that 3.05 is needed. + +>> Sorry, I missed that. With hundreds of wikipages it is hard to read all of them. +>> I am updating the download page now to link to it. + +I am now using ikiwiki 2.6.1 on my testing system. + +--JeremyReed diff --git a/doc/forum/use_php-markdown-extra_with_ikiwiki__63__.mdwn b/doc/forum/use_php-markdown-extra_with_ikiwiki__63__.mdwn new file mode 100644 index 000000000..86ed70fd2 --- /dev/null +++ b/doc/forum/use_php-markdown-extra_with_ikiwiki__63__.mdwn @@ -0,0 +1,3 @@ +Is it possible to use php-markdown-extra with ikiwiki? + +Thanks. diff --git a/doc/forum/use_php-markdown-extra_with_ikiwiki__63__/comment_1_66d48218361caa4c07bd714b82ed0021._comment b/doc/forum/use_php-markdown-extra_with_ikiwiki__63__/comment_1_66d48218361caa4c07bd714b82ed0021._comment new file mode 100644 index 000000000..af60ecbdb --- /dev/null +++ b/doc/forum/use_php-markdown-extra_with_ikiwiki__63__/comment_1_66d48218361caa4c07bd714b82ed0021._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://kerravonsen.dreamwidth.org/" + ip="60.241.8.244" + subject="PHP != Perl" + date="2010-07-10T12:44:15Z" + content=""" +Er, why? IkiWiki is written in Perl. Presumably php-markdown-extra is written in PHP, which is a completely different language. +"""]] diff --git a/doc/forum/use_php-markdown-extra_with_ikiwiki__63__/comment_2_f2ee0a4dce571d329f795e52139084c0._comment b/doc/forum/use_php-markdown-extra_with_ikiwiki__63__/comment_2_f2ee0a4dce571d329f795e52139084c0._comment new file mode 100644 index 000000000..ce60f4b3a --- /dev/null +++ b/doc/forum/use_php-markdown-extra_with_ikiwiki__63__/comment_2_f2ee0a4dce571d329f795e52139084c0._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawlzADDUvepOXauF4Aq1VZ4rJaW_Dwrl6xE" + nickname="Dário" + subject="comment 2" + date="2010-07-10T21:48:13Z" + content=""" +Because php-markdown-extra extends the basic markdown language (footnotes, etc.) +"""]] diff --git a/doc/forum/use_php-markdown-extra_with_ikiwiki__63__/comment_3_e388714f457ccb6ef73630179914558c._comment b/doc/forum/use_php-markdown-extra_with_ikiwiki__63__/comment_3_e388714f457ccb6ef73630179914558c._comment new file mode 100644 index 000000000..72ce7bb6f --- /dev/null +++ b/doc/forum/use_php-markdown-extra_with_ikiwiki__63__/comment_3_e388714f457ccb6ef73630179914558c._comment @@ -0,0 +1,9 @@ +[[!comment format=mdwn + username="http://kerravonsen.dreamwidth.org/" + ip="202.173.183.92" + subject="I still don't get it" + date="2010-07-11T07:18:35Z" + content=""" +But if you need the \"extra\" features of Markdown, all you have to do is turn on the \"multimarkdown\" option in your configuration. It makes no sense to try to use PHP with Perl. + +"""]] diff --git a/doc/forum/utf8_warnings_for___34____92__xAB__34__.mdwn b/doc/forum/utf8_warnings_for___34____92__xAB__34__.mdwn new file mode 100644 index 000000000..72f2d38e0 --- /dev/null +++ b/doc/forum/utf8_warnings_for___34____92__xAB__34__.mdwn @@ -0,0 +1,47 @@ +# getting Warnings about UTF8-Chars. + +I'm getting multiple warnings: + + utf8 "\xAB" does not map to Unicode at /usr/share/perl5/IkiWiki.pm line 774, <$in> chunk 1. + + +I'm assuming this is once per File, but even in verbose mode, it doesn't tell me which file is a problem. +It first reads all the files, and afterwards when parsing/compiling them, it outputs the warning, so I can't +deduce the offending files. + +Is there a way to have ikiwiki output the position, where it encounters the character? + +Probably all this has to do with locale-settings, and usage of mixed locales in a distributed setup ... +I'd rather cleanup some of the file(name)s of unexpected characters. --[[jwalzer]] + +-------- + +**Update** : So I took the chance to insert debug into ikiwiki.pm: + + root@novalis:/usr/share/perl5# diff -p /tmp/IkiWiki.orig.pm IkiWiki.pm + *** /tmp/IkiWiki.orig.pm Sun Feb 14 15:16:08 2010 + --- IkiWiki.pm Sun Feb 14 15:16:28 2010 + *************** sub readfile ($;$$) { + *** 768,773 **** + --- 768,774 ---- + } + + local $/=undef; + + debug("opening File: $file:"); + open (my $in, "<", $file) || error("failed to read $file: $!"); + binmode($in) if ($binary); + return \*$in if $wantfd; + + +But what I see now is not quite helpful, as it seems, STDERR and DEBUG are asyncronous, so they mix up in a way, that I can't really see, whats the problem ... Maybe I'm better off for troubleshooting, to insert an printf to strerr to have it in the same stream.. --[[jwalzer]] + + +---- + +**Update:** The "print STDERR $file;"-Trick did it .. I was able to find a mdwn-file, that (was generated by a script of me) had \0xAB in it. + +Nevertheless I still wonder if this should be a problem. This character happend to be in an *\[\[meta title='$CHAR'\]\]-tag* and an *\[$CHAR\]http://foo)-Link* + +Should this throw an warning? Maybe this warning could be catched an reported inclusively the containing filename? maybe even with an override, if one knows that it is correct that way? --[[jwalzer]] + +[[!tag solved]] diff --git a/doc/forum/web_service_API__44___fastcgi_support.mdwn b/doc/forum/web_service_API__44___fastcgi_support.mdwn new file mode 100644 index 000000000..4a78fb932 --- /dev/null +++ b/doc/forum/web_service_API__44___fastcgi_support.mdwn @@ -0,0 +1,13 @@ +This is a half-baked thought of mine so I thought I would post it in forum for discussion. + +There are some things that ikiwiki.cgi is asked to do which do not involve changing the repository: these include form generation, handling logins, the "goto" from [[recentchanges]], edit previews, etc. + +For one thing I am working on slowly ([[todo/interactive todo lists]]), I've hit a situation where I am likely to need to implement doing markup evaluation for a subset of a page. The problem I face is, if a user edits content in the browser, markup, ikiwiki directives etc. need to be expanded. I could possibly do this with a round-trip through edit preview, but that would be for the whole content of a page, and I hit the problem with editing a list item. + +> (slight addendum on this front. I'm planning to split the javascript code for interactive todo lists into two parts: one for handling round trips of content to and from ikiwiki.cgi, and the various failure modes that might occur (permission denied, edit conflicts, login required, etc.) ; then the list-specific stuff can build on top of this. The first chunk might be reusable by others for other AJAXY-edit fu.) + +Anyway - I've realised that a big part of the interactive todo lists stuff is trying to handle round trips to ikiwiki.cgi through javascript. A web services API would make handling the various conditions of this easier (e.g. need to login, login failed, etc.). I'm not sure what else might benefit from a web services API and I have no real experience of either using or writing them so I don't know what pros/cons there are for REST vs SOAP etc. + +Second, and in a way related, I've been mooting hacking fastcgi support into ikiwiki. Essentially one ikiwiki.cgi process would persist and serve CGI-ish requests on stdin/stdout. The initial content-scanning and dependency generation would happen once and not need to be repeated for future requests. Although, all state-changing operations would need to be careful to ensure the in-memory models were accurate. Also, I don't know how suited the data structures would be for persistence, since the current model is build em up, throw em away, they might not be space-efficient enough for persistence. + +If I did attempt this, I would want to avoid restructuring things in a way which would impair ikiwiki's core philosophy of being a static compiler. -- [[Jon]] diff --git a/doc/forum/what_is_the_easiest_way_to_implement_order:_disallow_all__44___allow_chosen__95__few_page_editing_policy__63__.mdwn b/doc/forum/what_is_the_easiest_way_to_implement_order:_disallow_all__44___allow_chosen__95__few_page_editing_policy__63__.mdwn new file mode 100644 index 000000000..fbc5c58e2 --- /dev/null +++ b/doc/forum/what_is_the_easiest_way_to_implement_order:_disallow_all__44___allow_chosen__95__few_page_editing_policy__63__.mdwn @@ -0,0 +1,3 @@ +As in title, I'd like to allow editing only some pages on my wiki. Rest by default is not editable by users except admin. Thanks + +> See [[plugins/lockedit]]. --[[schmonz]] diff --git a/doc/forum/where_are_the_tags.mdwn b/doc/forum/where_are_the_tags.mdwn new file mode 100644 index 000000000..ecb49fe43 --- /dev/null +++ b/doc/forum/where_are_the_tags.mdwn @@ -0,0 +1,9 @@ +Where is the tag cloud/tag listing of all the tags used in this wiki? I know we +have tags enabled. --[[jerojasro]] + +> This wiki does not use one global toplevel set of tags (`tagbase` is not +> set). +> +> There are tags used for the [[plugins]], and a tag cloud of those +> there. [[wishlist]] and [[patch]] are tags too, but I don't see the point +> of a tag cloud for such tags. --[[Joey]] diff --git a/doc/forum/wiki_clones_on_dynamic_IPs.mdwn b/doc/forum/wiki_clones_on_dynamic_IPs.mdwn new file mode 100644 index 000000000..f69f6501e --- /dev/null +++ b/doc/forum/wiki_clones_on_dynamic_IPs.mdwn @@ -0,0 +1,10 @@ +OK, this is not really a ikiwiki problem... but ikiwiki makes wiki clones +really easy to setup, and this is related to having a website cloned at +different places and pulling from the servers which are online. + +My setup is like this: I have a server at home and another at my dorm +which will serve as a wiki clone. Each of them has a dynamic IP with DynDNS +set up. Now the problem lies in linking my domain to these two DynDNS addresses. +Multiple CNAMEs are not supported, and I don't know if there's any utility +which can update the A records on the DNS to point directly point to the +two separate IPs. diff --git a/doc/forum/wiki_name_in_page_titles.mdwn b/doc/forum/wiki_name_in_page_titles.mdwn index 01ff8d817..4e9e51835 100644 --- a/doc/forum/wiki_name_in_page_titles.mdwn +++ b/doc/forum/wiki_name_in_page_titles.mdwn @@ -23,4 +23,10 @@ that provides a `IS_HOMEPAGE` template variable? --[[JasonBlevins]] >> few other small plugins brewing so I'll try to put up some contrib >> pages for them soon. --[[JasonBlevins]] -[path]: http://code.jblevins.org/ikiwiki/plugins.git/plain/path.pm +[path]: http://jblevins.org/git/ikiwiki/plugins.git/plain/path.pm + +> I used the following trick in some page.tmpl: +> +> <title><TMPL_VAR WIKINAME><TMPL_IF NAME="PARENTLINKS">: <TMPL_VAR TITLE></TMPL_IF></title> +> +> --[[JeanPrivat]] diff --git a/doc/forum/wishlist-discussion:_Editformular_showing_existing_tags.mdwn b/doc/forum/wishlist-discussion:_Editformular_showing_existing_tags.mdwn new file mode 100644 index 000000000..49c55e20e --- /dev/null +++ b/doc/forum/wishlist-discussion:_Editformular_showing_existing_tags.mdwn @@ -0,0 +1,15 @@ +# How about: + +having a list of all existing tags in the Edit-Formular as a selectionbox? + +Assume I have tagbase=/tags/ and for every tag I have given to articles an existing page there. + +Would it be possible to list all these tags together with the Formular, as selectionbox. +Maybe even with parsing of the content and preselecting the tags, that are given in the article and vice-versa when selecting the fields then also generating the \[\[\!tag\]\]-sourcecode ? + +this would need a bit JS-work and somehow on compiletime we need to put the list of tags somewhere, where the cgi could read them from. +This way, even a pagespec would suffice to determine the usable list of tags and not only the tagbase-variable. + +> I think this would be very hard to achieve with the current tag plugin, due to the nature of its implementation. +> +> I've had a "tag2" plugin on the go for a while which supports this. It's in a very rough stage but I'll try to find it and upload it somewhere. -- [[Jon]] |