Merge branch 'master' of ssh://git.ikiwiki.info/srv/git/ikiwiki.info

master
Joey Hess 2011-02-01 21:08:32 -04:00
commit 9ed779b746
10 changed files with 111 additions and 10 deletions

View File

@ -0,0 +1,60 @@
I'm using the [[map_directive|ikiwiki/directive/map]] to build dynamic navigation menus, and it's working really nicely!
However on some pages, each nested item each get wrapped in a full set of `<ul>` tags. This doesn't actually hurt anything, but it's does it inconsistently which seems like a bug. I don't like it because it puts extra vertical spacing into my menu bar.
Here's what I expect it to look like:
<div class="map">
<ul>
<li><span class="selflink">Archives</span>
<ul>
<li><a href="./2010/" class="mapitem">2010</a></li>
<li><a href="./2011/" class="mapitem">2011</a></li>
</ul>
</li>
</ul>
</div>
And here's what it's actually doing:
<div class="map">
<ul>
<li><span class="selflink">Archives</span>
<ul>
<li><a href="./2010/" class="mapitem">2010</a></li>
</ul>
<ul>
<li><a href="./2011/" class="mapitem">2011</a></li>
</ul>
</li>
</ul>
</div>
I've tried to replicate the problem on this site and cannot, I'm not sure if that's because of exactly how I'm using map or if there's something different with my site. I just upgraded ikiwiki to the latest Debian unstable as well as most of the required Perl modules and nothing changed.
If you look at [this page on my site](http://adam.shand.net/ikidev/archives/) (getsource is enabled) you can see it working as expected in the main page and not working in the side bar.
But it also doesn't work on the sitemap page: <http://adam.shand.net/ikidev/site/map/>
This might be really simple, but I've been staring at it too long and it only looks like a bug to me. :-( Any suggestions would be gratefully accepted. -- [[AdamShand]]
> Okay, I think I've figured this out, it looks like ikiwiki behaves differently depending on the level of heirarchy. I'll post the details once I'm sure. -- [[AdamShand]]
>> I managed to replicate the issue on my ikiwiki, and I believe it is a
>> bug. The current upstream logic for going up/down by a level opens
>> (and closes) the unnecessary lists that you are seeing. Although the
>> resulting markup is semantically correct, it has superflous stuff
>> that introduces whitespace issues at the very least.
>> I have a [[patch]] up [on my git repo](http://git.oblomov.eu/ikiwiki/patch/55fa11e8a5fb351f9371533c758d8bd3eb9de245)
>> that ought to fix the issue.
>>> Wonderful, thank you very much for the help! I've installed the patch and it's working great, but it looks like there a minor bug. Sometimes it doesn't print the top/first map item. Cheers, -- [[AdamShand]]
>>>
>>> <http://adam.shand.net/tmp/map-orig.jpg>
>>> <http://adam.shand.net/tmp/map-patched.jpg>
>>>> Thanks for testing. I managed to reproduce it and I adjusted the logic.
>>>> An updated [[patch]] can be found [here](http://git.oblomov.eu/ikiwiki/patch/dcfb18b7989a9912ed9489f5ff15f871b6d8c24a)
>>>>> Seems to work perfectly to me, thanks! -- [[AdamShand]]

View File

@ -13,7 +13,7 @@ Manual installation steps and requirements are listed on the [[install]] page.
## Debian / Ubuntu packages ## Debian / Ubuntu packages
To install with apt, if using Debian or Ubuntu: To install with [apt](http://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_basic_package_management_operations), if using Debian or Ubuntu:
apt-get install ikiwiki apt-get install ikiwiki

View File

@ -0,0 +1 @@
Hi there..

View File

@ -0,0 +1,8 @@
Do custom [[themes]] have to live outside of the wiki (eg. `/usr/share/ikiwiki/themes/`) or is there a way for them to live inside of the wiki srcdir?
I haven't been able to find a way so for now I'm just using a symlink, but that's a bit ugly.
I ask because I do most of my ikiwiki work on my laptop and then push changes to my server. It's not a big deal but it's annoying to have to sync the themes separately and it seems like something which should be able to live inside the wiki like templates.
Cheers,
[[AdamShand]]

View File

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://smcv.pseudorandom.co.uk/"
nickname="smcv"
subject="comment 1"
date="2011-01-29T18:17:40Z"
content="""
The theme plugin is just a shortcut for adding an underlay with a style.css and maybe some images. If you want to base your design on a modified theme, copy the theme's style.css (or part of it) to the local.css in your wiki's repository; you can also copy in the images and disable the theme plugin entirely.
"""]]

View File

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://adam.shand.net/"
nickname="Adam"
subject="Doh."
date="2011-01-29T19:32:18Z"
content="""
Ah that makes sense, thanks!
"""]]

View File

@ -18,3 +18,9 @@ lot of free CSS templates could be included, e. g. from
> that ikiwiki itself does not require. --[[Joey]] > that ikiwiki itself does not require. --[[Joey]]
### Once one has enabled the 'theme' plugin in the setup file, how does one use themes? ### Once one has enabled the 'theme' plugin in the setup file, how does one use themes?
Choose one of the [[themes]] which are bundled with ikiwiki and configure ikiwiki to use it by setting this in your setup file, eg.
theme => 'blueview',
-- [[AdamShand]]

View File

@ -4,7 +4,7 @@ This tutorial will walk you through setting up a wiki with ikiwiki.
## Install ikiwiki ## Install ikiwiki
If you're using Debian or Ubuntu, ikiwiki is an `aptitude install ikiwiki` away. If you're using Debian or Ubuntu, ikiwiki is an <code><a href="http://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_basic_package_management_operations">apt-get</a> install ikiwiki</code> away.
If you're not, see the [[download]] and [[install]] pages. If you're not, see the [[download]] and [[install]] pages.
## Create your wiki ## Create your wiki

View File

@ -1,4 +1,4 @@
pushing [[this|todo/httpauth feature parity with passwordauth]] and [[this|todo/htpasswd mirror of the userdb]] further (although rather in the [[wishlist]] priority): would it make sense for users to have a `$USER/creditentials` page that is by default locked to the user and admins, where the user can state one or more of the below? pushing [[this|todo/httpauth feature parity with passwordauth]] and [[this|todo/htpasswd mirror of the userdb]] further (although rather in the [[wishlist]] priority): would it make sense for users to have a `$USER/credentials` page that is by default locked to the user and admins, where the user can state one or more of the below?
* OpenID * OpenID
* ssh public key (would require an additional mechanism for writing this to a `authorized_keys` file with appropriate environment variables or prefix that makes sure the commit is checked against the right user and that the user names agree) * ssh public key (would require an additional mechanism for writing this to a `authorized_keys` file with appropriate environment variables or prefix that makes sure the commit is checked against the right user and that the user names agree)
@ -21,3 +21,13 @@ such a page could have a form as described in [[todo/structured page data]] and
> public keys in `authorized_keys` etc). > public keys in `authorized_keys` etc).
> -- GB > -- GB
>> having multiple login options leading to the same identity, and (more important to me) giving the user an easy way to review and edit them. i'm thinking a bit of foaf+ssl style "i am $USER and you can recognize me by my client certificate $CERTIFICATE" statements.
>>
>> the reason why i want this in a static place instead of cgi level is that it can be used, for example, for automatically creating htpasswd files for read-only (cgi-less) replicas of private wikis. furthermore, it all gets versioned and it can easily be seen where the data really is. the credentials have to be filed appropriately by plugins anyway, but that can happen as a part of the regular rebuild process.
>>
>> and yes, you're right about the word misusage; thanks for pointing it out and fixing it.
>>
>> --[[chrysn]]
an issue to be considered: for ways of authentication that don't explicitly mention the user name (and that would be everything but password; especially OpenID), there has to be a way to prevent users from hijacking an admin's account. the user wouldn't get more privileges, but the admin could find himself logged in as a user instead of an admin when he logs in using his OpenID, for example. he could fix it by removing the openid from the user's ("his") page, but it has to be taken care of nevertheless. --[[chrysn]]

View File

@ -1,15 +1,15 @@
[[!meta title="Adam Shand"]] [[!meta title="Adam Shand"]]
New IkiWiki user (well not really "new" anymore), long time wiki user. :-) New ikiwiki user (well not really "new" anymore), long time wiki user. :-)
<http://adam.shand.net/iki/> <http://adam.shand.net/iki/>
<!-- does't work, to track down why later [[!map pages="link(AdamShand)"]]
Pages I participate in: <!-- for map bug
[ ## Correct? (No extra ULs)
[ \[[!map pages="setup*" show="title"]]
!
inline pages="internal(recentchanges/change_*) and !author(http://adam.shand.net/)" feedonly=no atom=no]]
## Bug? (Extra UL for each LI)
\[[!map pages="tagged(done) and tagged(patch)" show="title"]]
--> -->