nedroden / draiwiki Goto Github PK
View Code? Open in Web Editor NEWOpen source wiki software.
Home Page: https://draiwiki.robertmonden.com
License: Apache License 2.0
Open source wiki software.
Home Page: https://draiwiki.robertmonden.com
License: Apache License 2.0
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.
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.
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.
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.
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:
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.
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.
To be honest, it looks a little weird.
This should definitely be done before releasing alpha 1.
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.
'''
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.');
'''
We need a sidebar menu like we had before the rewrite.
Its methods currently do too much, so we need to change that.
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.
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.
Apparently, after changing the constants to variables, I forgot to make the keys lowercase.
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.
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.
The current system is broken, unreliable and inefficient, and should be replaced / fixed.
Not sure why I made them uppercase.
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.
Error messages, failed login attempts, etc.
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.
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.
There's no locale model yet, but once we have one, the getters, setters and queries should be moved there.
If the user disabled redirects, a nice page should be displayed that explained what's happening.
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.
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
We should definitely add the ability to ban users/IPs.
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:
The html is maybe generated by my own phpdebug application?
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.
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.
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.
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.
Should be done using the Swiftmailer library.
If a fatal error occurs, we should show a nice error page.
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.
That would make things a little bit cleaner.
Should be done in Alpha 2 or 3.
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.
Should be fixed. ;)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.