nedroden / draiwiki Goto Github PK

The current system is broken, unreliable and inefficient, and should be replaced / fixed.

When navigating to /DraiWiki/, instead of the homepage, the **Edit Article: New page ** opens with the following error:

When trying to write an article there, saving navigates to:

http://localhost/draiwiki/%3Cbr%20/%3E%3Cfont%20size='1'%3E%3Ctable%20class='xdebug-error%20xe-notice'%20dir='ltr'%20border='1'%20cellspacing='0'%20cellpadding='1'%3E%3Ctr%3E%3Cth%20align='left'%20bgcolor='?id=%3Cbr+%2F%3E%0D%0A%3Cfont+size%3D%271%27%3E%3Ctable+class%3D%27xdebug-error+xe-notice%27+dir%3D%27ltr%27+border%3D%271%27+cellspacing%3D%270%27+cellpadding%3D%271%27%3E%0D%0A%3Ctr%3E%3Cth+align%3D%27left%27+bgcolor%3D%27%23f57900%27+colspan%3D&title=New+article&body=aaaa#f57900%27%20colspan=

The html is maybe generated by my own phpdebug application?

'''
if (!$this->_language == 'en_US' && file_exists(Main::$config->read('path', 'BASE_PATH') . 'lang/' . $this->_language . '/' . $className . '.language.php'))
$this->_strings[lcfirst($className)] = require_once Main::$config->read('path', 'BASE_PATH') . 'lang/' . $this->_language . '/' . $className . '.language.php';
else if (Main::$config->read('path', 'BASE_PATH') . 'lang/en_US/' . $className . '.language.php')
$this->_strings[lcfirst($className)] = require_once Main::$config->read('path', 'BASE_PATH') . 'lang/en_US/' . $className . '.language.php';
else
die('Could not load language file.');
'''

That would make things a little bit cleaner.

For security reasons, password strength requirements should be added to the registration process. It would save time to use an existing library, so we might as well go with one of these (other suggestions are welcome):

https://github.com/bjeavons/zxcvbn-php
https://github.com/rchouinard/phpass

If there's time, this will be added to Alpha 1. If not, it'll be pushed to Alpha 2.

Templates are loaded AFTER we've executed a database query to figure out what template set we need to load, so any errors that occur before that moment can't use error templates. Right now it doesn't really matter since we're automatically using die() if there are no templates, but I'd like something a little prettier.

Although this isn't hard to fix, basic functionality should be implemented first.

Rather than having the language switcher look something like this: EN | ES | NL | RU | SV, I'd like to have a popup, simply because that would be pretty neat.

I'm still not sure whether we'll go with AngularJS or JQuery, but either way, it should look similar to this (though we might ditch the flags):
https://trex-docs.s3.amazonaws.com/2016/Jan/language_selector_default_2d25024ce770d4a5de754b1483b00bae-1452321339515.png

This would make updating external libraries a little easier. Also, when there is a new version, the end user would have the option to update using the terminal.

Its methods currently do too much, so we need to change that.

Currently the Main class creates a new instance of the Connection class. After that, it creates a new instance of the Locale class. The thing is, however, the Connection class produces localized errors (i.e. it makes use of the Locale class), meaning it needs to create a new instance before it is able to do so. So basically, the line in the Main class is redundant.

TL;DR: We should find a way (shouldn't be too difficult) to keep the line that creates a new Locale object in the Main class.

Although I'd like to get the basic functionality working first, once that's done we should probably convert some sections/forms to work with AJAX.

We should add Wikipedia-like infoboxes. This should probably be done using PHP and SQL; that way the user would be able to reuse an infobox.

We should definitely add the ability to ban users/IPs.

Since we've just created this cool new registry class, we might as well make good use of it. We should attempt to replace most (if not all) singletons with regular classes that are called using the registry.

Since charts and graphs look cool, we should have some on the admin panel's dashboard. We should have charts/graphs for at least the following items:

• Articles per language
• Edits per week/month
• Registrations per week/month

Since this should be really easy to do (I've come across several libraries that take care of creating graphs/charts), it should be implemented before we release Alpha 1.

There's no locale model yet, but once we have one, the getters, setters and queries should be moved there.

Using AngularJS would've been really neat, however with the deadline approaching it might be easier to switch to a different framework. VueJS should do nicely.

It's possible we'll switch back to AngularJS once 1.0 Final is out and we start working on 1.1, but that will be discussed on a more appropriate date.

Apparently, after changing the constants to variables, I forgot to make the keys lowercase.

Should be fixed. ;)

Since Twig requires PHP7 (which is a great thing, but unfortunately we still support PHP5.6), it looks like we're going with Dwoo instead.

This should definitely be done before releasing alpha 1.

An extension could be written to accomplish this, but it might be quicker (and easier) to just include it by default. It would be turned off by default.

Just posting this here since posting new articles and editing existing ones should work, but since we have we have no permission profiles, groups and users yet, foreign key checks fail, causing a database error.

As soon as the authentication system has been implemented, this issue will be updated. Again, both creating and modifying articles should work, it just needs to be confirmed.

If the user disabled redirects, a nice page should be displayed that explained what's happening.

So we've finally found a location where we can put the search bar, now we just need to implement the actual search functionality. Not a priority, but it needs to be done before the release of Alpha 1.

The sidebar should have a 'delete' button that changes the article's status to 'deleted'. This would be a soft delete button.

In the admin panel you would be able to hard delete articles.

To be honest, it looks a little weird.

We need a sidebar menu like we had before the rewrite.

Whenever the the verifySession() method fails and we're NOT dealing with a guest, it should be logged and categorized as a security breach. An option could be added to (temporarily) ban the ip.

I'd really like to get this done in Alpha 1.

If a fatal error occurs, we should show a nice error page.

Although I would really really really love to do it right now, unfortunately this will have to wait until DraiWiki 1.1. We're currently require version 5.6, which is still partly (but not entirely) supported, and this prevents us from using features introduced in PHP7.1, such as return type declaration and the null coalescing operator.

Should be done in Alpha 2 or 3.

Error messages, failed login attempts, etc.

Not sure why I made them uppercase.

Root accounts should have the ability to edit wiki files from within the admin panel, in order to make wiki customization a little easier. All files except for files in the admin, src/core, vendor and node_modules directories should be editable. Part of the reason why the admin panel is (for the most part) isolated is to allow you to fix mistakes easily if you've screwed up.

Since this could cause security risks, only root accounts should be able to do this.

Although the session handler works, it leaves a lot to be desired. For example: the open and close functions don't do anything. Rewriting the class wouldn't be a bad idea, as we now know what caused the session handler not to function in the first place.

Should be done using the Swiftmailer library.

Alpha 1 will feature a sidebar, but it won't be customizable. It'd be awesome if you can add your own items, though, in alpha 2 we should make sure you can.

Once Alpha 1 is out we should start working on a modules system that allows users to install modules and extensions.

Extensions would be small additions/changes to the code, whereas modules would introduce major new features (e.g. a blog system, forum, CMS...).

Again, this would have to be done in Alpha 2 since the deadline for Alpha 1 is on July 15.

Let me explain: currently, if an article doesn't exist and you're trying to create it, you get a cool form. While that's absolutely fantastic, when dealing with a new article the editor doesn't display the title of the article that doesn't exist. Rather, it uses the title from the locale files. For English that would be 'New article'.

So, in short, when creating a new article, we should make it so that the editor automatically retrieves the desired title from the URL. Obviously, it'd have to be validated before it could be used.

Although it shouldn't be too difficult to fix, I'm posting it here just in case I forget.