Hello, I have a plugin in mind, but before starting to write some code, I come to you to see if something similar already exists, or if there is an easier way to do it.

What I want

I want to be able to have several versions of the same page. For instance (this is not my usecase, but it matches exactly), let's say I am developping a software, with several versions published, and I want:

the latest documentation to be available at http://example.com/doc;
the documentation for previous (or current version, with permanent URL) available at http://example.com/doc/v2_0.

What I am thinking about is:

my wiki has the documentation written in pages doc/v1_0.mdwn, doc/v2_0.mdwn, and so on;
the doc.mdwn page contains nothing but code to copy metadata from the latest doc/*mdwn page, that is: meta information, tag, and ymlfront.

What I have in mind

What I have in mind is a plugin providing a directive pageversion such that the doc.mdwn page contains only:

[[!pageversion  pages="doc/* and !doc/*/*"]]

This would grab the latest documentation page, copy its content, and copy meta information, tags and fields.

How to do it

I see two ways to do it, but both have big drawbacks.

I could, in the preprocess function of the plugin, copy the interesting part of the %pagestate global variable. In pseudo-code, something like:
```
$pagestate{doc}{meta} = $pagestate{doc/v2_0}{meta};
$pagestate{doc}{fields} = $pagestate{doc/v2_0}{fields};
$pagestate{doc}{tags} = $pagestate{doc/v2_0}{tags}; # This one definitely would not work, but it is pseudo-code
```
I fear that some necessary side effects would not occur. For instance, setting date using the meta plugin sets the page creation time at a deeper level. Copying %pagestate would bypass this.
I could, in the preprocess function, call the preprocess function for those three plugins. But this would mean guessing what the original directive arguments were, which can be tricky.

My questions

Does something similar already exist?
Do you have any better idea about how to do it?

RSS

I'm not so sure that copying metadata is desirable

I'm not so sure that copying metadata around is the right solution to the use case that you outlined. If you do that, then /doc/v2.0/ and /doc/ will be indistinguishable anywhere that pages are listed by their metadata - it's as though you'd copied the text content of doc/v2.0.mdwn into doc.mdwn. For example, if it's tagged readme, then a list of pages matching tagged(readme) will have two apparently identical entries, one of which is /doc/ and the other is /doc/v2.0/.

Why not do this instead?

# doc/v2.0.mdwn
[[!tag readme]]
[[!meta title="Foobar documentation, version 2.0"]]

[[!if test="doc/* and created_after(.)" all="no"
  then="""[[!template id="note" text="[Newer versions are available|doc]"]]"""]]

Here is new documentation about Foobar.

# doc/v1.0.mdwn
[[!tag readme]]
[[!meta title="Foobar documentation, version 1.0"]]

[[!if test="doc/* and created_after(.)" all="no"
  then="""[[!template id="note" text="[Newer versions are available|doc]"]]"""]]

Here is documentation about Foobar.

# doc.mdwn
[[!meta title="Foobar documentation"]]
[[!inline pages="doc/*" limit="1" sort="age" feeds="no" actions="no" raw="yes"]]

Older versions:

[[!inline pages="doc/*" skip="1" archive="yes"]]

... or even (with a bit of new code)

# doc.mdwn
[[!meta redir_first_match="doc/*" sort="age"]]

In real life you'd probably want to use a special [[!template]] for the link to the latest version, so that it's easier to make them all consistent, but for those examples I'm just using the standard note and some markup.

this is not my usecase, but it matches exactly

Why not ask us about your real use-case, in case it turns out that it doesn't match exactly after putting more thought into it? :-)

Comment by smcv — Thu Jun 9 11:09:30 2016

Remove comment

More information

[[!if test="doc/* and created_after(.)" all="no" then="""[[!template id="note" text="[Newer versions are available|doc]"]]"""]]

I like that!

Why not ask us about your real use-case, in case it turns out that it doesn't match exactly after putting more thought into it?

Good point: I explained what I wanted; I did not explain why.

The reason I want the metadata, fields and tags to be copied from the last subpage to the main page is to inline them.

On my professional website (I am a math teacher), I have a page list where I list some activities I do in class. For instance, I describe here how I got my students to learn statistics by debunking a psychic's claim. However, I greatly improved this the following year, and published a new version of the same article.

So far I have three pages: .../sismologie/20150110 and .../sismologie/20150819 (the actual articles), and .../sismologie/ (which should reflect the latest article). I want:

both articles to be available;
only the latest one to be visible on the page list (not to highlight outdated articles).

The page list is generated using the report directive (from the report plugin). It references the relative latest page (.../sismologie and not .../sismologie/20150819), and needs to access the meta information, fields and tags.

Right now, what I do is copying "by hand" the meta information of the latest article, which can be error prone, and is tedious to keep up to date. I am thinking about the page version plugin I described earlier not to repeat myself.

Sorry for the long post… I hope it is clear enough…

Louis

Comment by spalax — Fri Jun 10 14:58:08 2016

Remove comment

comment 3

It references the relative latest page (.../sismologie and not .../sismologie/20150819), and needs to access the meta information, fields and tags.

I think this might be the right place to "cut the knot": instead of indirecting through the "latest" page, why not something like this? (this is pseudocode describing a hypothetical plugin, not something you can do right now):

# index.mdwn
[[!report pages="newest(sismologie/*)" ...]]

Or you could keep the indirection but make it explicit, without introducing copying:

# sismologie.mdwn
[[!inline pages="./*" trail="yes" sort="age"]]

# index.mdwn - assume ... is a glob that matches sismologie but not its subpages
[[!report pages="first-trail-member(...)"]]

(first-trail-member doesn't exist, but it could.)

Or maybe a distinct data structure:

# sismologie.mdwn
[[!versions pages="./*"]]

# index.mdwn - assume ... is a glob that matches sismologie but not its subpages
[[!report pages="version-of(...)"]]

Comment by smcv — Sat Jun 11 08:14:21 2016

Remove comment

More thought about the `pageversion` plugin

I like your idea of a pagespec:

# index.mdwn - assume ... is a glob that matches sismologie but not its subpages
[[!report pages="first-trail-member(...)"]]

What I have in mind now, assuming that my website have the following structure:

$ tree
├── blog.mdwn
└── blog
    ├── bar.mdwn
    ├── bar
    │   ├── 20151108.mdwn
    │   └── 20160413.mdwn
    ├── foo.mdwn
    └── foo
        ├── 20160103.mdwn
        └── 20160605.mdwn

I can have a plugin that implements:

a directive [[!versionof parent]] in every actual article (bar/20151108.mdwn, bar/20160413, foo/20160103, foo/20160605) which does two things:
- it registers the pages as being a version of its parent page;
- it displays a text Other versions of this article: ....
a pagespec function latestversion, so that the blog.mdwn page can list the last version of each article using something like [[!report pages="*/* and latestversion()]];
a directive [[!redir_to_latest_version]] (or a nicer, shorter name) in 'meta' articles (foo.mdwn, bar.mdwn), which redirects the page to the latest version of the article (so that http://example.com/blog/foo redirects to http://example.com/blog/foo/20160605 (the latest version of foo)).

Anyway, thank you very much: it may not be the definitive form yet, but it is already much more clean than it was at the beginning.

Comment by spalax — Tue Jun 14 11:36:32 2016

Remove comment

Done!

At last, I wrote this plugin. It was not on the top of my priority list, but I eventually did it.

It is called pageversion.

Thank you very much for your advice: it is far better than what I had in mind before discussing it with you!

Comment by spalax — Sat Feb 18 15:53:15 2017

Remove comment

Add a comment