public inbox for documentation@lists.ipfire.org
 help / color / mirror / Atom feed
From: Michael Tremer <michael.tremer@ipfire.org>
To: documentation@lists.ipfire.org
Subject: Re: New Wiki Software - Please help testing :)
Date: Mon, 27 May 2019 17:27:54 +0100	[thread overview]
Message-ID: <E57533C5-5D72-4FDB-936E-4A256F7B1BB4@ipfire.org> (raw)
In-Reply-To: <A424236A-CFD6-419D-ACA7-27E9B1DDC35E@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3022 bytes --]

Hello,

Yes, there are differences in plain markdown.

I have seen that you did a couple of changes and I have a couple of notes about those:

* You used absolute links: This is something that should not be done when linking other pages on the wiki. I have spent a lot of time to make the code fast enough when it fetches the headline of the page so that we will show the correct headline. The absolute links don’t work like that.

So wiki links are possible just as they were before with [[page]] and [[page#Other Title]].

* You used the <img> tag to embed an image. The image pages have a short snippet to embed the image:

  https://wiki.dev.ipfire.org/ipfire_tux_512x512.png?action=detail

All images will always be full widths by default (and there is no reason not do to that) because all pages have to be responsive and we need to be able to read them on mobile. So using custom heights and widths naturally won’t work. We don’t know how large the screen is someone is using.

* Matthias saved the same page a couple of times. That definitely shows that we need a preview function :)

I do not want to point any fingers here at all. But I learned things from this. If it felt natural for you to do these things, but it was meant in another way then this is a bug in the software.

But I have no idea how to find a good solution for this. Admittedly nothing is documented yet, but future editors might not read the documentation. People edit first and I do want anyone to edit this wiki. We care about the information first, but we need to make sure that people do not mess up the markup.

I think that Dokuwiki is quite bad in that sense that it allows to be messy with the markup. This is also why conversion into another language is so difficult. There is multiple ways to do something and they can be mixed. Horror.

So what springs to mind here is: We could refuse saving the page when something is not right. But I think that might feel very frustrating. An <img> tag should never show up. If we find that, then we can just throw an error.

What do you guys think could work?

-Michael

P.S. I pushed out a couple of fixes, but I do not have a preview function yet. Not sure whether I can make that update live or if we will have a button. Or maybe a two-step save process. I need to explore that a little. Please send me your thoughts in case you have any ideas. But make them easy to implement :)

> On 24 May 2019, at 23:03, Jon Murphy <jcmurphy26(a)gmail.com> wrote:
> 
> Michael - It seems like there are some differences between Markdown and the new wiki app.  One is the double brackets, e.g., [[relativeLink]]
> 
> With the old wiki I could search thru the Dokuwiki website for hints. What is the name of the new app?  That will give us a better idea of how to use it.
> 
> Jon
> _______________________________________________
> Documentation mailing list
> Documentation(a)lists.ipfire.org
> https://lists.ipfire.org/mailman/listinfo/documentation


  reply	other threads:[~2019-05-27 16:27 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-24 22:03 Jon Murphy
2019-05-27 16:27 ` Michael Tremer [this message]
2019-05-27 17:10   ` Matthias Fischer
2019-05-30 14:50     ` Michael Tremer
2019-05-28  3:05   ` Jon Murphy
2019-05-30 14:51     ` Michael Tremer
     [not found] <2CAE7946-C451-4D11-B3C6-9C64CAFC1220@gmail.com>
2019-07-17 15:57 ` Michael Tremer
2019-07-17 22:57   ` Jon Murphy
2019-07-18 10:16     ` Michael Tremer
     [not found] <4BB6A887-545C-4194-B497-16E08FE82231@gmail.com>
2019-05-30 19:04 ` Michael Tremer
2019-05-30 19:23   ` Jon Murphy
2019-05-30 19:24     ` Michael Tremer
2019-05-30 19:30       ` Jon Murphy
2019-06-02 22:13         ` Michael Tremer
     [not found] <3917C587-0660-4EA5-A997-081C3A69D045@gmail.com>
2019-05-30 18:17 ` Michael Tremer
     [not found] <0E1A43E9-96F5-487C-8974-ED25DC70D05B@gmail.com>
2019-05-30 17:31 ` Michael Tremer
     [not found] <630732F1-CA01-43FD-8EB5-4601C6BF3162@gmail.com>
2019-05-30 17:07 ` Michael Tremer
2019-05-30 17:22 ` Michael Tremer
     [not found] <AF378EE0-6263-41AA-A6A0-5442D9C5FCC3@gmail.com>
2019-05-30 14:50 ` Michael Tremer
  -- strict thread matches above, loose matches on Subject: below --
2019-05-24 16:48 Jon Murphy
2019-05-23 13:35 Michael Tremer
2019-05-24 10:58 ` Carlo Fusco
2019-05-24 11:07   ` Carlo Fusco
2019-05-26 10:43     ` Michael Tremer
2019-05-26  8:28 ` Matthias Fischer
2019-05-26 10:54   ` Michael Tremer
2019-05-26 10:55   ` Michael Tremer
2019-06-01 12:09 ` ummeegge
2019-06-02 22:10   ` Michael Tremer
2019-06-06  3:30     ` Jon Murphy
2019-07-16 16:34       ` Michael Tremer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E57533C5-5D72-4FDB-936E-4A256F7B1BB4@ipfire.org \
    --to=michael.tremer@ipfire.org \
    --cc=documentation@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox