Post-Nuke Scope, Vision, and Goals

Posted by niceguyeddie  on Friday, July 06, 2001

I realized earlier tonight that I might not have been very clear since we went live with Post-Nuke on some of the goals and vision that we are aiming for. You may have noticed that we are in Alpha Releases and not Beta, and there is a reason for that, which I will cover. This will be the living document to all of you that develop, use, hack, or even fork from. This will be kept in our sections, and will be updated from time to time. Please check take some time to read it, and realize what our goals that we hope to accomplish.

I want to explore where we have been, where we are at right now, and where we are going. I feel to get somewhere, we need to know why and how, just like if we were jumping in our car and going out for the week end. We need to know why we are going, what the goals are, and how we are going to get there, maybe by using a map.

Where we have been

This project started sometime in May. I don't know the exact date, sorry. I was frustrated with the direction that I saw PHP-Nuke headed in. I really thought that we weren't making some of the necessary changes to make Nuke a CMS system that was really universal in scope and vision. It seemed to me that the project was continuing down a spiral of self-destruction because of many factors. Some of which I have explained already in the previous posts on the subject, and I see no reason to bring back up.

What was missing in my opinion was the true vision of what could be. Now, I don't claim to be the sharpest guy in the world, nor do I claim to be the best coder. What I do have are ideas on how things can be universally better for all of us.

I made a post on my site, expressing some of my thoughts, desires, and motives. This started the ideas in a few people. About the same time, Francisco Burzi, made his infamous post about open development, and so the ball started rolling from there. From that post, I was fortunate in finding three other like minded individuals, that shared the same concerns, and the dedication needed for a project this big that is released free of charge.

We spent the next month or so planning where we wanted to go. We also worked on some things that we knew could be done in the short term, and tried to get those together while we talked about the project. We also looked at some of the things that others were working on, to get even more ideas. All of this time was spent planning. We would be no where near the point we are now if we hadn't used this time wisely.

We spent quite a bit of time defining what we thought was the core. I wrote something up at the very beginning of the project that I thought was the core, but you know what? I was way off.

Where we are at now

Some of you might recognize that are project development status is Alpha. Some of you might also ask why we are in Alpha when we are forking from a supposed stable version ( PHP-Nuke 5.0 ). We are taking this time in Alpha status to explore some avenues that we can try to reach our goals. So what does Alpha mean to someone that just wants to install this ap on their website, and let it run? Well, it means that at times, we may release something that is not meant to be released. It also means that a feature that we are looking at might not work as well as we had hoped, or it worked worse than in our dev sites.

It also means that you might be inundated with releases. We will make every attempt possible to release code that is sound, but in Alpha status, you have to keep in mind that we are testing things.

We are trying to also build a community. Everyone is welcome here. Although, the current climate might be more suitable for some one that is accustom to a development atmosphere, I think that we are also doing our best to build up the community. Without the support of everyone that reads this document, we could well loose focus of where we want to go, and in the end we would all loose out. We want to build a better website. Obviously you want to see if there is something better on the horizon, or you would never visit.

Where we are going

Well, here it is in a nutshell of where we want to get to. We want a division of Core to Plugin files ( I'll get to this in a minute ). We want a system that installs without a hitch, that allows you to choose what you want to install to make your website run better and faster. That is what is on our mind. We also want to maintain some semblance to PHP-Nuke in terms of adding abstraction layers to allow you to be able to use all of its add-ons and themes if you so desire.

What's the core?

Quite frankly, the Core is the users system. My original thoughts had the core defined with many things including the content management. However, after our planning and discussions, we concluded that not every site absolutely wants even that. So what does that mean? We are going to shift very soon to focusing on what we have defined as the core of the system, and the rest of the system will be plugin based.

Let's say you want to run a site with just news and links. What we want to do, is allow the core script manage the user portion (which includes your administration functions) and allow you to decide what is right for your website. What is envisioned is that you upload the Core files to your web directory, and then run the install script to install the rest of the plugins. So the install script will install your news files and your link management.

Let's say instead, you want to run a forum, news and reviews. Well then, you will install the Core script, and then run the install file to install the rest. Starting to become clearer to you?

Now there will be other functions that the core will provide, such as the theme for the site, the administration, etc., but as far as managing something, the script will basically manage the users to your website. We want to allow everyone to install a website that is very easy to tailor to your own needs instead of having a ton of extra features that you don't use, or don't even understand why anyone would use them.

So what will this give us? It will give us the ability to have a rock solid stable core to the script, and then focus on the added feature that may not be suited to your needs, but someone else may have. This will allow everyone to enjoy the benefits of a high-end web site application that won't cost a cent to buy. We also hope that by having an open development model, this will speed us to fixing problems, and coming up with solutions to some of the challenges we face.

I hope this shed some light on our focus and objectives. If you have any suggestions or comments, let them be heard.

The Reasons for Post-Nuke

Posted by niceguyeddie  on Sunday, July 01, 2001

You may be wondering why on Earth do we need a fork from PHP-Nuke? There are several reasons behind our insanity. The time is right for a developers version of PHP-Nuke. It wasn't a simple decision, but so far it has been very rewarding.

There were many factors in our decision for forking off. Below are some of the more rational reason, and some of the more irrational ones as well.

1) There is in our opinion a severe need for a more open developement system. This can only speed the direction of the project and help everyone in the end.

2) Ask yourself this. Do you want more features, or do you want more features that work correctly? We feel that in a collective enviroment, we can code very quickly and fix problems that, by ourselves, we might have missed.

3) Did you happen to read: http://phpnuke.org/article.php?sid=1833 This completly soured my outlook on PHP-Nuke. This attitude has become a cancer on the whole community, and frankly I don't much care for the community feel now.

4) How long have we been crying out for a CSS encased version of PHP-Nuke. Well, with Post-Nuke this was our number one priority. There are now no hard coded fonts, or hard coded colors for that matter. The themes themselves have no hard coded colors. It's as simple as changing a few variables at the top of the theme.php, and editing the style.css file, and you have a completly different site.

5) How many bugs have you fixed over various versions, only to see them crop back up in the next version? In an open-developement enviroment, that might be less likely to happen.

6) Has anyone ever sat down and thought, what exactly are core files and what are just the bells and whistles? We are defining the core files, and setting that as our priorities, not adding a haphazard new download.php just before release time.

7) HTML compliance. Yes, the index page for PHP-Nuke validates, but have you ever tried to validate some of the other files? Trust me, it ain't pretty. We have spent considerable time and effort to start to fix these errors. Are they all fixed? Nope. Will they be? Well, if this release is any indication, I would bet you on it.

These amognst other technical reasons are just the tip of the iceburg of why we are forking off.

Now it has been said that an open-developement enviroment will not work because of the egos. Guess what, we have been discussing this for over two months now, and we are still here.

Food for thought.

Copyright 2001