sbrl / pepperminty-wiki Goto Github PK

Generating search result context appears to have broken when I tried it today on Windows.

Showing a page's tags on the list of all pages would probably be a good idea.

register_save_preprocessor() isn't mentioned in the docs yet. We really should update the docs to make module development easier.

The pages in the sidebar should be sorted alphabetically.

If you delete the pageindex, it doesn't pick up on files associated with the pages it finds.

A module to allow redirects to be created would be a good idea.

With it we have several things to think about:

• What if we encounter a redirect loop?
  • Perhaps we could add a cookie to the request that tracks the number of redirects the user has had and use that to track long redirect chains
• How do we store the fact that a page is a redirect page?
  • Changing the page index is probably not a good idea - this would be a module - what if the module was not installed?
  • Perhaps it would be better to store the redirect information inside the page itself, similar to the way you have #REDIRECT [[Page Name]] in mediawiki.

If we create the page Page A/New, the page index entry for Page A doesn't get updated with a reference to Page A/New.

In order to fix this, we need to fix #12 first - otherwise we could crash in certain circumstances.

Since this wiki software is aimed at small-ish wikis, perhaps having an optional sidebar that shows a list of all the pages & folders on the current wiki would be a good idea.

Quote from /u/Theis:

A better navigation system would be useful. Personal I would like to use this for note taking. So a sidebare with folders and markdown pages to navigate would be beautiful :)

The folders depend on issue #6 though. Things to do:

• Implement issue #6
• Add support for HTML insertion by modules
• Implement sidebar
• Add option to settings to turn the sidebar off / on

Hello

There is a tag </datalist> alone

look this picture

cheers

The page list gives lots of useful information, but it currently gives me information overload. This issue will track the improvement of the page list.

Let's start by gathering some examples of how others have displayed page lists.

This causes inconsistencies to arise when the idindex is consulted.

We should make the links to non-existent pages red. To start with, we need to write a module to post-process a given page's HTML and add a class to the internal links that lead to pages that don't exist.

Tasks:

• Work out how to tell the difference between internal links and other links
• Work out how to determine if a given page exists
• Write a post processor to add a class to the internal linking <a /> tags that lead to pages that don't exist

Implementing issue #38 is nice, but it currently doesn't work with the login button in the top corner, only with the forced redirected on private wikis. We should make it work for all login mechanisms.

The links on an uploaded file's page don't work - The page name is not being carried over correctly.

The site secret is not needed to delete pages.

The question is though, should the site secret be needed to delete pages?
Please comment below - I am a little unsure on this.

It moves the file, but doesn't save the pageindex properly.

Perhaps we should add a parsedown module that adds Parsedown as a parser to Pepperminty Wiki. It should be optional and not included by default since this module might add some significant weight to an installation.

• Add support for extensions that aren't included in the build by default (issue #10)
• Create parsedown extension

Line 342 of index.php : There is a head tag instead of body
cheers

For some reason random new pages are being created when the pageindex is regenerated. This probably has something to do with #27.

A recent changes page would be very helpful in order to see what has been going on recently on a wiki.

It's awesome that we have support for tags in Pepperminty Wiki, but we need to have a link to it somewhere else on the wiki. Perhaps the list of pages would be a good candidate? The top bar is getting kind of full, unless we add a link in the "More..." menu.

Private wiki owners may not want other people to read their wiki content. We should add support for private wikis.

• Require login to view pages
• Add support for moving the root in which files are stored (to prevent people from circumventing the wiki itself) - Issue #37
  • Make sure that we proxy the 'original image' button if access control is enabled, as the web root will likely have been moved to somewhere inaccessible from the web

If you aren't logged in, you get redirected to the login page. However, the sidebar (in extra-sidebar) can be used to view the names of pages on the wiki. We should fix this as it could cause private information to leak to unauthorised users.

We should implement sub pages.

Things that need checking / doing:

• Check that the page name escaper correctly handles forward slashes
• Add support for sub-pages to the page index
  • Add field that indicates whether a given pages has any sub pages
• Update the page-list extension to support sub-pages
• Add support for sub pages to the page index rebuilder
• Allow sub pages to be saved in sub folders
• Display a configurable list of sub pages on pages that have sub pages

Update:

Bugs to fix before this is done:

• Fix issue #11 - Non-existent subpage parents aren't added to $pageindex->$page->subpages
• Fix issue #12 - Creating a page with a non-existent parent doesn't cause the parent to be created
• Fix issue #13 - Creating a sub page doesn't result the subpage[] entry being updated

It would be nice to allow editors to upload images. This will probably have to be a separate project though. Naming suggestions are welcome!

This has the advantage that we can have a level of integration between the two projects. For example, we could have short syntax for images since we will know already where they are uploaded to. We would also be able to keep information about who uploaded the images, and how much space is taken up by images, too.

Tagging pages would aid organisation and make it easier to find them later.

• Add support for adding / changing tags when editing a page
• Add a page that lists the pages with a specific tag
• Display the associated tags beneath each page
• Link the displayed tags to the page that lists all the pages with that page

It picks up the directory that a page's subpages are stored in as an associated file, when it really isn't.

We should have a short syntax for referencing files uploaded to the current wiki.

When deleting a page, we don't clean up the inverted index or the id index. We ought to clean these up to avoid potential problems later on.

• Remove page from id index
• Remove page from the inverted search index
• Test to make sure that the above works

The help page is useful, but it could be better. We should upgrade it to allow modules to register their own help sections.

We need better themes for this thing. In particular, we need a better default theme.

I will probably need help with this.

Quote from reddit user /u/Theis:

But I really think a better userinterface is needed, maybe use something like Bootstrap. The thing is that regular non-technocal people get scared away from something that looks too bare. Or maybe just clone the look and feel from Githubs wiki.

Having the new theme based on GitHub's wiki theme seems like a good idea.

Allowing the directory in which Pepperminty Wiki stores stuff to be changed allows the administrator to move the data storage directory outside the webroot. This is an important step for #25 Access control.

As the title suggests. If you create the page Page A/Non/New, and the page Page A/Non doesn't exist, it won't be created. The same goes Page A in this instance too. If it doesn't exist, it won't be created.

If I click login while on a page called 'Oranges' for example, when the login process is completed I end up on the main page. This is really annoying as I lose my place on the site and forget what I was doing.

We should redirect the user to the exact page that they were upon before logging in.

This is already partially implemented, but currently has some bugs. We should finish the job and fix all the bugs.

If you search for something that isn't a page whilst logged out on a wiki that doesn't allow anonymous edits, then it tells you that you can create the page, even when you can't.

If I add, say, lion to a page that didn't have it before, it doesn't show up in the search results. I do, however, get it weird junk at the bottom of the search index.

//...
    "animal": {
        "3": {
            "freq": 1,
            "offsets": [2]
        }
    },
    "jam": {
        "3": {
            "freq": 1,
            "offsets": [3]
        }
    },
    "0": {
        "2": "testing",
        "1": "page"
    },
    "1": {
        "1": "internal"
    },
    "2": {
        "1": "link"
    },
    "3": {
        "1": "non"
    },
    "4": {
        "1": "existent"
    }
}

This issue is part of issue #28.

This would make it much easier to read and understand.

This bug is in the $pageindex creator. Assuming the following structure:

Page A
Page A/Sub 1
Page A/Sub 1/Sub Sub 1

If, for example, the page Page A/Sub 1 didn't exist, then it would be created and added to $existingpages ready for adding to the $pageindex. This is all OK, but if Page A is already added to the new $pageindex, then the non-existent Page A/Sub 1 won't be added to Page A's ->subpages object index.

The solution, I assume, to this problem would be to check to make sure that the all the sub-pages parents exist in both the file system and the $existingpages array before we start looping, but a solution that doesn't involve a second loop here would be desirable.

I would try and think of one now, but dealing with all these sub-pages is confusing...!

Workaround: Delete the bugged pageindex.json and get it to recreate it a second time.

Moving a page that has an associated file doesn't result in the file being moved also.

The current search facility only directs the user to a specific page. I would be nice if it would actually search the site if it can't find an exact match. Perhaps an upgrade is in order?

Firstly we should do some research on how to create a search engine in PHP which doesn't take ages to find anything.

The problem lies in the fact that if someone gets hold of the network traffic, they can impersonate the an unsuspecting user.

If the sidebar is enabled, it shows on the printable version of a page. This is probably not what we want.

We should write some documentation on the mod API that we have so far. This will allow others to pick up the API and write their own plugins more easily.

Page protection can be enabled, but not disabled.

If you disable editing via $editing = false;, it doesn't prevent the editing / deleting of pages.

Having a page that lists all the tags on Pepperminty Wiki is great, but it doesn't look particularly pleasant. We should make it look nicer so that it is more of a pleasure to use and fits in with the rest of the wiki,

We should allow modules to be optional and not included in the default build. This is in preparation for issue #9.

If a page has an associated file, deleting doesn't delete the associated files. This could use up disc space and be rather annoying.

It would be awesome if instead of talk pages, it were possible to comment on any given page. Perhaps we could use a system similar to that of the blog over at starbeamrainbowlabs.com, where you can comment and then reply to comments.

This would possibly require us to store users' email addresses for notification purposes.

This issue will track the implementation of this mega enhancement as a new module.