Note, this is the english page of the article PukiWiki2 (In Japanese)
Add whatever you think would be relevant. This page is for suggested directions for development of PukiWiki 2.0, and to a latter degree the time-frame of the operation perhaps.
- Would be better for a more extensive way for modularisation. An interesting idea would be to allow dependencies, then we can have main handlers more integrated.
- Maybe it'd be an idea to have some form of article history similar to that of mediawiki as a module. I'll whip one up. -- JordanC
- Allow for actual skin handling, and any form of image handling be handled by that skin itself.
- Removal of the strange GLOBAL image array for defining the various images used in skins. Skins should have a relative folder for their own images, and a default image folder for things like hard-coded buttons or so on.
- Perhaps a more simplistic skin format, with code blocks for the wiki-edit box and other stuff being given a generic handler which is then called with one variable, rather than actually having the PHP code in the file. This means that the skins can be much more easily developed by those who don't have PHP experience, and so that things can be changed cosmetically without throwing huge PHP errors. -- JordanC
- The current system for en/ja language should be replaced for gettext and allow for user and global domains. This would only marginally increase the CPU usage.
- An interesting idea would also be to implement a miniature wikicode parser, and allow for pluggable modules or pages which deal with different syntaxes (MediaWiki, PHPwiki and so on) -- JordanC
- Hi. PukiWiki Plus! (A derivation of PukiWiki) is using gettext already. -- 通りすがり
- BugTrack/748 --
- I generally discourage forks and reworks of inactive projects, but the problem with this project is that a lot of time is spent discussing and belittling, rather than coding, discussing and progression. Still, PukiWiki Plus! for me is just a needless excursion :/ -- JordanC
- Less OOP/non-oop mixing, can't we just either go entirely OOP?
- Another idea would be for the export formats. The pages should be stored in an intermediary format which can then be parsed to various types if required through modules (PDF, XML and so on). -- JordanC