Merge branch 'master' into cvs
Amitai Schlair
commit
b88994ddfa
|
|
@ -13,7 +13,7 @@
|
|||
#
|
||||
# You should have received a copy of the GNU General Public License
|
||||
# along with this program; if not, write to the Free Software
|
||||
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
|
||||
# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.
|
||||
|
||||
require 5.002;
|
||||
package IkiWiki::Plugin::calendar;
|
||||
|
|
|
|||
|
|
@ -75,7 +75,7 @@ underlay_install:
|
|||
install -d $(DESTDIR)$(PREFIX)/share/ikiwiki
|
||||
for dir in `cd underlays && $(FIND) . -follow -type d`; do \
|
||||
install -d $(DESTDIR)$(PREFIX)/share/ikiwiki/$$dir; \
|
||||
for file in `$(FIND) underlays/$$dir -follow -maxdepth 1 -type f -not -name \\*.full.js -not -name \\*.full.css`; do \
|
||||
for file in `$(FIND) underlays/$$dir -follow -maxdepth 1 -type f ! -name \\*.full.js ! -name \\*.full.css`; do \
|
||||
cp -pRL $$file $(DESTDIR)$(PREFIX)/share/ikiwiki/$$dir 2>/dev/null || \
|
||||
install -m 644 $$file $(DESTDIR)$(PREFIX)/share/ikiwiki/$$dir; \
|
||||
done; \
|
||||
|
|
|
|||
|
|
@ -1,3 +1,10 @@
|
|||
ikiwiki (3.20120203) UNRELEASED; urgency=low
|
||||
|
||||
* Fix a snail mail address. Closes: #659158
|
||||
* openid-jquery.js: Update URL of Wordpress favicon. Closes: #660549
|
||||
|
||||
-- Joey Hess <joeyh@debian.org> Wed, 08 Feb 2012 16:07:00 -0400
|
||||
|
||||
ikiwiki (3.20120202) unstable; urgency=low
|
||||
|
||||
* mdwn: Added nodiscount setting, which can be used to avoid using the
|
||||
|
|
|
|||
|
|
@ -1,13 +0,0 @@
|
|||
I'm writing [pykipandoc plugin](https://github.com/temmen/pykipandoc/blob/master/pykipandoc), that work at least as pandoc-iki.
|
||||
|
||||
It works in compile mode, editing pages in web mode however results in
|
||||
|
||||
pandoc: : hGetContents: invalid argument (Invalid or incomplete multibyte or wide character)
|
||||
|
||||
I think that is because HTTP POST request building editpage doesn't correctly manage utf-8 contents: see strange chars in this form-data name="editcontent"?
|
||||
|
||||
This principle has guided pandoc’s decisions in finding syntax for tables, footnotes, and other extensions.
|
||||
|
||||
Please, any advice can be sent to [GitHub pykipandoc](https://github.com/temmen/pykipandoc) (some other info there on the [README](https://github.com/temmen/pykipandoc/blob/master/README.md)) and to [temmenel(at)gmail(dot)com](mailto:temmenel@gmail.com).
|
||||
|
||||
¡Thank you all!
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
import os
|
||||
os.environment['LANG'] = 'it_IT.utf-8'
|
||||
|
||||
Suona plausibile?
|
||||
|
||||
[GitHub pykipandoc](https://github.com/temmen/pykipandoc) -- Temmen
|
||||
|
||||
> The place to put contrib plugins is in [[plugins/contrib]].
|
||||
>
|
||||
> Closing this bug report as whatever it is that was fixed is apparently not an ikiwiki
|
||||
> bug.. I guess. [[done]] --[[Joey]]
|
||||
|
|
@ -3,3 +3,5 @@
|
|||
Whoops, somehow missed a spot on the last incarnation of this branch.
|
||||
`find -not` doesn't work on NetBSD and `find !` runs equivalently
|
||||
for me. Fixed in 9659272e25fac37f896991dab01a05b4f4c85ccb.
|
||||
|
||||
> [[done]] --[[Joey]]
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ I'd very much like to be able to list my blog posts on a daily basis (used for l
|
|||
|
||||
There was some effort to do this as detailed here.
|
||||
|
||||
[[http://ikiwiki.info/todo/Set_arbitrary_date_to_be_used_by_calendar_plugin/]]
|
||||
[[todo/Set_arbitrary_date_to_be_used_by_calendar_plugin]]
|
||||
|
||||
I had a quick go at doing something similar on Debian Stable (Ikiwiki 3.0) but alas my Ikiwiki fu is not strong enough.
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,15 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joey.kitenet.net/"
|
||||
nickname="joey"
|
||||
subject="comment 4"
|
||||
date="2012-02-21T17:23:00Z"
|
||||
content="""
|
||||
To be clear, this patch creates a `yyyy/mm/dd` file for each day, listing the posts for that day, so the calendar can link to it rather than a random single post.
|
||||
|
||||
While a valid solution certainly, that's a lot of added pages! Especially a high overhead for such a minor UI point as this.
|
||||
|
||||
Surely something interesting could be done with javascript or some other form of UI to make clicking on a day in a calendar that has multiple posts present a list of them? That would have essentially no overhead, since the calendar plugin already has a list of the posts made on a given day.
|
||||
|
||||
Ikiwiki already does something similar to deal with the case where a page has a great many backlinks.. It makes a UI element that, if hovered over, pops up a display of all the rest. This is done quite simply in the `page.tmpl`
|
||||
using the popup and balloon CSS classes. Calendar could also use this.
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
How to add a mouse-over pop-up label for a text?
|
||||
|
||||
I'd like to have the following effect:
|
||||
|
||||
when a user move the mouse arrow on top of the text, a small window will show up at the upper right of the text and the window contains some additional information about the text.
|
||||
|
||||
Any idea how to achieve this?
|
||||
|
||||
|
|
@ -0,0 +1,25 @@
|
|||
[[!comment format=mdwn
|
||||
username="https://www.google.com/accounts/o8/id?id=AItOawnp4lzWSX1pvSpwAoboehP3SSbmbQESe80"
|
||||
nickname="Felipe Augusto"
|
||||
subject="I'm trying to use OpenID without success"
|
||||
date="2012-02-08T04:54:22Z"
|
||||
content="""
|
||||
I'm using ikiwiki package from Debian squeeze and I can't seem
|
||||
to be able to make OpenID work. It's a blog and when I try to
|
||||
add a comment and click on SignIn, I'm redirected to
|
||||
|
||||
>http://my.site/ikiwiki.cgi?do=commentsignin
|
||||
|
||||
|
||||
Once I click on Google logo/icon, it takes a while before showing
|
||||
|
||||
>no_identity_server: The provided URL doesn't declare its OpenID identity server.
|
||||
|
||||
|
||||
It's not clear for me what's wrong or if I should add meta openid in some page.
|
||||
This is the version of libnet-openid-consumer-perl: 1.03-1. It also fails for
|
||||
Yahoo! and other providers, we never get redirected to Google/Yahoo! or other
|
||||
verification page.
|
||||
|
||||
Thank you in advance!
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
I use gitweb to display the pagehistories of my local ikiwiki. However since a few weeks it doesn't work anymore and displays just: 404 - No such project. I don't remember that I changed something with my wiki. Any ideas how to fix this? I guess that it could be a permission problem, however I don't really know which permissions are important in this case.
|
||||
|
||||
|
||||
|
|
@ -0,0 +1 @@
|
|||
How can I get the little glasses-icon with a link to the diff on Recentchanges, please? I have git integration working nicely, and recentchangesdiff is producing diffs in the RSS feed, but I'd really like a link on the RecentChanges like you have here.
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joey.kitenet.net/"
|
||||
nickname="joey"
|
||||
subject="comment 1"
|
||||
date="2012-02-23T20:20:17Z"
|
||||
content="""
|
||||
Set up gitweb and configure the `diffurl` in ikiwiki and the glasses will appear.
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
[[!comment format=mdwn
|
||||
username="bob"
|
||||
ip="137.205.152.60"
|
||||
subject="comment 2"
|
||||
date="2012-02-24T09:30:50Z"
|
||||
content="""
|
||||
Thanks, that was just the ticket :). My ikiwiki.setup file didn't even have a commented out diffurl in it - is there a handy list of configuration-variables somewhere? I thought the theory was that ikiwiki.setup was generated with (commented out) nearly all the config variables already mentioned?
|
||||
|
||||
[FWIW, I'm using the version in Debian stable]
|
||||
"""]]
|
||||
|
|
@ -74,6 +74,7 @@ think about merging them. This is recommended. :-)
|
|||
* nezmer `git://gitorious.org/ikiwiki-nezmer/ikiwiki-nezmer.git`
|
||||
* [[yds]] `git://github.com/yds/ikiwiki.git`
|
||||
* [[pelle]] `git://github.com/hemmop/ikiwiki.git`
|
||||
* [[chrismgray]] `git://github.com/chrismgray/ikiwiki.git`
|
||||
|
||||
## branches
|
||||
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ the calendars to highlight the current day.
|
|||
|
||||
An example crontab:
|
||||
|
||||
0 0 * * * ikiwiki-calendar ~/ikiwiki.setup "posts/* and !*/Discussion"
|
||||
0 0 * * * ikiwiki-calendar ~/ikiwiki.setup 'posts/* and !*/Discussion'
|
||||
|
||||
# TEMPLATES
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,36 @@
|
|||
Suggestion to change
|
||||
|
||||
0 0 * * * ikiwiki-calendar ~/ikiwiki.setup "posts/* and !*/Discussion"
|
||||
|
||||
to
|
||||
|
||||
0 0 * * * ikiwiki-calendar ~/ikiwiki.setup 'posts/* and !*/Discussion'
|
||||
|
||||
I ran into (for me) unexpected behaviour with double quotes, since when I tried it in the interactive shell, the "!" made it fail ([history expansion](http://mywiki.wooledge.org/BashPitfalls#echo_.22Hello_World.21.22)). I thought "aha, it should be escaped!", did so, and did not get any error messages, but it no longer functioned as intended (as per the earlier linked page).
|
||||
|
||||
The latter line will work everywhere, not just in environments without history expansion. I think trying a command manually before putting it into crontab is common, and this would avoid the possible user issue I ran into.
|
||||
|
||||
----
|
||||
|
||||
I wonder what this program (ikiwiki-calendar) is useful for. Would not it be simpler to have the [[calendar|ikiwiki/directive/calendar]] directive generate the `archive_base/year/month.mdwn` files on the fly, as are the tag pages generated by the [[tag|plugins/tag]] plugin? This solution would have the advantage of automatically generating the right calendar pages, instead of having to tell ikiwiki-calendar which years to take into account.
|
||||
|
||||
Using this solution would mean to have the pagespec stored somewhere in the configuration. But this is already the case, as the pagespec used by [[ikiwiki-calendar]] is either set in the configuration file of the wiki, or in the crontab or whatever script used to call ikiwiki-calendar.
|
||||
|
||||
Having done this, the only purpose of ikiwiki-calendar would be to re-generate the wiki on a daily (or whatever frequency) basis, which can be done using ikiwiki instead of ikiwiki-calendar.
|
||||
|
||||
Did I miss something? If I am right, I offer to write the necessary patch, copied and adapted from the tag plugin, to generate the pages `archive_base/year/month.mdwn` on the fly.
|
||||
|
||||
-- Spalax
|
||||
|
||||
> Good spotting, `ikiwiki-calendar` predates the `add_autofile` API used to
|
||||
> autocreate tag pages and was bolted in as an easy way to create calendar
|
||||
> pages.
|
||||
>
|
||||
> It would be possible to do that inside the caneldar plugin now. Although
|
||||
> some command would still need to be run on a daily (or weekly, or
|
||||
> monthly, or yearly..) basis to have it wake up and make the new calendar
|
||||
> pages and update the displayed current day from calendar directives.
|
||||
>
|
||||
> That last is, arguably, the real point of running ikiwiki-calendar in
|
||||
> a cron job. Of course all it really does is run `ikiwiki -setup foo
|
||||
> -refresh`. --[[Joey]]
|
||||
|
|
@ -12,7 +12,7 @@ ikiwiki-makerepo bzr|mercurial srcdir
|
|||
|
||||
`ikiwiki-makerepo` injects an existing `srcdir` directory, containing
|
||||
sources for an ikiwiki wiki, into revision control. It is rarely
|
||||
run directly; consider using `ikiwiki -setup /etc/ikiwiki/wiki.setup` instead
|
||||
run directly; consider using `ikiwiki --setup /etc/ikiwiki/wiki.setup` instead
|
||||
to set up a wiki.
|
||||
|
||||
For git, the `repo` is created as a bare git repository, and the srcdir is
|
||||
|
|
|
|||
|
|
@ -172,3 +172,5 @@ Personal sites and blogs
|
|||
* [SolderPad Documentation](http://docs.solderpad.com)
|
||||
* various sub-domains at kisikew.org ([example](https://portal.kisikew.org/))
|
||||
* [Paul Elms](http://paul.elms.pro) Personal site and blog in russian.
|
||||
* [James' Tech Notes](http://jamestechnotes.com) My technical notes, blog, wiki, personal site.
|
||||
* [Salient Dream](http://www.salientdream.com/) - All Things Strange.
|
||||
|
|
|
|||
|
|
@ -17,3 +17,5 @@ can be calculated automatically.
|
|||
It can be [found here][3].
|
||||
|
||||
[3]: http://www.tahina.priv.at/hacks/googlemaps.html
|
||||
|
||||
See also [[plugins/contrib/osm]].
|
||||
|
|
|
|||
|
|
@ -0,0 +1,13 @@
|
|||
[[!template id=plugin name=osm author="Blars Blarson, Antoine Beaupré"]]
|
||||
[[!tag type/special-purpose todo/geotagging]]
|
||||
|
||||
Openstreetmap/Openlayers support for ikiwiki
|
||||
--------------------------------------------
|
||||
|
||||
This plugin provides simple Openstreetmap/Openlayers support for ikiwiki. It can embed Openstreetmap viewports within a page or link to a bigger map that will have multiple markers, generated with a KML (or CSV, or GeoJSON) datafile of markers based on the different calling pages. Multiple distinct maps on a single wiki are supported.
|
||||
|
||||
Plugin was originally written by [[the techno-viking|http://techno-viking.com/posts/ikiwiki-maps/]] and fixed up by [[anarcat]]. Code is available at `git://src.anarcat.ath.cx/ikiwiki-osm.git`. See [[this page|http://anarcat.ath.cx/software/ikiwiki-osm/README]] for a more complete description and [[the Mtl-mesh wiki|http://mesh.openisp.ca/nodes/anarcat]] for a sample of what this plugin can do.
|
||||
|
||||
See also [[plugins/contrib/googlemaps]].
|
||||
|
||||
This plugin would be greatly improved by [[todo/internal_definition_list_support]].
|
||||
|
|
@ -3,3 +3,8 @@
|
|||
I tried exactly that, namely having an inline in my sidebar to include an rss feed from some other side. I think the complete wiki rebuild should be doable every few days when a new article appears in that feed. But contrary to that warning there is no complete wiki rebuild, only the sidebar page is rebuilt by the "ikiwiki --aggregate" from cron. Is that a bug or a feature?
|
||||
|
||||
> It's a bug, discussed in [[bugs/transitive_dependencies]]. --[[Joey]]
|
||||
|
||||
I needed to include inline directives into sidebars at different site sections to generate a dynamically updated navigation - very nice when combined with toggles - and I ran into the very same problem. I tried the map directive instead, but found I wouldn't like to re-style everything and also was missing the ability to make use of the show=title variable giving me meta titles where needed without taking the cost of rebuild with every page edit.
|
||||
|
||||
Then I came across the tip to include the quick=yes variable with the inline directive, where it is described as not showing page titles included with the meta-directive, and I thought, well if it lets me have it only this way, maybe I can restrain from using meta titles.
|
||||
But to my surprise, even with the quick=yes variable included into the inline directive in the sidebars meta titles still are shown, no more forced rebuild when editing via cgi, which is amazing, but maybe it should be noted somewhere. One more time ikiwiki showed its bright face, thank you. --Boris
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ The theme plugin allows easily applying a theme to your wiki, by
|
|||
configuring the `theme` setting in the setup file with the name of a theme
|
||||
to use. The themes you can choose from are all subdirectories, typically
|
||||
inside `/usr/share/ikiwiki/themes/`. See [[themes]] for an overview
|
||||
of the themes included in ikiwiki.
|
||||
of the themes included in ikiwiki and the [[theme market]] for third party themes.
|
||||
|
||||
You can set the theme via the **theme** option in your config file (after
|
||||
enabling the plugin). Refresh the wiki after changing it to see the changes.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,8 @@
|
|||
# Sandbox
|
||||
|
||||
[[!pagestats pages="/tags/*"]]
|
||||
|
||||
<<<<<<< HEAD
|
||||
ttt
|
||||
[[!sidebar content="dfdsfsf""
|
||||
This is my custom sidebar for this page.
|
||||
|
||||
|
|
@ -10,6 +11,7 @@ This is my custom sidebar for this page.
|
|||
|
||||
[[!sidebar ]]
|
||||
|
||||
|
||||
## number 2
|
||||
### number 3
|
||||
|
||||
|
|
@ -18,6 +20,8 @@ This is the [[SandBox]], a page anyone can edit to try out ikiwiki
|
|||
|
||||
[[!toc levels=1 startlevel=2 ]]
|
||||
|
||||
See, online editing :-p
|
||||
|
||||
Let's try this~!
|
||||
|
||||
w00t, how does this look on the **git** end? Well, as a commit of course.
|
||||
|
|
@ -116,6 +120,13 @@ Now we try to write a "code" block starting with a hash sign
|
|||
$ another test
|
||||
|
||||
|
||||
Oh, let's try to do the same thing using sane syntax instead:
|
||||
|
||||
~~~
|
||||
# test 1,2,3
|
||||
$ another test
|
||||
~~~
|
||||
|
||||
Now let's write the same block, with a bullest list preceding it.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,11 @@
|
|||
[[!meta title="Theme Market" description="user-contributed themes for ikiwiki"]]
|
||||
|
||||
This is a directory of user-contributed ikiwiki themes. For more information about themes, see the [[plugins/theme]] page.
|
||||
|
||||
It is usually preferable (and more maintainable) to create a [[css]] file instead of a full theme, but sometimes the HTML produced by ikiwiki just isn't compatible with your template, so you need to modify the templates provided. This is when you need to make your own theme.
|
||||
|
||||
Feel free to add your own [[theme|themes]] here, but first consider writing a simpler [[css]] file and adding it to the [[css market]] instead, or look at the [[themes]] shipped with ikiwiki.
|
||||
|
||||
* **[[AntPortal theme|https://github.com/AntPortal/ikiwiked]]**, contributed by Danny, see an example [[on the Antportal wiki|https://antportal.com/wiki/]]
|
||||
|
||||
* **[[Night city theme|http://anarcat.ath.cx/night_city/README/]]**, contributed by [[anarcat]], see an example [[on his homepage|http://anarcat.ath.cx/]]
|
||||
|
|
@ -5,3 +5,5 @@ I would like to contribute a theme I created and posted on github:
|
|||
For an example of the theme in action, see: [[https://antportal.com/wiki/]]
|
||||
|
||||
> Shouldn't we just make people post their themes in the [[themes]] page? Or maybe we should make a [[theme market]]? --[[anarcat]]
|
||||
|
||||
> I did just that. -- [[anarcat]]
|
||||
|
|
|
|||
|
|
@ -0,0 +1,25 @@
|
|||
Please consider providing a plugin for [BrowserID](https://browserid.org/) authentication, preferably enabled by default.
|
||||
|
||||
Some additional information on BrowserID:
|
||||
|
||||
- <https://github.com/mozilla/browserid/wiki/How-to-Use-BrowserID-on-Your-Site>
|
||||
- <http://identity.mozilla.com/post/7616727542/introducing-browserid-a-better-way-to-sign-in>
|
||||
- <http://identity.mozilla.com/post/7669886219/how-browserid-differs-from-openid>
|
||||
- <http://identity.mozilla.com/post/7899984443/privacy-and-browserid>
|
||||
|
||||
> I would like to see BrowserID offered as a signin option in ikiwiki
|
||||
> right next to the buttons for common openid providers.
|
||||
>
|
||||
> As far as implementing it goes, I don't want to rely on browserid.org.
|
||||
> This means that include.js needs to be shipped with ikiwiki (or in a
|
||||
> dependency in a sane world).
|
||||
>
|
||||
> And it means that relying on a https
|
||||
> connection to browserid.org to verify the user's identity assertion
|
||||
> token is out. (Well, it's probably out anyway, since it relies on https
|
||||
> CA security as the only security in that part of the protocol.)
|
||||
>
|
||||
> This seems to need an implementation, in perl or an externally callable
|
||||
> program (haskell would be fine ;),
|
||||
> of <https://wiki.mozilla.org/Identity/BrowserID#Assertion_Verification>.
|
||||
> --[[Joey]]
|
||||
|
|
@ -0,0 +1,68 @@
|
|||
[[!template id=gitbranch branch=chrismgray/exclusive-hooks author="[[chrismgray]]"]]
|
||||
|
||||
Sometimes plugins register a function with `hook`, but they only want
|
||||
the function called with the content that they know how to deal with.
|
||||
Normally, this means that they call `pagetype` first thing in the
|
||||
function, determine if they know how to deal with the content, and
|
||||
only do anything if they do.
|
||||
|
||||
> So, I can't find any plugins shipped with ikiwiki that actually do that.
|
||||
> Scan hooks are only ever passed the content of actual wiki pages, and
|
||||
> so unless a scan hook cares whether a page is written in markdown or
|
||||
> something else, it has no reason to care what the pagetype is. (Same for
|
||||
> linkify.) --[[Joey]]
|
||||
|
||||
>> My [[org-mode|todo/org_mode]] external plugin (which will never
|
||||
>> really make sense to include with ikiwiki I think) does this. I
|
||||
>> think that most plugins defining alternate wiki syntaxes would as
|
||||
>> well. --[[chrismgray]]
|
||||
|
||||
This is a bit wasteful in itself, but for external plugins, it's
|
||||
really bad. For functions like `scan` and `linkify`, where the entire
|
||||
page is sent back and forth over `stdout` and `stdin`, it really slows
|
||||
things down.
|
||||
|
||||
Thus, I propose that there be a new optional parameter to `hook` that
|
||||
tells it that the function should only be called for files whose type
|
||||
is the same as the id of the plugin calling `hook`. I have called
|
||||
this parameter `exclusive` in my branch, but this might not be the
|
||||
best name.
|
||||
|
||||
[[!tag patch]]
|
||||
|
||||
> It's an interesting idea, but it might be more useful if it was more
|
||||
> generalized, say, by making it a filter, where the parameter is a regexp.
|
||||
>
|
||||
> --[[KathrynAndersen]]
|
||||
|
||||
>> Would it make more sense as a pagespec? That might be a bit more hard
|
||||
>> to implement, but would certainly fix the naming issue.
|
||||
>>
|
||||
>> --[[chrismgray]]
|
||||
|
||||
>>> Considering where it would be called, a pagespec might be overkill. --[[KathrynAndersen]]
|
||||
|
||||
>>>> Pagespecs have some overhead themselves. Probably less than shipping
|
||||
>>>> the page content over stdio.
|
||||
>>>>
|
||||
>>>> Rather than putting filtering in the core of ikiwiki, I can think
|
||||
>>>> of two options. One is to make the main plugin a perl plugin, and
|
||||
>>>> have it call functions that are provided by another, external plugin.
|
||||
>>>> This is assuming you're using the other language because something
|
||||
>>>> is easy to do in it, not to avoid writing perl.
|
||||
>>>>
|
||||
>>>> Or, the external plugin interface could provide a version of `hook()`
|
||||
>>>> that does not pass the content parameter, but saves a copy that
|
||||
>>>> the plugin could request with a later rpc call. Assuming that
|
||||
>>>> it's really the overhead of serializing the page content, that's
|
||||
>>>> the problem, and not just the general overhead of making rpc calls
|
||||
>>>> for every page.. --[[Joey]]
|
||||
|
||||
>>>>> Since the argument to `hook` is optional, the pagespec is only
|
||||
>>>>> interpreted if it is given. So there is no extra overhead
|
||||
>>>>> (beyond an unused `if` branch) in 99% of the cases.
|
||||
>>>>>
|
||||
>>>>> Rewriting the external plugin's shim using Perl is a good idea,
|
||||
>>>>> and one that I wish I had thought of earlier. On the other
|
||||
>>>>> hand, it doesn't set a great precedent about the usability of
|
||||
>>>>> external plugins. --[[chrismgray]]
|
||||
|
|
@ -0,0 +1,40 @@
|
|||
While ikiwiki can support definition lists (`dl/dt/dd`) through [[multimarkdown|mdwn]], it doesn't actually /do/ anything with those valuable definitions. It would be interesting for third party plugins to have access to this stuff as a proper data structure. This is what allows MoinMoin to have plugins that collect that data across multiple pages and tabulate it, for example.
|
||||
|
||||
What I am proposing here is that the [[variables exported to plugins|plugins/write/#index6h2]] be extended to include a `%dictionnaries` hash. For a markup like this:
|
||||
|
||||
[[!format txt """
|
||||
Apple
|
||||
: Apple is a fruit
|
||||
: It's also a computer company
|
||||
Orange
|
||||
: Orange is a fruit
|
||||
"""]]
|
||||
|
||||
would result in a data structure like this:
|
||||
|
||||
[[!format txt """
|
||||
%dicts = {
|
||||
'Apple' => [ "Apple is a fruit", "It's also a computer company" ],
|
||||
'Orange' => [ "Orange is a fruit" ],
|
||||
}
|
||||
"""]]
|
||||
|
||||
Now, I know I can write myself a `format()` parser that would do this on all pages in my own plugin, but then it would need to be adapted to all markups, while markup formatters should be the ones implementing this directly, if possible.
|
||||
|
||||
My first use case for this would be to extend the [[plugins/contrib/osm]] plugin to tap into those lists, so that I could have this data in the page, visible to the user:
|
||||
|
||||
[[!format txt """
|
||||
Longitude
|
||||
: -45.30
|
||||
Latitude
|
||||
: 73.67
|
||||
"""]]
|
||||
|
||||
and then reuse that data in the plugin.
|
||||
|
||||
Then for us running the humongous [[koumbit wiki|https://wiki.koumbit.net/]], it is a necessary step to be able to migrate away from MoinMoin to Ikiwiki as we have a lot of pages that tabulate information like this. For example, see our [[ServerList|https://wiki.koumbit.net/ServerList]] ([[source|https://wiki.koumbit.net/ServerList?action=raw]]), being generated from pages like [[this one|https://wiki.koumbit.net/metis.koumbit.net]].
|
||||
|
||||
If there are no objections to that concept, I may try to start coding patches. Otherwise this is really just a [[wishlist]].
|
||||
|
||||
> Have you looked at the [[plugins/contrib/field]] plugin? This gives you the infrastructure, and all you need is to write a plugin that parses the definition list format. Then you could use [[plugins/contrib/getfield]], [[plugins/contrib/ftemplate]] and/or [[plugins/contrib/report]] to do what you like with the data.
|
||||
> --[[KathrynAndersen]]
|
||||
|
|
@ -18,3 +18,5 @@ Note that for example dokuwiki has a [[nice plugin|http://danjer.doudouke.org/te
|
|||
>>>>> Have you tried running it with "verbose" turned on, and noting the output? That could give some clues.
|
||||
>>>>> And no, the PDFs are not placed in the source dir, only in the destination dir.
|
||||
>>>>> -- [[KathrynAndersen]]
|
||||
|
||||
**Edit (17.02.2012)**: I have put an extended version of the question on webmasters.stackexchange: [[http://webmasters.stackexchange.com/questions/24905/run-external-application-on-markdown-source-in-ikiwiki]] , perhaps someone of the ikiwiki programmers is intersted in having this feature too...
|
||||
|
|
|
|||
|
|
@ -18,3 +18,8 @@ installable on a wheezy host. -- [[Jon]]
|
|||
>> not installable on *squeeze*, which is what I care about, rather than
|
||||
>> *wheezy*. Someone needs to backport `libtext-markdown-discount` I
|
||||
>> guess. — [[Jon]]
|
||||
|
||||
>>> For squeeze, it will be appropriate for an ikiwiki backport to
|
||||
>>> still depend on the old markdown. Although a discount backport would be
|
||||
>>> nice! I don't want the current ikiwiki to be held back by requirement
|
||||
>>> that it be installable as-is on squeeze. --[[Joey]]
|
||||
|
|
|
|||
|
|
@ -55,3 +55,7 @@ href="http://jaspervdj.be/hakyll">Hakyll</a>?
|
|||
>> dependency stuff. -- [[tychoish]]
|
||||
|
||||
>>> (nods) Which is why I suggested it. I'm not sure whether it would be easier to "bolt on" those things than static compilation, but it could be worth looking at, at least. -- [[KathrynAndersen]]
|
||||
|
||||
-----
|
||||
|
||||
Rather than coding plugins for the Perl ikiwiki in Haskell, I wonder how easily a Haskell ikiwiki could still support plugins written in Perl? The (old and apparently stale) [HsPerl5](http://hackage.haskell.org/package/HsPerl5) package might provide a helpful starting point there. -- [[JoshTriplett]]
|
||||
|
|
|
|||
|
|
@ -0,0 +1,4 @@
|
|||
I'm Chris Gray. I have an ikiwiki-based blog at
|
||||
[[http://chrismgray.github.com]]. I wrote a plugin for
|
||||
[[org-mode|todo/org_mode]] files that is probably the first ikiwiki
|
||||
plugin written mostly in emacs lisp.
|
||||
|
|
@ -38,7 +38,7 @@ var providers_small = {
|
|||
},
|
||||
wordpress: {
|
||||
name: 'Wordpress',
|
||||
icon: 'https://ddgw.s3.amazonaws.com/wordpress.org.ico',
|
||||
icon: 'https://s2.wp.com/i/favicon.ico',
|
||||
label: 'Enter your Wordpress.com username:',
|
||||
url: 'http://{username}.wordpress.com/'
|
||||
},
|
||||
|
|
|
|||
Loading…
Reference in New Issue