claudioc / jingo

Node.js based Wiki

JINGO

A git based wiki engine written for node.js, with a decent design, a search capability and a good typography.

Table of contents

• Introduction
• Features
• Installation
• Authentication and Authorization
• Known limitations
• Customization
• Editing
• Configuration options reference

Introduction

The aim of this wiki engine is to provide an easy way to create a centralized documentation area for people used to work with git and markdown. It should fit well into a development team without the burden to have to learn a complex and usually overkill application.

Jingo is very much inspired by (and format-compatible with) the github own wiki system Gollum, but it tries to be more a stand-alone and complete system than Gollum is.

Think of jingo as "the github wiki, without github but with more features". "Jingo" means "Jingo is not Gollum" for more than one reason.

There is a demo server running at http://jingo.cica.li:6067/wiki/home

Features

• No database: Jingo uses a git repository as the document archive
• Markdown for everything, github flavored
• Jingo uses Codemirror or Markitup as the markup editor, with a nice (ajax) preview (see the features key in the config file)
• It provides a "distraction free", almost full screen editing mode
• Compatible with a wiki created with the Gollum wiki
• Revision history for all the pages (with restore)
• Show differences between document revisions
• Paginated list of all the pages, with a quick way to find changes between revisions
• Search through the content and the page names
• Page layout accepts custom sidebar and footer
• Gravatar support
• Can include IFRAMEs in the document (es: embed a Google Drive document)
• Generate Table of Contents for pages
• Can use custom CSS and JavaScript scripts
• White list for authorization on page reading and writing
• Detects unwritten pages (which will appear in red)
• Automatically push to a remote (optionally)
• Mobile friendly (based on Bootstrap 3.x)
• Quite configurable, but also works out of the box
• Works well behind a proxy (i.e.: the wiki can be "mounted" as a directory in another website)
• Pages can be embedded into another site
• Authentication via Google, Github, LDAP and local name/password

For code syntax highlighting, Jingo uses the node-syntaxhighlighter module. For the list of supported languages, please refer to this page.

Installation

npm install -g jingo or download/clone the whole thing and run npm install.

Note: if you already have Jingo installed, please also run npm prune (some modules can be stale and need to be removed).

Jingo needs a config file and to create a sample config file, just run jingo -s, redirect the output on a file and then edit it (jingo -s > config.yaml). The config file contains all the available configuration options. Be sure to provide a valid server hostname (like wiki.mycompany.com) if you use a 3rd party provider for authentication (like Google or GitHub). It is needed for them to be able to get back to you.

This document contains also the reference for all the possible options.

If you define a remote to push to, then Jingo will automatically issue a push to that remote every pushInterval seconds. To declare a remote for Jingo to use, you'll need to identify the name of your local remote. The following example shows how a local remote is typically defined:

git remote add origin https://github.com/joeuser/jingorepo.git'

Based on that example, you would update config.yaml with the remote name "origin" as follows:

remote: "origin"

You can also use the git remote command to get the name of your remote.

You can also specify a branch using the syntax "remotename branchname". If you don't specify a branch, Jingo will use master. Please note that before the push, a pull will also be issued (at the moment Jingo will not try to resolve conflicts, though).

The basic command to run the wiki will then be

jingo -c /path/to/config.yaml

Before running jingo you need to initialise its git repository somewhere (git init is enough). Additionally the user running the process needs to have git config --global user.name and git config --global user.email configured. Else your document's repo will get scrambled and you have to reinitialize it again (rm -rf .git && git init).

If you define a remote to push to, be sure that the user who'll push has the right to do so. This means you have to configure the remote via the git:// URI that uses ssh authentication to push and have created and published the process user's ssh public key to the remote.

If your documents reside in subdirectory of your repository, you need to specify its name using the docSubdir configuration option. The repository path must be an absolute path pointing to the root of the repository.

If you want your wiki server to only listen to your localhost, set the configuration key localOnly to true.

Authentication and Authorization

You can enable the following strategies: Google logins (OAuth2), GitHub logins (OAuth2), ldap logins or a simple, locally verified username/password credentials match (called "local").

The Google Login and the GitHub login uses OAuth 2 and that means that on a fresh installation you need to get a client id and a client secret from Google or GitHub and put those informations in the configuration file.

For Google, follow these instructions (you need to be logged in in Google):

• Open the Google developer console
• Create a new project (you can leave the Project id as it is). This will take a little while
• Open the Consent screen page and fill in the details (particularly, the product name)
• Now open APIs & auth => Credentials and click on Create new client id
• Here you need to specify the base URL of your jingo installation. Google will fill in automatically the other field with a /oauth2callback URL, which is fine
• Now you need to copy the Client ID and Client secret in your jingo config file in the proper places

For GitHub, follow these instructions (you need to be logged in in GitHub):

• Register a new application here
• Enter whatever Application name you want
• Enter your installation URL (localhost is OK, for example "http://localhost:6767/")
• Enter /auth/github/callback as the Authorization callback URL
• Press the Register application button
• In the following page, on the top right corner, take note of the values for Client ID and Client Secret
• Now you need to copy the Client ID and Client secret in your jingo config file in the proper places

Warning In certain cases the Github authentication system return an empty email and Jingo is not happy about this. To avoid problems, when using Github set the authorization.emptyEmailMatches configuration option to true.

The ldap method uses url as the ldap server url, and optionally a bindDn and bindCredentials if needed. The searchBase and searchFilter are required for searching in the tree. In the configuration searchAttributes is also available. Since we want to install the (binary) support to LDAP only when needed, please manually npm install passport-ldapauth to use the LDAP support.

The local method uses an array of username, passwordHash and optionally an email. The password is hashed using a non salted SHA-1 algorithm, which makes this method not the safest in the world but at least you don't have a clear text password in the config file. To generate the hash, use the --hash-string program option: once you get the hash, copy it in the config file.

You can enable all the authentications options at the same time. The local is disabled by default.

The authorization section of the config file has three keys: anonRead, validMatches and emptyEmailMatches.

If anonRead is true, then anyone who can access the wiki can read anything. If anonRead is false you need to authenticate also for reading and then the email of the user must match at least one of the regular expressions provided via validMatches, which is a comma separated list. There is no "anonWrite", though. To edit a page the user must be authenticated.

emptyEmailMatches allows access when remote authentication providers do not provide an email address as part of user data. It defaults to false, but will usually need to be set to true for GitHub authentication (GitHub only returns email addresses that have been made public on users' GitHub accounts).

The authentication is mandatory to edit pages from the web interface, but jingo works on a git repository; that means that you could skip the authentication altogether and edit pages with your editor and push to the remote that jingo is serving.

Known limitations

• The authentication is mandatory (no anonymous writing allowed). See also issue #4
• The repository is "flat" (no directories or namespaces)
• Authorization is only based on a regexp'ed white list with matches on the user email address
• There is one authorization level only (no "administrators" and "editors")
• No scheduled pull or fetch from the remote is provided (because handling conflicts would be a bit too... interesting)

Please note that at the moment it is quite "risky" to have someone else, other than jingo itself, have write access to the remote / branch jingo is pushing to. The push operation is supposed to always be successfull and there is no pull or fetch. You can of course manage to handle pull requests yourself.

Customization

You can customize jingo in four different ways:

• add a left sidebar to every page: just add a file named _sidebar.md containing the markdown you want to display to the repository. You can edit or create the sidebar from Jingo itself, visiting /wiki/_sidebar (note that the title of the page in this case is useless)
• add a footer to every page: the page you need to create is _footer.md and the same rules for the sidebar apply
• add a custom CSS file, included in every page as the last file. The default name of the file is _style.css and it must reside in the document directory (but can stay out of the repo). It is not possible to edit the file from jingo itself
• add a custom JavaScript file, included in every page as the last JavaScript file. The default name of the file is _script.js and it must reside in the document directory (but can stay out of the repo). It is not possible to edit the file from jingo itself

All these names are customizable via the customizations option in the config file (see the reference).

Once read, all those files are cached (thus, not re-read for every page load, but kept in memory). This means that for every modification in _style.css and _script.js you need to restart the server (sorry, working on that).

This is not true for the footer and the sidebar but ONLY IF you edit those pages from jingo (which in that case will clear the cache by itself).

Editing

To link to another Jingo wiki page, use the Jingo Page Link Tag.

[[Jingo Works]]

The above tag will create a link to the corresponding page file named jingo-works.md. The conversion is as follows:

1. Replace any spaces (U+0020) with dashes (U+002D)
2. Replace any slashes (U+002F) with dashes (U+002D)

If you'd like the link text to be something that doesn't map directly to the page name, you can specify the actual page name after a pipe:

[[How Jingo works|Jingo Works]]

The above tag will link to Jingo-Works.md using "How Jingo works" as the link text.

Images

If you put images into the repository, Jingo will be able to serve them. You can enable Jingo to serve even other file types from the document directory: you need to change the staticWhitelist configuration option.

Configuration options reference

application.title (string: "Jingo")

This will be showed on the upper left corner of all the pages, in the main toolbar

application.logo (string: "")

Supply the full URL to an image to be shown as the logo of your wiki. It will appear on the left of the page title in the navigation bar. Just set the application.title to an empty string to only show the Logo image. Please note that Jingo does not resize the image in any way (you can do it yourself using a custom CSS of course)

application.favicon (string: "")

Supply the full URL to an image to be shown as the favicon of your wiki. Please note that Jingo will try to get the mime type of the image from its extension (this can easily fail for a lot of reasons)

application.repository (string: "")

Absolute path for your documents repository (mandatory).

application.docSubdir (string: "")

If your documents reside inside a directory of the repository, specify its name here.

application.remote (string: "")

This is the name of the remote you want to push/pull to/from (optional). You can also specify a specific branch using the syntax “remotename branchname”. If you don’t specify a branch, Jingo will use master.

application.pushInterval (integer: 30)

Jingo will try to push to the remote (if present) every XX seconds

application.secret (string: "change me")

Just provide a string to be used to crypt the session cookie

application.git (string: "git")

You can specify a different git binary, if you use more than one in your system

application.skipGitCheck (boolean: false)

Jingo will refuse to start if a version of git is found which is known to be problematic. You can still force it to start anyway, providing true as the value for this option

application.loggingMode (integer: 1)

Specifies how verbose the http logging should be. Accepts numeric values: 0 for no logging at all, 1 for the a combined log and 2 for a coincise, coloured log (good for development)

application.pedanticMarkdown (boolean: true)

(the default was false in jingo < 1.1.0)

The markdown module we use (Marked) tries to overcome some "obscure" problems with the original Perl markdown parser by default. This produces some problems when rendering HTML embedded in a markdown document (see also issue #48). By default we now want to use the original parser and not the modified one (pedantic: true).

With this option you can revert this decision if for some reason your documents are not rendered how you like.

application.gfmBreaks (boolean: true)

Enable GFM line breaks

application.proxyPath (string: "")

If you want jingo to work "behind" another website (for example in a /wiki directory of an already existing intranet), you need to configure it to be aware of that situation so that it can write all the outbound URLs accordingly. Use this option to pass it the name of the directory that you've configured in your proxy_pass option in nginx or apache. See also an nginx example in the /etc directory of the jingo source distribution.

Please note that jingo won't work correctly if this option is activated.

application.allowHtml (boolean: false) New since version 1.9.0

Since version 1.9.0 Jingo sanitizes HTML by default, escaping it while rendering Markdown. Esplicitely enable html rendering again with the allowHtml option set to true. Remember that this will also enable, among all the other HTML elements, rendering of <script> though, so beware!

Setting this option to true will generate a warning during Jingo startup.

Also note that Jingo session cookie is http only and cannot be read by JavaScript.

authentication.staticWhitelist (string: "/\.png$/i, /\.jpg$/i, /\.gif$/i")

This is to enable jingo to serve any kind of static file (like images) from the repository. By default, Jingo will serve *.md files and *.jpg, *.png, *.gif. Provide the values as a comma separated list of regular expressions.

authentication.google.enabled (boolean: true)

Enable or disable authentication via Google logins

authentication.google.clientId

authentication.google.clientSecret

Values required for Google OAuth2 authentication. Refer to a previous section of this document on how to set them up.

authentication.google.redirectUrl (string: /oauth2callback)

Specifies a custom redirect URL for OAuth2 authentication instead of the default

authentication.github.enabled (boolean: false)

Enable or disable authentication via Github logins

authentication.github.clientId

authentication.github.clientSecret

Values required for GitHub OAuth2 authentication. Refer to a previous section of this document on how to set them up.

authentication.google.redirectUrl (string: /auth/github/callback)

Specifies a custom redirect URL for OAuth2 authentication instead of the default

authentication.ldap.enabled (boolean: false)

Enable or disable authentication via LDAP logins Requires manual installation of passport-ldapauth module via npm

authentication.ldap.url

authentication.ldap.bindDn

authentication.ldap.bindCredentials

authentication.ldap.searchBase

authentication.ldap.searchFilter

authentication.ldap.searchAttributes

authentication.local.enabled (boolean: false)

The Local setup allows you to specify an array of username/password/email elements that will have access to the Wiki. All the accounts must resides in the configuration authentication.local.accounts array

authentication.local.[accounts].username

Provide any username you like, as a string

authentication.local.[accounts].passwordHash

Use an hash of your password. Create the hash with jingo -# yourpassword

authentication.local.[accounts].email

If you want to use Gravatar, provide your gravatar email here.

authentication.alone.enabled (deprecated)

Boolean, defaults to false The Alone authentication option is deprecated in favor of the Local one

authentication.alone.username (deprecated)

Provide any username you like, as a string The Alone authentication option is deprecated in favor of the Local one

authentication.alone.passwordHash (deprecated)

Use an hash of your password. Create the hash with jingo -# yourpassword The Alone authentication option is deprecated in favor of the Local one

authentication.alone.email (deprecated)

If you want to use Gravatar, provide your gravatar email here. The Alone authentication option is deprecated in favor of the Local one

features.markitup (boolean: false)

DEPRECATED: markitup support has been removed as of version 1.8.0

features.codemirror (boolean: true)

Whether to enable Codemirror or not.

features.gravatar (boolean: true)

Whether to enable gravatar support or not

server.hostname

This is the hostname used to build the URL for your wiki pages. The reason for these options to exist is due to the need for the OAuth2 authentication to work (it needs an endpoint to get back to)

server.port

Jingo will listen on this port

server.localOnly

Set this to true if you want to accept connection only from localhost (default false)

server.CORS.enabled (boolean: false)

Enable or disable CORS headers for accessing a page through an ajax call from an origin which is not the one which serves Jingo. Use this option if for example you want to embed a (rendered) page inside a page of another website.

The configuration options for CORS are at the moment quite limited: via an Ajax call you can only read (GET) a wiki page (that is, the /wiki/NameOfYourPage path), or issue a search. Once you enable this option, all the wiki page will be accessible. Please note that no authentication check is made, which means that the Ajax calls will be denied if the anonRead configuration option will be false (all or nothing).

You can also white-list origin via the following option (CORS.allowedOrigin)

server.CORS.allowedOrigin (string: "*")

Set the allowed origin for your CORS headers. All the Ajax calls to the wiki pages must come from this origin or they will be denied. The default is "*", which means that all the origins will be allowed

server.baseUrl

The baseUrl is usually automatically generated by Jingo (with "//" + hostname + ":" + port), but if for some reason you need to overrideit, you can use this option

authorization.anonRead (boolean: true)

Enables/disables the anonymous access to the wiki content

authorization.validMatches (string: ".+")

This is a regular expression which will be used against the user email account to be able to access the wiki. By default all emails are OK, but you can for example set a filter so that only the hostname from your company will be allowed access.

authorization.emptyEmailMatches (boolean: false)

If the endpoint doesn't provide the email address for the user, allow empty emails to authenticate anyway. Note that GitHub authentication usually requires this to be true (unless all wiki users have public email addresses on their GitHub accounts).

pages.index (string: "Home")

Defines the page name for the index of the wiki

pages.title.fromFilename (boolean: true)

If this is true, the title of each page will be derived from the document's filename. This is how Gollum works and from Jingo 1.0 this is now the default. An important consequence of this behavior is that now Jingo is able to rename documents (according to the new name it will be eventually given to), while previously it was impossible.

pages.title.fromContent (boolean: false)

If this is true, the title of the document will be part of the document itself (the very first line). This is the default behavior of Jingo < 1.0 and the default is now false. If you have an old installation of Jingo, please set this value to true and fromFilename to false.

pages.title.asciiOnly (boolean: false)

If this is set to true, Jingo will convert any non-Ascii character present in the title of the document to an ASCII equivalent (using the transliteration module), when creating the filename of the document. Default was true for Jingo < 1.0 while for Jingo >= 1.0 the default is false

pages.title.lowercase (boolean: false)

If this is set to true, Jingo will lowercase any character of the title when creating the filename. Default was true for Jingo < 1.0 while for Jingo >= 1.0 the default is false

pages.title.itemsPerPage (integer: 10)

This defines how many page item to show in the "list all page" page. Keep this value as low as possible for performance reasons.

customizations.sidebar (string: "_sidebar.md")

Defines the name for the sidebar component. Defaults to _sidebar.md. Please note that if you need to use a wiki coming from Github, this name should be set to _Sidebar

customizations.footer (string: "_footer.md")

Defines the name for the footer component. Defaults to _footer.md. Please note that if you need to use a wiki coming from Github, this name should be set to '_Footer'

customizations.style (string: "_style.md")

Defines the name for the customized style CSS component. Defaults to _style.css.

customizations.script (string: "_script.md")

Defines the name for the customized script JavaScript component. Defaults to _script.js.

jingo's Issues

Auth handshake fails in 403 (sometimes)

Despite I can successfully login to our Jingo instance, users repeatedly report errors which are reflected by the thrown 403 below.

x.x.x.x - - [22/Jan/2015:08:21:05 +0100] "GET /auth/github HTTP/1.1" 302 0 "http://wiki.transformap.co/login?destination=%2Fwiki%2FTransforMap" "Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.3.0"
x.x.x.x - - [22/Jan/2015:08:21:06 +0100] "GET /auth/github/callback?code=07548d1af20764a1a354 HTTP/1.1" 302 76 "http://wiki.transformap.co/login?destination=%2Fwiki%2FTransforMap" "Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.3.0"
x.x.x.x - - [22/Jan/2015:08:21:07 +0100] "GET /auth/done HTTP/1.1" 403 29 "http://wiki.transformap.co/login?destination=%2Fwiki%2FTransforMap" "Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.3.0"

I'm running Jingo behind a nginx reverse proxy and proxy_buffering off;.

How can this error happen? Why does the user receive a forbidden status?

Sidebar shows its title

It seems like if the sidebar is present, Jingo will show its title instead of removing it

Diff is shown inverted

If you add a line on a doc, the subsequent diff will show the new line in red.

npm version is outdated

hi

Some useful patch like "fix jade error" are not applied on 0.5.1 version

it's a minor but annoying issue ;)

Automatically create a fragment for H* headers

This is what Gollum does automatically

Normalize newlines

Remove ^M

Issue with favicon

When I run jingo -c config.yaml I get this error:

fs.js:696
  return binding.stat(pathModule._makeLong(path));
                 ^
Error: ENOENT, no such file or directory '/home/alex/Desktop/ninth-hour/public/favicon.ico'
    at Object.fs.statSync (fs.js:696:18)
    at favicon (/home/alex/.node/lib/node_modules/jingo/node_modules/serve-favicon/index.js:55:15)
    at Object.module.exports.initialize (/home/alex/.node/lib/node_modules/jingo/lib/app.js:107:11)
    at start (/home/alex/.node/lib/node_modules/jingo/jingo:82:34)
    at /home/alex/.node/lib/node_modules/jingo/jingo:77:3
    at Object.<anonymous> (/home/alex/.node/lib/node_modules/jingo/lib/gitmech.js:153:7)
    at ChildProcess.exithandler (child_process.js:656:7)
    at ChildProcess.emit (events.js:98:17)
    at maybeClose (child_process.js:766:16)
    at Socket.<anonymous> (child_process.js:979:11)

I'm on Ubuntu 14.04, and I've installed jingo globally using the sudoless npm install.

Pull before edit

When you click on the Edit button, Jingo should issue a pull request and then open the edit page

Process exits after accessing unknown page history

Sometimes I notice that my process has died, even when I don't recall explicitly having accessed unknown pages. Logs say the history of an unknown page was requested. I suppose it could happen if a web crawler tries to reindex a previously present page.

To reproduce:
Assuming wiki.myhost.com is jingo, go to
http://wiki.myhost.com/wiki/some_made_up_page/history

Instead of a 404, the process will exit with the error:

/app/node_modules/jingo/lib/tools.js:14
    var title = content.split("\n")[0];
                        ^
TypeError: Cannot call method 'split' of undefined
    at Object.tools.getPageTitle (/app/node_modules/jingo/lib/tools.js:14:25)
    at /app/node_modules/jingo/routes/index.js:428:36
    at /app/node_modules/jingo/lib/gitmech.js:215:9
    at ChildProcess.<anonymous> (/app/node_modules/jingo/lib/gitmech.js:36:7)
    at ChildProcess.EventEmitter.emit (events.js:98:17)
    at maybeClose (child_process.js:743:16)
    at Process.ChildProcess._handle.onexit (child_process.js:810:5)

This does not happen with normal unknown page access, which redirects to a 404.

The pageHistory function in routes/index.js does check for error in the same as pageShow and tries to redirect to /, so it's not clear to me what is happening here.

MarkItUp Editor not working - no errors on console.

The MarkItUp editor doesn't seem to change anything in its associated textarea.

No errors are thrown on the console. UI interaction works (buttons, alerts, ...).

Crashes on start if some optional values is missing in config

Test the presence of pages object in the config, for example

Feature Request: GitHub authentication

Any plans to support GitHub login? Considering the compatibility with GitHub Wiki / Gollum, I reckon being able to authenticate through GitHub is just as attractive as Google.

Server crash (Syntax highlighter)

I'm getting an error with one of my wiki page:

Error: You need to pass a language obtained via "getLanguage"
Please report this to https://github.com/chjj/marked.
    at Object.highlight (/opt/jingo/node_modules/node-syntaxhighlighter/node-syntaxhighlighter.js:81:24)
    at Object.Marked.setOptions.highlight (/opt/jingo/lib/renderer.js:12:16)
    at Parser.tok (/opt/jingo/node_modules/marked/lib/marked.js:837:33)
    at Parser.parse (/opt/jingo/node_modules/marked/lib/marked.js:778:17)
    at Function.Parser.parse (/opt/jingo/node_modules/marked/lib/marked.js:765:17)
    at marked (/opt/jingo/node_modules/marked/lib/marked.js:1017:19)
    at Object.Renderer.render (/opt/jingo/lib/renderer.js:77:12)
    at exports.miscPreview (/opt/jingo/routes/index.js:423:23)
    at callbacks (/opt/jingo/node_modules/express/lib/router/index.js:161:37)
    at param (/opt/jingo/node_modules/express/lib/router/index.js:135:11)

I suspect yaml syntax.

modal-backdrop obscures content

Clicking on any modal popup shows the modal-backdrop at z-index: 1040 while the rest of the site appears to be z-index: 0.

Hide the search textbox if anonRead = false

In the layout, remove the search box if the anonymous cannot read documents (thus, it cannot issue searches)

Unable to use the alone auth method on a recent installation of jingo.

I have been using this wiki with no problems in the past. But then, I tried to upgrade it (to see if there was a newer version) and then I was unable to log in.

I tried to uninstall it and then reinstall it to no avail.

Using node-inspector, I found out that res.locals.user is always undefined.

Since I noticed that the version of jingo I had and the version I just installed are the same version, my best guess is that, while the jingo version was the same, one of the dependencies was upgraded. That is very likely, since jingo's package.json uses the * wildcard as the required version of several dependencies.

I tried to install jingo on a different pc to be 100% sure, and no, I can't install it there either.

Plugin System

I am proposing to think about a Plugin System for Jingo, maybe version 2.
Generally accepted use of npm as the package manager is clear.

Together with this, seperation of Client and Server could be undertaken, to render Jingo more data friendly (thus, being an Open API at the core). It would innovate by providing an HTTP API to a git backed Markdown Wiki. Additionally this seperation would make it more easy for me to include real time aspects for an Etherwiki.

Plugins should have names like jingo-plugin-persona, jingo-plugin-ether or jingo-plugin-rss. What these do could then be discussed in seperate Repos.

I will try to build both into core first, but as a plugin would be much more appreciated.

Small typo in revision history.

I'm just running jingo locally; revision history is lacking a space after the page title just inbetween the word and the french braces.

api?

Is there api documentation on how to access the wiki externally through rest or w/e other protocol?

Thanks.

Table rendering using HTLM tags

There is an issue rendering tables in the wiki using HTML tags instead of MD syntax.
The table will be aligned in the bottom of the page.

Steps to reproduce:
Create a new page and paste the following code:

## TITLE

<table>
  <tr>
    <th>header</th>
    <td>test</td>
  </tr>
</table>

### SUBTITLE

There is an unexpected gap between the TITLE and the Table.

Search should be restricted to `docSubdir`

Now that docSubdir is implemented, I think the scope of search should be restricted to this folder.

I have a big git repo where I keep all personal docs/notes. When I search something in jingo, it is searching the whole repo (which is a nice feature(!) to have sometimes), but it is miserably slow.

I suggest there be a run-time flag to search "only the wiki" or "entire repo".

Thanks!

Redirect Loop

Steps

1. Clone Jingo
2. Create directory wiki_src
3. Create config.yaml in wiki_src
4. Set username and password in config.yaml, set application.repository to "wiki_src"
5. Fire up the server. It works!
6. Create the home document in the web gui.
7. Save
8. Get error wiki_src/.git is not a git repository
9. Hit back
10. Hit save again

The result is a redirect loop.

It looks like Home.md was saved, however.

What sort of log files should I check to help diagnose this issue? Environment is Windows, Node 0.10.

Option to have file names as page titles

It would be nice to optionally (config option?) have the page titles determined by the file name (and not have the # Title in the files), for compatibility/interaction with GitHub Wikis.

P.S.: Love Jingo!

Missing page title on the compare page

The compare page misses the title of the page the versions of which we are comparing

Unable to run jingo in windows environment

node jingo -c config.yaml
Output:
Unrecognized git semver (1.9.4.msysgit.2)

Github flavoured todo lists

In Github's version of markdown I can create todo lists:

• Buy pizza base
• Prepare olives
  • Buy olives
  • Soak olives in salt

(hrmph, no support for nested lists yet 💀 )

"Create new" view has no title set

When creating a new page, the proposed title will not show up in the tab/browser title, as <title></title> is empty.

feature request, porting to git backed ssdb?

Git backed by redis alternative ssdb. Is that possible? In return I can help u code other api etc

Links in footer are not clickable.

I've just pulled new commits from Jingo and were happy to see Sidebar and Footer support.

Both work well, but appearantly links put in the footer are not clickable.

At short sight, I don't know why it's blocked.

Table of Content

Gollum has an interesting feature: automatic table of content generation.
Usage: [[_TOC_]]
It would be nice to have such feature in Jingo.

Good job so far, great project

Simple login method

A simple login method for local installations would be very desirable.
By simple, I mean: salted password or some such method. Easy way to do this would be to have a command line option to generate salted passwords for a user:

jingo --generate-salt username password

The admin can then copy this into the config file. This should suffice for personal wikis and the like.

Thanks for making a great project!

Highlight lines matching the search results

When opening a page from a search page, highlight the line containing the term

Login Page shows empty sidebar, if _sidebar.md is present.

The sidebar is displayed correctly on all other pages.

[UX] Escape to close preview

The Ctrl P shortcut to preview is great. Please add ability to close the preview with ESC.

exppress-validator not properly instantiated in express pipeline.

When I initially downloaded jingo through git, it was hanging on every request.

After looking at the code I noticed that express-validator wasn't being instantiated properly.

Instead of:

  app.use(expValidator);

it should be

  app.use(expValidator());

Redirect loop

After login, I was shown an edit view for Home page. But after saving, I can't see any page because I get a "redirect loop" error from the browser:

Error 310 (net::ERR_TOO_MANY_REDIRECTS): There were too many redirects.

Editing from mobile browser

Unfortunately it isn't possible to edit articles when using a mobile browser (at least not on my Nexus 5 using Chrome), because the toolbox is outside the visible area.

Installation problem

Hi

When trying to install I get the following warnings and errors.

npm WARN engine [email protected]: wanted: {"node":"0.8.x","npm":"1.1.x"} (current: {"node":"0.10.31","npm":"1.4.23"})
npm ERR! fetch failed https://registry.npmjs.org/iconv/-/iconv-2.1.4.tgz
npm ERR! Error: 400 Bad Request
npm ERR!     at WriteStream.<anonymous> (C:\Program Files\nodejs\node_modules\npm\lib\utils\fetch.js:58:12)
npm ERR!     at WriteStream.emit (events.js:117:20)
npm ERR!     at evalmachine.<anonymous>:1609:14
npm ERR!     at C:\Program Files\nodejs\node_modules\npm\node_modules\graceful-fs\graceful-fs.js:102:5
npm ERR!     at Object.oncomplete (evalmachine.<anonymous>:107:15)
npm ERR! If you need help, you may report this *entire* log,
npm ERR! including the npm and node versions, at:
npm ERR!     <http://github.com/npm/npm/issues>

npm ERR! System Windows_NT 6.1.7601
npm ERR! command "C:\\Program Files\\nodejs\\\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "install" "jingo"
npm ERR! cwd C:\Windows\system32
npm ERR! node -v v0.10.31
npm ERR! npm -v 1.4.23
npm ERR!
npm ERR! Additional logging details can be found in:
npm ERR!     C:\Windows\system32\npm-debug.log
npm ERR! not ok code 0

The command was executed in a console with admin rights. Also I could not locate the file - npm-debug.log - on my system.

Link images

There should be a way to use images from inside the repository

Mobile-responsive CSS

Should not be too much trouble to lightly modify the jade files and style.css with appropriate classes so that the sidebar and footer don't look like crap on mobile browsers. I've already added some specific element classes/ids (#sidebar/#footer/.markdown-body etc.) in a dev branch that makes things like tables look much better.

It would be nice to have a clean mobile interface. I will take a look into it. Posting this for accountability, heh.

Use codemirror for the edit area

Codemirror can be used with highlight support for Markdown (see Ghost)

Redirect to the requested page upon login

requesting page X and logging in, should redirect me to page X

Custom style/script broken

The customization section states that that _style.css and _script.js in the repository will be included as custom CSS/Javascript; however, I'm only able to get this to work if the files end in .md. I believe this is caused by line 22 of the components.js, which hardcodes .md to the filename it is looking for:

  this.file = this.getConfig().customizations[this.name] + ".md";

(As an aside, I think the wiki would be more flexible if it looked for other common file extensions, like .markdown, or even .text, but that's probably a separate issue...)

Make demo using GitHub Wiki

Unless I've completely misunderstood how Jingo works, it should be possible to use Jingo essentially as an alternative front-end for a GitHub Wiki, correct? (If I'm mistaken then I'd appreciate some explanation on what you mean by "compatible".)

Then how about making a demo site that's hooked up with a live GitHub Wiki, so we can see this in action? I'm not very keen on signing up to a demo app, but I'd have no qualms about making edits via GitHub's interface and seeing how they're reflected in Jingo.

Demo server is down

Can't find demo of jingo ((( I tried a demo server running from example -

http://jingo.cicali.cc:6067/wiki/home

Ability to set a path inside a git repo.

I already have a git repo for all my documents and would like to add a wiki directory inside this for use through jingo.

Can you please add a config option for specifying the directory path inside the repo under which jingo does its business.

For example if the config option is:

repository:"/blah/"
storePath:"wiki"

Then jingo would store the pages inside the wiki directory in the blah repository.

Trim pagenames before creating the file

trailing and leading spaces are left in the page names.

Add the last commit message to the page list

It would be nice to see what was the last change on a page.

Create a plugin for codemirror to insert pages

It should not be difficult to add a feature for codemirror to select one of the existing pages to be linked while editing a document

Bad google login is persistent

If you enter an unauthorized e-mail you will have to clear the browser's data for the page to attempt another login.