[Darth-Apple]

Yeah, the project was on a hiatus for way too long. Real life got in the way, and being that it is a large project, it can be stressful to code at times.

A good amount of progress has already been made just today, getting some bug fixes in order and what not. I'm currently working on the ACP at the moment, to add new settings for administrators. The user interface for some things was already put into place without the functionality behind them, so today I'm reworking some of that to complete what has been left unfinished.

I'll try to post some screenshots once some more progress is made there. The ACP won't be too pretty, but at least it should be more functional soon.

[Darth-Apple]

Alright, I'm currently in the process of experimenting with moving the settings to the DB based system over the flat file system. I imagine I'll keep the flat file API (might be useful at some point) but it's a real pain once you start adding a bunch of settings in.

Currently I have no plans for a DB-based API. I'm going straight in and literally coding every single setting individually. Bleh, this isn't going to be fun. We'll see if this turns out to be any easier.

Probably the hardest part about coding this so far is the lack of a good API to use. I've experimented with different APIs, and even have a DB API that I was using, which I've decided against continuing to use. This will be a lot of cleanup... and the code still lacks a good localization system, templates, etc...

Basically, I'm trying to get it fully functional first. After that, I'll focus on figuring out what I'm doing for templates, plugins, etc... As this is my first major, full scale project, I'm pretty much learning as I go.

[Darth-Apple]

It's been a nice few days, and a significant amount of progress has been made. The database-based settings system and the very simple "API" is going very nicely, although a lot of settings are still left to move around and code. The good news is that the system in place works well, and that's a good starting point.

The Mod CP
The Mod CP and approval system is working very nicely. The only thing that's really left to do is to make the mod CP page itself look nice, which hasn't been done yet, but the overall functionality is working very well.

Basically, when a category is created, you will have the option to either require or not to require approval on new uploads. (See screenshot below)


(click for full size)

If a category requires approval, an upload will not immediately be visible publicly. Only administrators and moderators will be able to view the upload, which will allow a moderator to carefully review a submission before approving it. A moderator can, in turn, either delete the upload completely, leave it unapproved, or approve it, allowing it to then be displayed publicly.


(click for full size)


The Code

I realized pretty early on in the project that some of my early framework decisions weren't the best. As a result, the constant effort to recode significant portions of the code continues. The work won't be done in time for the next POC release, but certainly significant improvements are being made.

Even in the notifications, API improvements are being made. I'm setting up a new set of notifications functions that will allow me to, with one line of code, immediately add a notification and know that it will appear in a certain place on the page and appear in the correct format. That alone will be quite an improvement!

I have been fixing a number of bugs, including an annoying bug that caused .zip files not to be able to be uploaded. This has (thankfully) been fixed. Also, various other bugs, including the home menu, ACP related bugs, and more have been fixed. The main known issue left is to fix the login/logout system, which is functional, but is a bit buggy. The login/logout system did not use many of the same API functions that I had coded for other features of the script, so it behaves a little oddly. I'm still looking into recoding the user control panel/login system to behave more appropriately.

The ACP (which was shown in a screenshot above) is still quite a mess. With the frontend, I focused on getting the framework set up first, then the functionality, but I'm quite literally doing the opposite with the backend. I'm programming functionality in before the visual framework, so be prepared for a rough backend for a while.

Either way, stay tuned! I'll be releasing more updates shortly!

[Acko]

As I have said many times earlier, this is great. I will use it for my own site when it is released

[Darth-Apple]

Progress has been continuing. I am still working hard on restructuring existing code and on removing bugs as quickly as possible. I'm also working on making the framework modular, which will mean fully restructuring nearly 5,000 lines of existing, functional code. The advantage is that I will be able to add a new page or section without editing 12 different functions, duplicating unnecessary code, or anything else. The system will be much easier to develop once that's complete, but it will be a tedious process.

As I was reading through previous "release" notes, it (embarrassingly) became apparent to me that POC #2's installer did not even work. Other attachments did not have working installers either, and I believe that there was only one that did work properly. The code, even in its proof-of-concept phases, is simply not ready for release, and I have thus decided to remove all existing attachments from this thread until I am able to fully debug the code, installers, etc...

The original plan was to release POC release #3 this Wednesday. However, as I have coded more and more into the system, the need to restructure has become more apparent. Given the new developments that are in place, it could be as late as the last week of February or early March before the next POC release is out. We shall see.

Anyway, stay tuned for more information. I do plan on releasing the next proof-of-concept release in the near future, and if you would like to help test, please feel free. The more feedback that comes in, the better

[Darth-Apple]

So far, progress on modularizing existing code hasn't gone too badly. I've decided to go the object oriented route. I don't particularly care for using object oriented code unless there is a good reason for it, but in this case, there is a good reason. (You may call me a bad coder for not using classes for everything, but personally I don't like seeing ungodly masses of ugly class syntax first thing when I explore index.php. Classes are undoubtedly a useful tool, but they aren't necessarily the best way to approach everything. )

I will admit that I'm not particularly experienced with variable functions, variable class names, autoload, etc..., but the results will pay off nicely. So far, I've created the basis for a module system, which loads modules automatically, and have created APIs for adding notifications and menu items. Each module has its own class, which has a constructor that adds all hooks. Hooks themselves have their functionality programmed into the $modules class, which so far is pretty basic. Page handlers and action handlers are next (which will be critical if core file edits are to be avoided in adding new modules. )

I've also set up a plugin hook system that can accept arguments, and can run any function, whether inside a class or a normal function. (That was more complicated than it sounds to set up. Particularly the variable class names. ) We'll see how the plugin system works later on. Right now, I'm still pretty early on in this.

The goal is to be able to add new features to the program simply by uploading new modules, without the need to edit any core files. These new modules can add new pages, menu links, notifications, page handlers, form/action handlers, and anything else without the need to edit a single line in the core code.

Wish me luck, restructuring 5,000 lines of existing code to use hooks and modules will be a lengthy process.

EDIT: I've now begun completely rewriting the page handler, meaning pretty much everything will be broken until I'm finished. The good news is that the new page handler will have hooks enabled, allowing modules to add pages very easily. Given how messy the old, hardcoded pagehandler was, this is looking like it will be a great improvement already.

[Darth-Apple]

The beginnings of some minor reskinning work (of course a work in progress! )



Also, I may open this up to some pre-alpha testing in the not too distant future. Would anyone be interested in helping out with that?

[brian51]

good luck with this Blake !
and please keep us posted on your progress with this huge coding project

Thanks, brian

[Darth-Apple]

Thanks, I'll be sure to continue with regular updates.

I've made a few additional theme related improvements, although I haven't done anything particularly major besides fix a few glitches since the last screenshot. I do plan on overhauling the theme again, but for now, the look and feel will suit development for a while. My main focus today has been to get the comments system to work properly, and to get the edit page forms to work properly. There is quite a lot of debugging involved, but neither of these two core functionality features have really worked properly, and it's about time to fix that. I'd like to make the display pages a lot nicer as well. I'll be sure to post some screenshots once the comments and discussion systems work!

Also, I've drawn up a hopefully final framework for hooks. Hooks will be divided into two categories.

Page Hooks
The $page class will contain all functions related to page handlers, menus, blocks, notifications, error messages, and more. Anyone who is familiar with MyBB can tell you that adding a menu link to the navbar requires a manual edit to the HTML templates to add the link. Filecave will have no such requirement, as the menu system will be very easy to hook into, allowing menus to easily be edited without the need for editing any HTML templates. A similar concept will go for page blocks, notifications, etc... The final goal is to make it completely unnecessary to apply HTML template edits for the vast majority of "simple" addon modules and plugins.

Module Hooks
Module hooks are simply event-based hooks in the code. At certain points in the code, Filecave will check to see if a plugin has tried to add a hook. If so, it will execute the hooks. Module hooks work almost exactly like MyBB hooks do, although Filecave will use callbacks instead of procedural variable functions, allowing for a little more flexibility with object oriented code. Of course the major sacrifice is that arguments won't be able to be passed by reference due to a PHP limitation with call_user_func, which powers module hooks, but it's a sacrifice worth making for increased object oriented support. (No, not everything will be object oriented in Filecave, but the modules themselves will in fact be heavily object oriented if I stick to my existing plans. )

The vast majority of this has already been coded and implemented. The only thing that is really left is to organize $page hooks into one class, which won't be difficult to do. Stay tuned for additional updates!

Templates
The templates engine has not been coded yet. I'm slowly drawing up plans for a template engine, which will be exciting. Most of the templates will be templates for very small elements, and not necessarily for entire pages. (Except for the header, footer, etc...) The reason for this is that pages will be generated with a block-based algorithm that generates the header and the footer, and then adds blocks where needed. I'd like to get this system to function similarly to a drupal-like block system, although don't get too excited, the front end won't be nearly as exciting.

None of the template engine work has been completed yet. I'll post updates once more coding goes towards the template system. Once that is done, however, pretty much anything in the code will be able to be hooked into and modified with only a few small lines of code, allowing for a great deal of customization potential and for plugins to be made without core file edits.

[Darth-Apple]

I'll be honest. The whole page hooks system has been a bit more complicated than I expected it to be. I've decided to go with the concept still, but I'm not sure how everything being organized into one class is going to work haha. It might not be quite that simple. (This is my first "major" project, so I'm pretty much learning this stuff as I go. )

The good news is that the module hooks system is working and is fully functional. That is of course also a good thing because it was pretty simple to implement. As far as page hooks, here is the latest model I am going to attempt to use.

Page Hooks
Page hooks will actually be a group of different hooks allowing menu items, blocks, notifications, etc... to be added to the page. I've decided to do a template system, which will manage HTML templates and have variables in the templates for different menus, block panels, etc... So, a sample template might look like this:

Code:

{$header}
{$pagetitle}
<div class='pagebody'>
{$sidebar_left}
{$content}
</div>
{$footer}|

As you can see, many of the templates will use variables that will be replaced by the template engine. However, where are these variables defined?

MyBB, for example, requires plugins to be made to add page elements that aren't included in MyBB core. Adding menus, sidebars, etc... are often done with straightup HTML in the code because it's a pain to code all of these elements into plugins. The advantage of this is that themes are only HTML templates and CSS, making it very easy to distribute PHP-free themes. However, the disadvantage is that there is less flexibility for a truly fluid page layout. Also, designing plugins that interact with the page layout is more difficult because there are no hooks in the templates, and the actual HTML has to be modified by a plugin. Because of this, not all plugins are compatible with all themes.

Adding menu links requires template edits, for example. My goal with filecave is to prevent that from being the case. The advantage of my latest "model" at the moment is that modules that interact with the page structure will be much easier to make. Menu items, blocks, layout changes, etc... will be much easier to implement. For example, if a module adds a new menu, it will not be necessary to literally code the HTML fully for the menu. It can create a new instance of the menu class, and work with that instead. Furthermore, someone could even create a plugin for that module and further modify the menu. It leaves the door wide open for customization and flexibility.

The disadvantage is that themes that take advantage of the additional functionality and create additional page elements will require a PHP file to be distributed with the theme. Wordpress requires many themes to use PHP as well, and I believe Drupal does as well (although I'm not sure, it's been a while since I messed with drupal). It has its disadvantages, but I think it will show a lot of customization potential, especially when it comes to mutli column layouts, block panels, etc...

So, in essence, the current model will have each theme distributed with a PHP "page" class that defines instances all of the menus, sidebars, etc... The theme can then make use of these new page elements by using template variables to insert them. Because all of these basic page elements will be defined in the $page class, it will be easy to implement globally, and theme designers will be able to control almost every basic aspect of their design by creating page elements as they wish. Of course not all themes will require this to be defined. The default theme's $page class will be used if a theme does not distribute an alternative, so themes that do not require PHP code will of course be possible as well. My goal is to create all of the page elements that the majority of themes will need, such as main menus, etc..., so that only highly customized themes will require the PHP functionality. Performance is also something that I'll be watching out for carefully. My goal is not to make this too server intensive.

Of course we'll see how this works out once I get more of this coded. It's a huge project to take on, and is pretty much a roadblock to further development until I get all of this completed. Anyway, what are your thoughts so far?

[Darth-Apple]

I've now officially begun working on the template engine. I found a very simple tutorial online to show me how it's done, and overall I'd say it's worked pretty well on an independent test.

Unlike MyBB, you will actually have to explicitly set template variables in the code. This may make the code a little messier, but it is more secure as it ensures that only data that is explicitly set can be included in a template. Someone can't, for example, include the database password and reveal that through a malicious template.

For example:

Code:

hello world, [@user]! <br />
Age: [@age].<br />
Occupation: [@occupation]. </br />
Interests: [@Interests] <br />

Would reveal something like:

hello world, Darthness!
Age: Unknown
Occupation: Restaurant worker
Interests: Lots of stuff!

In the PHP, template variables are set something like this:

Code:

    $templates->set("template_hello", "user", "Darthness");
    $templates->set("template_hello", "age", "Unknown");
    $templates->set("template_hello", "occupation", "Restaurant worker");
    $templates->set("template_hello", "Interests", "Lots of stuff!");
    echo $templates->parse("template_hello");

I have yet to implement this outside of an independent testing environment, but this is what I've got so far, and we shall see how this works. (In case you're wondering, I got the idea to do it using this method from this tutorial, although I'm definitely not following it exactly. )

[Darth-Apple]

I rewrote the class, and it's literally only 26 lines of code. The new class does not require to you define a specified template when setting variables. I think it's unnecessary, personally. For instance, the variables that would be set on the user profile page would only be set when the user was viewing the profile, so it's not an issue of scope or of performance.

I'm now working on implementing the beginnings of it into Filecave. Of course I'll probably expand it out a good bit as well, but this will be a start. One of the reasons I'm going for this system over some more obvious template solutions is for security concerns. For example, in PHP, you could do something like this in a text string:

$number = 4;
echo "some number in code = $number";

It so turns out that what you will see in your browser is "some number in code = 4" when you go to the script in your browser. $number actually gets replaced with the actual value of $number. This is the concept that MyBB utilizes in its template engine, but I've purposefully avoided going that route for a very specific reason. For example, this is also possible.

echo "DB password: {$conf['dbpassword']}";

And voila, your database password has been leaked. Using PHP variables in strings that could potentially be altered by either the user or a plugin is, for that reason, dangerous. MyBB attempts to filter out unsecure code before saving a template, which seems to solve their problem. Unfortunately, I don't have time to write complex security scanners, so it's much easier just to filter out anything that looks like PHP at all, rather than just validating certain code and denying other code based on a complex set of conditions.

This system may be replaced later, depending on how it works out, but I'd like to see how it works. It definitely has the potential to be much more secure because you can only include tags that are explicitly set in code (and thus you cannot include the database password, or anything else that isn't intended for templates).

[Gmdykfuiygh66476]

Nice work