urosm
/
ikiwiki
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

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

master
Joey Hess 2010-05-18 13:33:54 -04:00
parent 7aa209f1ce 529141779f
commit 32d4d975ae
3 changed files with 38 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
doc/forum/ikiwiki_development_environment_tips.mdwn
View File

@ -3,3 +3,17 @@ I haven't settled on a comfortable/flexible/quick development environment for ha
Does anyone have a comfortable setup or tips they would like to share? -- [[Jon]] 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'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). 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]]

3
doc/todo/allow_displaying_number_of_comments.mdwn
View File

@ -25,3 +25,6 @@ Please review... and pull :)
> --[[Joey]] > --[[Joey]]
[[patch]] [[patch]]
>> Well, the COMMENTSLINK variable fits my needs. Sorry for
>> the disturbance. [[done]] --[[intrigeri]]

21
doc/todo/multiple_template_directories.mdwn
View File

@ -50,3 +50,24 @@ I have a use case for this, a site composed of blogs and wikis, templates divide
>> multiple template directories is still present. Just put them in >> multiple template directories is still present. Just put them in
>> the templates/ subdirectory of multiple underlay directories instead. >> the templates/ subdirectory of multiple underlay directories instead.
>> --[[Joey]] >> --[[Joey]]
>>>Thanks, I didn't realize this was possible. Problem solved. -- Changaco
>>>> We can consider this [[done]], then. For reference, the solution
>>>> to the hierarchy I mentioned above would be:
>>>>
>>>> all your sites have $your_underlay as an underlay
>>>>
>>>> the blogs and wikis all have $blog_underlay or $wiki_underlay
>>>> (as appropriate) as a higher priority underlay
>>>>
>>>> every ikiwiki in the world (/usr/share/ikiwiki/templates)
>>>> \--- your site ($your_underlay/templates, or templatedir)
>>>> \--- your blogs ($blog_underlay/templates)
>>>> \--- travel blog ($srcdir/templates)
>>>> \--- code blog ($srcdir/templates)
>>>> \--- your wikis ($wiki_underlay/templates)
>>>> \--- travel wiki ($srcdir/templates)
>>>> \--- code wiki ($srcdir/templates)
>>>>
>>>> --[[smcv]]