OpenCPN Dokuwiki - Comments

[rgleason]

Ok I think Indexmenu is now working.
https://forum.dokuwiki.org/post/54830
The wiki should be checked to be sure before we continue editing.
TOOLBAR Buttons [Opencpn]

[rgleason]

I added an OpenCPN logo. Should I make it a tad smaller?

At the top under the logo:

I am trying to tighten up the real estate a little.
Why? I suggest you try it on your cell phone http://tgp-architects.com/dokuwiki/
It's pretty darn good, but there is some space used at the top. The logo size seems to be the limiting factor.
It is 60x60 now. The default dokuwiki logo.png was 64x64.

Do we want the You are here: or Trace?
I can shorten them, so they stay on one line. Also I believe I can eliminate one or both of them. Sometimes they are useful.

You are here: OpenCPN » OpenCPN » OpenCPN User Manual » TOOLBAR Buttons
Trace: • Chart Info • OpenCPN • OpenCPN User Manual • GPS Setup and Status • Getting Started • TOOLBAR Buttons

I am going to make a couple of TAR backups now!

[rgleason]

Fabbian, I think its ok now, and I backed it all up again.

[fgd3]

Originally Posted by rgleason

Fabbian,
This morning I've been methodically working on getting the CSS back on our active wiki with the help of Myron Turner, but it does not seem to be working. See https://forum.dokuwiki.org/thread/14298

I may need to copy over our backup version to get a fully working wiki. I may be able to keep the documents and just copy the dokuwiki structure, I have to find out from Myron.

The point is however that if I must copy the documents and structure, we are missing one hour of work. By comparing the Recent Changes pages, it seems to be this work of yours:
which seems to span an hour. Can you recall what was done and how extensive or difficult it is to repeat? I am sorry if we loose this and will try not to!

It looks like some of the work I did on those pages was lost but it will be pretty easy to reconstruct it. I'll get to it sometime this week.

Fabbian

[fgd3]

Originally Posted by rgleason

I had to think hard about the [[pencpnpencpn_user_manual links and finally came up with the page I had seen about Namespaces https://www.dokuwiki.org/namespaces

See third example down
It appears both are acceptable. It also appears that I have been doing all links as absolute paths. I am not sure what is best. Yes we could do a search and replace to make things standard, once we know there aren't some special cases.

We're both still learning. It looks like this issue needs more study before we do anything about it. I think we want to use relative paths in all cases (for increased portability) but it still isn't clear to me how to do that. Either way, I think it's easy enough to fix it the way we want with search and replace.

Fabbian

[rgleason]

I think we want to use relative paths in all cases (for increased portability) but it still isn't clear to me how to do that. Fabbian.

I am going to try a couple of dummy new pages with relative naming to see how it works.

In some respects all our wiki pages are relative even now because they all start with the "start" or ":start" page/namespace which is "opencpn" for our books.

If we were to simply move the wiki by copying it, just as it is, it would work fine. In fact I have done that on the server for a backup. It is pretty easy to do and perhaps I should try to do that automatically every 6-12 hours. Try DOKU2 OpenCPN [Opencpn] It is a BACKUP so don't get confused about which one you are editing! I may change this to DOKU-BK

Our wiki actually has two other namespaces:

• "wiki" which contains a duplicate of the Dokuwiki User Manual
• "playground" which contains all of my playground testing.

These are being hidden by a config setting right now.

[rgleason]

Fabbian and other Editors
Here is a Test Page showing what happens with use of relative paths
Test Page in the Edit User Manual section of the O wiki

Summary:
Do not use relative paths!! They do not work and will mess up the wiki structure.
Always start with <code>[[opencpnpencpn_user_manual: ....]] </code>

[rgleason]

Please see this Dokuwiki forum thread about Pros and Cons of namespace tokens, It's also helpful.
https://forum.dokuwiki.org/post/54846;nocount

By the way, I backed the website up again tonight. Hope to get a batch file or script that will do this.

[rgleason]

We have a stopgap backup system, stored on the server using Webmin > Services > Filesystem Backup.
Full Weekly --Dated files --bz2 340mb
Full Daily -- Dated files --bz2 340mb
Partial Hourly --> Dump file is overwritten
Incremental file backup does not seem to be available.
Dump file options to add changed files result in increases of 340mb each time.
If the server fails all backups are gone.
I will have to delete files on a regular basis, every 3 days.

Is there a TAR parameter for incremental backup?
Probably not because it is derived from tape backups.

I guess I have to get rsync loaded and learn and set that up. This is a slow process for me. So if someone has some bright ideas or way to help, it would allow me to get back to doing the wiki perhaps.

[fgd3]

Originally Posted by rgleason

Fabbian and other Editors
Here is a Test Page showing what happens with use of relative paths
Test Page in the Edit User Manual section of the O wiki

Summary:
Do not use relative paths!! They do not work and will mess up the wiki structure.
Always start with <code>[[opencpnpencpn_user_manual: ....]] </code>

I made some small corrections to your test page. You wrote "semicolon" when you meant "colon". You included a leading colon in the example of a path without a colon so I removed it. Finally, I removed the alternate text (the string following the pipe | symbol) when it duplicated the path. The path without the leading colon doesn't require alternate text. The path with the leading colon will not show the leading colon unless you specify it in the alternate text.

I'm glad you discovered the problem with relative paths. As long as every path begins with the book namespace we will still have a portable manual.

Fabbian

[rgleason]

Thank you Fabbin, please feel free to edit these pages as you have some excellent points I may not have gotten across.

As long as every path begins with the book namespace we will still have a portable manual.

Yes!

Which raises a question because we have 4 books under the namespace opencpn. We would like the entire thing to be portable. I do not know the consequences if we were to shorten the paths by eliminating that namespace, (and right now I am not interested in finding out, as I've had enough trouble!).

Also our Indexmenu Plugin (the navigation toc to the right) relies on a page called sidemenu which is hidden but located under the opencpn namespace. I do not know if shortening the pathname would affect the operation, but I expect that all four books would not be as visible (perhaps). I'd have to think about it and do some experiments. In short, it is not simple.

I think that until proven otherwise, we should include opencpn with all of the pathnames please.
For the four "books" / "namespaces" we would then continue to use:

Internal Links
[[opencpn:opencpn_user_manual:____]]
[[opencpn:supplementary_hardware:____]]
[[opencpn:supplementary_software:____]]
[[opencpn:developer_manual:_____]]

Media Links
{{opencpn:manual:____}}
{{opencpn:hardware:____}}
{{opencpn:software:____}}
{{opencpn:dev:_____}}

I think at some point I will do a FIND + SED search to remove the leading semicolons. So continue to use just

[[opencpn:opencpn_user_manual:___]]

without the colon please.

Damn smilies, turn the b___ off.

[rgleason]

Drew, I like your Chart Manual Installation page.
Manual installation | Official OpenCPN Homepage

will move it over.

[rgleason]

Improved Migration Process page under the new oWiki ,
Under: Opencpn User Manual >_Edit User Manual > Migration Process

[fgd3]

Originally Posted by rgleason

Improved Migration Process page under the new oWiki ,
Under: Opencpn User Manual >_Edit User Manual > Migration Process

I made a few minor changes to the Migration process page which I hope make it more clear.

The old user manual pages have three links at the bottom: Table of Contents, previous page, and next page. The previous and next page links were supplied automatically by Drupal. I have been manually coding those three links at the bottom of each page I edited.

I noticed you put a mini-TOC at the bottom of your pages. At the bottom of the Route and Mark Manager page you have a link to the same page. How have you chosen the links you put at the bottom of each page?

As pages are edited in the future the previous and next links may have to be updated (if someone inserts a new page in the manual, for example). Since we have the table of contents on the left do we need any of those links at the bottom of each page? The Table of Contents link leads to a page that duplicates the information in the sidebar. The previous and next page links make it easier to page through the manual if you're reading it like a book, but it's just as easy to follow the sidebar links to the next or previous page (except it sometimes requires the reader to scroll up to find the current part of the TOC).

What do you think about eliminating those bottom of page links?

Fabbian

[fgd3]

I completed the missing five child pages from the Toolbar Buttons/AIS section today. I'm not sure what's been done and what remains to be done. The pages under the Route and Mark Manager page need to have blank pages attached. It looks like we are getting close to finishing the user manual.

Fabbian