emesik/djiki

Djiki is a light and portable Wiki engine based on Django.

djiki's Issues

Make images storage-agnostic

Some tend to keep files on external PaaS. Make it possible.

i18n

It should be possible to use djiki for multi-language content. Two things have to be taken under consideration:

• storage: Different language versions can be stored either in the same database (and the same table), appearing under the same site address. On the contrary, they might be spread among separate, independent servers.
• connection: There must be some way to define interwiki links and resolve them into proper URLs, depending on the storage solution.

The roadmap:

1. Add language field to the Page model and make (title, language) unique instead of title itself.
2. Add DJIKI_LANGUAGE setting with fallback to automatically recognize the language used on site, within the current request context.
3. Add interwiki syntax to the Creole markup and implement a set of basic URL resolvers (perhaps a part of the parser itself).
4. Think how to handle the images

Add Jinja2 templates

Django.views.generic.simple is deprecated since Django 1.3

It's being used in e.g. djiki/views.py.

For further information, please see https://docs.djangoproject.com/en/dev/topics/class-based-views/

Tests

Write tests that check behavior of different settings.py

recovery or support for '/' in target-page titles

Currently, putting a slash in an intended page title (like say [[about/team]]) results in a nasty TemplateSyntaxError from a 'NoReverseMatch' condition... which can't easily be recovered, as the page now can't be displayed and backing up to the prior edit page doesn't seem to allow replacing the bad content with a new submission.

A way to recover would be nice -- perhaps dumping back to edit on errors? -- but also allowing titles with '/' is beneficial for many uses, so perhaps the functionality now indicated by a trailing /path could instead be moved to a ?query-string or alternate /path-prefix/ in the default urls-mapping.

"title": CharField cannot have a "max_length" greater than 255 when using "unique=True"

Got the error during installation on mysql 5.1.67.

diff -rupN djiki.orig/models.py djiki/models.py
--- djiki.orig/models.py    2014-02-11 14:49:22.198695089 +0000
+++ djiki/models.py 2014-02-11 14:58:16.615661160 +0000
@@ -32,7 +32,7 @@ class Revision(models.Model):


 class Page(models.Model, Versioned):
-   title = models.CharField(_("Title"), max_length=256, unique=True)
+   title = models.CharField(_("Title"), max_length=255, unique=True)

    class Meta:
        ordering = ('title',)

Update django templates

They're based on some old grid. Update them.

from django.utils.importlib import import_module

django.utils.importlib is a compatibility library for when Python 2.6 was still supported. It has been obsolete since Django 1.7, which dropped support for Python 2.6, and is removed in 1.9 per the deprecation cycle.

Use Python's import_module function instead:

from importlib import import_module

Fix your code, please

Split out markup-agnostic package

Having the creole markup not developed by original authors for quite long time, we might split the package into:

djiki (no markup backend)
djiki[creole]
djiki[mediawiki] (once #6 is finished)

MediaWiki parser

Provide a MediaWiki-compatible parser. This is the most popular wiki markup and should be supported. There are some pieces of software that could handle this task:

• mwlib: http://pypi.python.org/pypi/mwlib
• mediawiki-parser: https://github.com/peter17/mediawiki-parser

PEP8 compliance - spaces?

Any chance of converting the Python code to be PEP8 compliant and use spaces not tabs?

http://www.python.org/dev/peps/pep-0008/#tabs-or-spaces

Spaces are the preferred indentation method.

Tabs should be used solely to remain consistent with code that is 
already indented with tabs.

This is actually one of the biggest reasons I wouldn't contribute to this project. I would have to configure my editor to use tabs for this project, when it uses spaces for every single other Python project that I work on. I could write something that detects tabs in existing modules, but for new files in a project it's not possible.

The arguments about the relative merits of spaces/tabs aren't relevant here. The advantages of everyone doing the same thing outweigh other considerations, and PEP8 is the de-facto standard for Python projects. When I see a Python project with tabs instead of spaces, which are pretty few and far between, especially in the Django ecosystem, I tend to assume the author is not a team player, and it discourages me from contributing at all.