I want to Fork! Who's with me?

Posted: Thu Sep 15, 2005 3:46 pm

I am almost done recoding PHP-Nuke 7.8 for 100% Compliance (and strict compliance and XHTML compliance is being worked on too).

After seeing 7.9 and the proposed changed for 8.0, I'm at the end of my rope with FB.

I want to fork. To take my code and tell FB to, "Stuff It" and to make something better than he could ever dream of and to give users a good upgrade path.

I want to watch PHP-Nuke completely die due to FB's lack of coding skills and his refusals to allow others to help.

I want to watch PHP-Nuke completely die due to FB's refusals to test his own code that he publically distributes.

I want to watch PHP-Nuke completely die because I can only hope that people like Chatserv get finally sick of repatching the same old bugs 1000 times and having to maintain 20 CVS's of revisions for EACH AND EVERY VERSION OF PHP-NUKE because FB won't simply incorporate fixes from one version to the next.

I want to watch PHP-Nuke completely die because FB profits at our expense.

I want to watch PHP-Nuke completely die because FB does not innovate, but rather steals other people's work and then takes credit for everything himself.

I want to watch PHP-Nuke completely die because WITHOUT US, THE SUPPORT PROVIDERS AND BUG-FIXERS, IT WOULD ALREADY BE DEAD!

I want to mention that all of this is my personal opinion (is also in the chit-chat forum) and does not reflect the opinions of Ravenphpscripts.com

Steph

Posted: Thu Sep 15, 2005 4:03 pm

There was a time I'd have agreed with you whole heartly. But after seeing that while FB may own PHPNuke it remains much larger then the man himself. I believe that people like yourself and our own kguske who continue to provide folks with the best of the best with reworked versions actually provide the end users with something they can use and enjoy.

Platinum serves the community as an example of what could be done. NSN-Nuke, CPG-Nuke as examples of why it shouldn't be done. The time may come when FB ruins the code by failing to update key areas such as the admin side the portal. Many say that time has come already but I truely hope it hasn't.

Posted: Thu Sep 15, 2005 4:15 pm

I somewhat agree. As a member of the CPG team, I too have issues there and what strikes me most about it are the lack of compatability and the attitudes of some in the past several months. I find it extremely frustrating.

Platinum represented a good idea, but I think it went somewhat too far. I also think that the major problem was the "one person" leading the show issue, and this is where I think PHP-Nuke is going wrong.

I mean lets face it, if Chatserv just said, "I'm done patching this mess" PHP-Nuke would die on its own in probably 6 months. I mean if you can hack and deface a domain in less than 30 seconds, why would ANYONE use it?

As for ownership, I disagree. Given that I have modified every single Nuke file, it is no longer "PHP-Nuke" in the first place if I don't want to call it that. GPL is pretty clear regarding this issue. I have to give him "based on" credits, but I don't have to call it PHP-Nuke. What's more, given that it is 100% compatible with Nuke modules, I think that users would quickly abandon PHP-Nuke in favor of a solution that is essentially Nuke but without the bugs.

I think sooner or later the user community is going to come to same conclusions. Especially if they've been hacked, defaced and locked out of their own domains.

Just my two cents.
Steph

Posted: Thu Sep 15, 2005 4:49 pm

I'd have to give you all of your points there. Keeping module compatability is nearly a must and ignoring the 100's of available modules from the community was the downfall of both the projects mentioned above. Respectably CPG continues on and has a large following of its own I feel it left us all behind when it truely became a new portal in its own right.

Posted: Thu Sep 15, 2005 6:35 pm

I'll offer my services for testing and will commit to writing 100% compliant modules in the future (including re-coding what I've got). My biggest issue right now is not having a 100% compliant nuke to speed my own compliancy testing work... Smile

Like I said in other posts, I have already re-coded a new module I am working on to be 4.01 Strict compliant.

montego

Posted: Thu Sep 15, 2005 7:52 pm

My opinion? It is time to fork. 5.5 to 7.9... The pattern has been established by FB that each new version is a re-hashing of previous problems with the added bonus of new ones.

If compatibilty can be maintained with existing add-ons I think that there would be a HUGE exodus. We saw this happen when Platinum gained notoriety, but I can assure you NOT on the level that what you propose would cause. Provide a fork that is secure, stable, compliant and you will make many webmaster's and hobbyists extremely happy.

Many of you (Chatserv, Raven, Steph, sixonetonoffun, Bob, kguske and many many others) have been contributing to the "correction" of Nuke since it was in infancy, and I feel that if you all worked together on this it is, it can be a reality that most nuke users would get behind. I know I would.

Just my opinion of course.

Posted: Thu Sep 15, 2005 11:19 pm

I guess it boils down to how far you want to fork away from Nuke.

If you want to take it and completely redo much of it and call it something different then thats one thing. If you want to take a stable Nuke version and build off of it its another.

As what has been said before if you dont have the ability to use standard Nuke modules and blocks nor phpbb mods (ported) then you loose a ton of options. With out those options you will die.

So if you want to rewrite then you have to take extra care in making sure that your "customers" can have the flexibility to use things they are familure with or like in the Nuke world. Plus have the level of support they can get now.

PNP was a good example of what to do and what not to do with a standard Nuke fork. We could sit here all day and go over that, but I think 64bit and I have gone over that enough. I think the best part of it was it showed what COULD be done, though it feel short in many ways.

There are a lot of people out there with a lot of different ideas, plans and projects. Many of them I feel have good potential. Of course some dont. But maybe instead of going through the woods alone, you should take a look at whats already out there. I know you have been burned and maybe that makes it a tuff idea to swallow, but not everyone is the same.

Of course I would pipe up that the fork I have been working on is one to look at. Wink

Quake from NukeFixes has a good plan and some ideas that I think could be wonderful improvements on Nuke without breaking the compatibility. I know there are a ton of other good people out there working on things, which I am to tired at the moment to remember.

Anyways no matter what I hope something positive comes from this. Good luck to you.

Useless Joined: Aug 23, 2002 Posts: 213 Location: Chicago

I guess having forks like PostNuke, XOOPS and Xaraya does tell us that forks of PHP-Nuke can become huge if done right.

Biggest issue will be how to market the project to current PHP-Nuke users and which could be done as 64bitguy said, by make it competible with PHP-Nuke's 3rd party modules.

It's all about trying it and then see what kind of responce you can produce from a project.

Posted: Fri Sep 16, 2005 2:20 am

Well, I don't want to brag or anything, but in a nuthsell what I have accomplished is taking PHP-Nuke and made it what is should have always been.

I mean I've fixed things in here that I doubt people even realize are broken. I have a list of things as long as my arm.

My thought at this point is why call it Nuke? I mean it is kind of Nuke, but really it isn't. You have to keep in mind that after making over 20,000 changes, for all intensive purposes, I could call this thing whatever I want.

In my verion (let's call it Not-Nuke)...things are NOT like Nuke in that:

1) Not-Nuke runs without bugs.
2) Not-Nuke is secure.
3) Not-Nuke is 100% Cross-Broswer Compatible.
4) Not-Nuke is 100% W3C HTML 4.01 Transitional AND CSS Compliant (All User AND Administrator Screens!)
5) Not-Nuke heavily exploits CSS (Even 90% of the Theme Images are CSS Based)...
6) Not-Nuke runs all PHP-Nuke 7.5+ Blocks and Modules (actually, all 6.5+ blocks and modules that have adapted to Patched 3.1 and the 7.5+ Administration Mods)...
7) Not-Nuke has 100% bug-fixed, cross-browser enabled and W3C CSS and HTML 4.01 Transitional Compliant Forums! Something phpBB hasn't achieved themselves yet!
8) Not-Nuke has optimized the TinyMCE editor reducing 120k from every page load...
9) Not-Nuke has cached-blocks enabled *(and cached modules coming)
10) Not-Nuke is not only 100% W3C HTML 4.01 Transitional Compliant, but VERY VERY CLOSE to HTML 4.01 Strict Compliant.... (A gigantic leap forward!)
11) Not-Nuke has fixed too many errors in too many modules to document here. Not-Nuke would never be released without thorough bug and security testing.
12) Not-Nuke loads extremely fast with considerable overhead reduced without affecting, restricting or eliminating ANY baseline Nuke features.
13) Not-Nuke starts with Patched 3.1 and NukeSentinel 2.4.1 as the baseline for security before any other revisions were done.
14) Not-Nuke is a solid foundation for adding not only additional blocks and modules, but also forum mods as it is already compliant!
15) Not-Nuke supports all existing Nuke themes, but would also help users find bugs in their existing themes as the baseline code is completely compliant. It makes theme compliance errors stick out and thus much easier to repair!
16) Not-Nuke's code provides by example a demonstration of how Nuke themes should have been designed all along.
17) Not-Nuke's author would integrate fixes as they were discovered instead of shutting out the World.
18) Not-Nuke will be supported.

So... The question becomes:
"To Nuke or to Not-Nuke?"

Sells PC To Pay For Divorce Joined: Posts: 5661

New Member Joined: Sep 02, 2005 Posts: 8

im new to nuke but id does seem very stupid to me that php-nuke has 10 different versions and every1 advises you to not use new versions!
also if you changed significantly from nuke would it be possible to design a program that can analysis old blocks and convert them to not-nuke ?
9) Not-Nuke has cached-blocks enabled *(and cached modules coming)
this seams like a very good idea,(as i said im new to phpnuke, is this posible with nuke atm?)
13) Not-Nuke starts with Patched 3.1 and NukeSentinel 2.4.1 as the baseline for security before any other revisions were done. (could sentinel be switched off(as cheap servers tend to suffer under the sentinal load (well mine did))
1 Cool

Not-Nuke will be supported.
would this mean i could see forums and support on the same site as i can d/l the 'official' version of not-nuke Very Happy

that would be a good idea!would i have to pay for support Sad

? or would i have the option to Very Happy

?

would not-nuke have its own unique (more secure)blocks and or modules if so would u have an almost comprehensive catalog on ure support page because i apreciate that all these site have a few d/l however its quite hard to compair different blocks on different sites ect...?

i think raven was going to fork but decided not 2 in the end (well there are forums)

Posted: Fri Sep 16, 2005 6:37 am

As a heads-up, NukeSentinel would not impact performance whatsoever UNLESS you were employing a very large number of IP2Country functions.

The now gone solution know as "Protector", now that is another story altogether.

I think you can see by looking at the test domain that Not-Nuke (lol) is very fast. Average page generation time of the 7.8.3.1.1 Version is 0.07 seconds and that is with using a "full' theme. Using a partial theme (any theme included with regular PHP-Nuke) it is even faster... around 0.03 seconds. (If you register, you can switch the theme to DeepBlue and see for yourself). To answer you question, you could disable NukeSentinel, but we would not support any such situation as this would be leaving you wide open to hackers.

To answer your other question, yes, Caching is a capability that exists in Nuke; however, due to the thousands of coding errors in Nuke, it is by no means as affective as it could be. To make matters worse, it is not incorporated into the Nuke structure by default, you must modify your files.

As for support, yes... forums would exist in the same place of where you would d/l the solution.

As for blocks and modules, all included baseline blocks and modules have been recoded using the latest security models. The intent is that these lay the foundation and provide documented examples for Module designers to follow. While 100% compatibility exists for older methodologies, I would encourage users to only use these latest methodologies as defined by the "Patched" series of updates produced by Nuke Resources. These methodologies are widely recognized as the best and most secure.

As for the rest, I just don't know yet.
Steph

Posted: Fri Sep 16, 2005 8:06 am

You have some great things in your 18 points. Where can we download it. Smile

Site Admin Joined: Jun 04, 2004 Posts: 6432

This thread will inevitably be linked to the earlier "To fork or not to fork" thread, and seems to be driven by the same, or at least similar, issues. Since the previously thread, I've been working on a fork with several goals - many of which were based on the previous discussion and Steph's earlier points. My thought at the time was to start with a distribution and evolve into a fork - or possibly a new system altogether. But the evolution would be driven by what the community needed.

Here are the goals towards which I've been focusing (pasted from a document I last updated 5/24):

Possibilities / Evolution Path:

Obviously, Steph's ideas are definitely incorporated in these goals. Many of the things he is doing or has done are things I'd consider at some point down the road. The risk, I think, is conflicting goals - or conflicting priorities.

So far, I've:

I think the most important goal, at least for now, is Nuke-compatibility. What would happen if (anybody else remember the song "Daddy, what if.."?) we suddenly stopped supporting Nuke and introduced a non-compatible alternative? Sure, Nuke would suffer - maybe even die. But, we would likely also lose the opportunity to convert the Nuke community to the new system. CPG started off with great ideas for improving performance and security, but lost many by becoming incompatible. NukePlatinum had great ideas for enhancing functionality and usability, but overdid it with excessive gaming functions not applicable to many Nuke sites and incompatible themes. I'm sure you could make similar comparisons with Post-Nuke, Xoops, and any other Nuke derivative.

Next, because I support several business and community sites that use Nuke, I have no interest in gaming features. Aside from the glaring holes in security, PHP-Nuke has also missed my boat, so to speak, by focusing on adding gaming features. Platinum (and it's derivative Imagination Nuke) took this to the extreme. Other distributions have potential, but miss in certain areas (i.e. they have different goals and priorities).

I'm not taking security for granted. Thanks to Raven, Bob and Chatserv, security is much less an issue today than it was a year ago (assuming sites are patched and use NukeSentinel). As Steph has done with W3C compliance, we should work with various module makers to improve security - or simply include / make available secured versions.

Support is obviously critical - and it's been a major factor in delaying the distribution of the work I've done. I definitely favor working with a team, and I'm obviously very pleased with team here.

If you've ever seen PHP-Auction (at least the paid version), you'll know what I mean by automated updates. It basically provides a PHP interface for updating components of the software by selecting the new components and clicking update. There are several possible ways to implement this, but I'm looking for a way to have it intelligently determine what you need to update - and what you've customized - so you don't accidentally wipe out an important change. To me, and I think to many of the visitors here, having this capability would eliminate LOTS of support needs as there are way too many problems caused by mistakes applying patches, fixes, and updates.

The question for me is: Can we agree on goals and priorities? If so, I am excited to participate in this effort.

Posted: Fri Sep 16, 2005 10:30 am

Yeah, I'm pretty close to you on all of this.

Compatability with Nuke modules in my mind is critical. Also, I agree completely about Dragonfly.

We are also on exactly the same page regarding Platinum.

I should mention though that I've not only fixed compliance issues, but literally thousands of bugs. In doing that, I've enhanced everthing as well.

Just as a brief example.
If you use PHP-Nuke 7.7, 7.8 or 7.9, the Feedback module won't email you readable text.

It required a complete recoding to support the WYSIWYG editor being used to input data. Otherwise you were getting plain text formatted emails with HTML code in them.... The bottom line was you couldn't interpret anything any user sent via feedback, especially if they used a quote, or pasted code, or anything else. Pretty d*** useless. I recoded that module to actually send HTML emails. No, it was not a 5 second fix, in fact considerable time went into just fixing this one stupid issue. While I was at it, I thought it a good idea to add the IP address of the sender as well, so in other words, the module was enhanced. And yeah, I fixed the 20+ compliance bugs while I was there.

Every single module had issues.

Re-porting BBtoNuke was also a huge undertaking. I think the one person that can really appreciate what I mean is Chatserv since he did the first one. I can't tell you what a pain in the tail just fixing the Jumpbox issue was, nevermind the popup windows, the smilies code and the BBCode for cross-browser compliance.

Again, it wasn't a 5 minute fix for any of those problems. The Headers (both of them) alone took days, not hours... but again, the big issue was total compatability and having a bug-free, secure, compliant and cross-browser baseline.

But do I really want to put this stuff out so FB can steal it only to screw it up again later? I think not.

I see no advantage in helping him, especially (as Raven best put it), my "Blood Boils" every time he releases a new revision. I just want to strangle him if for no other reason than he does not maintain this junk and he puts out very dangerous code that hurts the entire community KNOWING.. YES KNOWING that Chatserv and others will fix it for him and he can simply sit back and collect the money for everyone else's hard work.

I mean any idiot could find these serious bugs in less than an hour, yet MONTHS have passed and he hasn't addressed any of them.... On top of that, he keeps introducing old bugs and coming up with new ones? I mean don't get me started.....sheessh.

Things that need work (because again, this is just baseline:
1) Optimization of SQL Queries. Let's face it, this needs some serious attention. Nuke has just gotten worse and worse because who really wants to fix this when the code was so buggy. Well, I've addressed the first part, but I would definately need help in consolidating queries so that any given homepage would use half of what they use now. I mean we can definately fix the problems. Just tackle them one block and module at a time. Things like that stupid gaming block with 300 queries should be identified for what they are. Junk.

2) Groups Integration. There's a new thread going, but the jist of it is, all three groups systems integrated into one. Points/NSN Groups/BBGroups.

3) A "Submit" data hash template (non-mainfile). The existing method is just plain stupid. You do NOT need to examine output for forbidden tags, only input. In other words, whenever there is any query or input function, that data is parsed through a stripping, analysis and filtering process, and THEN submitted. URL control can be handled by Mainfile security (IE NukeSentinel).

4) Compliant theme methodologies. Already have it started, working on HTML 4.01 Strict and XHTML 1 now. CSS is coming along very nicely. Will provide a fully functional demo theme to show designers how to do it right. Would love to see this evolve into theme "Class"es. In our case, it is NOT like Dragonfly where theme designing is equivalant to having to be a Rocket Scientist. In this regard, Effectica (of effectica.com) has been a real fantastic help to me in working on and designing my theme. He's really getting this stuff down pad now and doing/learning more about optimization as things go on. Again, having a compliant baseline really helps in this regard.

5) New Universal module, to help Nuke developers design compliant modules. This would help expediting moving from Tables to CSS in design.

6) New YA Module. CNBYA 5.0 I need not say more. It has the new security hash functions, ability for multiple new custom fields, membership approval controls, groups integration, single userinfo solution (replaces forums "profile") multiple types of emailers, OSC Nuke Integration, too many new features to list here... Oh yeah, and I've already recoded it for 100% W3C compliance too!

7) Module enhancements. Let's face it, the downloads and Links modules need work. The upside is, they are now 100% bug free and compliant. We simply need to enhance them to do the thing that they should and not do the things that they shouldn't. (Like why you need a details screen as the default location with ratings, etc.. for links is beyond me. It needs to be cleaner and let you click a small option icon for more info instead of the other way around.

8) RSS/XML Input/Output controls. Syndicated News is coming along. I could always use some help to optimize it, but it has seriously evolved. It has a fully integrated Magpie RSS/XML solution and automated cache controls. It reads any RSS/XML/Atom compliant feed in any language and is already UTF-8 (and I can even present that in an ISO-8859-1 wrapper!) I also have compliant output templates for 0.91, 2.0 and Atom! I'm working on Itunes templates now. Screw that junk that FB stole that queries the remote server everytime someone loads a page. It needlessly sucks bandwidth, is non-compliant and it is anything but efficient. It's 4 years old after-all.

Anyway... I want to fork. I'm ready to fork and I've got just the code to start with. I've already achieved all of his 7.9 as well as 8.0 goals! And my work won't screw every nuke user out there. On the contrary, it does just the opposite.

I think that if Raven, Bob and Chatserv as well as a few others Stopped supporting Nuke and stopped providing bug fixes, in favor of supporting a stable and maintained version that is completely Nuke compatible with a consistant baseline and upgrade path, Nuke would die as it deserves to die and everyone would migrate to that new platform and be much happier.

The phrase I want to use here, I can't.... but I think you'll figure it out.

&%*$ FB and the tricycle he rode in on! I'm simply sick of this junk he calls software and him profiting at everyone's expense without a care in the World.

Just my two-cents. Oh, and one more thing. UTF-8 is coming too, you'll notice I talked about that in the, "To Fork or Not To Fork" along with all of these other things that I finally ended up doing on my own. Automated Updates is broken down into two sections. Automated notification and updating (separate). If you have no custom mods, you can use the files. If you have mods, you use the annotated listings.

Steph

Posted: Fri Sep 16, 2005 12:11 pm

I was looking at adding Magpie, too...it sounds like our work compliments nicely, though it seems you have done much more than I. Using tools like Magpie, PHP-Mailer, overLIB, kses, nuSoap, PEAR, jscalendar...the list goes on and on - rather than trying to develop everything custom (remember the "dream" of PHP-Nuke having it's own forums module?), enables us to take advantage of the best tools, techniques, etc., very quickly.

I used this same approach on modules: if I have to fix something, let me at least start with something that works (i.e. I replaced the Feedback module, the newsletter function, etc., etc., etc.). CNBYA is a great example of that, but there are many more. For WYSIWYG, although I started with FCKeditor, the idea is to be able to choose whichever editor you prefer - or at least to minimize the damage if you decide to switch to something else down the road.

I agree that we're very close on goals - but it's not surprising since your earlier comments heavily influenced my goals.

How do you envision distributing the code? I couldn't care less about FB or anyone else taking it - without support it means nothing. If people are dumb enough to pay him for something he borrowed, when they could get something better for free, well there's a lot to be said for the old saying about a fool and his money... But I also appreciate what you've experienced in terms of others using your hard work. Credit should be given where it's due - I use a Credits module for this, in addition to leaving all copyrights, etc., where they are.

I'm also ready to fork. How would you like to proceed?

Posted: Sat Sep 17, 2005 2:30 am

How about a newsletter regarding this project for those who are and might be interested in near future.

Posted: Sat Sep 17, 2005 8:42 am

Growing up in the early 1970's, we always enjoyed cartoons on Saturday morning - they helped us laugh when there wasn't much else to laugh about. We saw adults treat soldiers like criminals and our president cry. Nothing seemed to get better. Since some are feeling similar frustrations with PHP-Nuke, I thought I would try to bring some humor back to Saturday morning...

With apologies to Bobby Dare and Shel Silverstein, this is the PHP-Nuke version of the hit 70's song (appropriate as that's when the last innovation occurred...),

Nuke-Daddy, What If:

Nuke-Daddy, what if NSN stopped securing?
What would happen then?

If NSN stopped securing you'd be so surprised.
Script kiddies'd deface your website with wide open eyes

And Raven would respond with support, it's no lie
And your website would be secure again

But Nuke-Daddy, what if Raven stopped supporting?
What would happen then?

If Raven stopped supporting then the web would be dry
And your site wouldn't load, your visitors would fly

And Chatserv would patch it, as fast as the wind,
And your site would start loading again

But Nuke-Daddy, what if Chatserv stopped patching?
What would happen then?

Well, if Chatserv stopped patching you'd wonder why
And come back to me and ask me to try

In the next release, I would promise the sky
Yes, the cash would start flowing again.

But Nuke-Daddy, what if I stopped paying you?
What would happen then?

If you stopped paying me, the releases would stop flowing
Your site would be secure, and the bug list would stop growing

So you see, if you wanna keep this whole mess a-going
You'd better keep paying me again, again
You better keep paying me again
You hear me, Steph?

You better keep paying me again
You love the bugs, Steph? (no)
Please come click my ads again

Posted: Sat Sep 17, 2005 12:13 pm

ROFLMAO!!!!!!
In your face Nuke-Daddy!!!

Posted: Sat Sep 17, 2005 12:48 pm

cpgnuke did start as a derivative work from phpnuke but somehow we didn't like the nuke interface so we went ahead and changed the core to our likings.
We renamed it Dragonfly CMS to avoid any connection with php-nuke and mainly because the systems are NOT the same although they both were based on thatware.

So please don't put Dragonfly and PHP-Nuke on the same line because they are way to different.

As of cpg-nuke shure you may compare those since the interface is almost the same (last version was 8.2c a year ago) but it died a slow death.

We are still the "CPG-Nuke Development Team" but that's just as of respect and history reminder.

The idea of forking php-nuke is there for many years and a lot of people have tried or still doing it, however look at what they evolved to and/or how productional they still are. So as advice you should gather a team and setup strict rules and a roadmap on what to do with this fork. Without those rules and roadmap you either die or evolve in something totally different like what happend with PostNuke and Dragonfly.

Also keep in mind that PHP 5 and MySQL 5 are slowly taking more ground and that PHP 4 & MySQL 3 (ISO SQL99) will be ancient history within 5 years. So do keep in mind what you are and what you should become.

To avoid all these issues i've started something new and fresh in pure PHP 5 with ISO SQL2003, WAI-AAA, WML, XHTML 2, CSS 3, Section 508, ISO 17799, UML, XMI and UTF-8 (UCS4 & UTF-16 ready)
Expect a beta in 2006 and a first stable release end 2006 or 2007.

As you see there's a lot to change in the future thanks to W3C, Linux and Gecko but somehow M$ Vista is still stuck in the year 1999 but maybe that will change.

I hope you do understand what you want to do and what the result of it would be within 5 years, if you do i wish you all good luck!

Posted: Sat Sep 17, 2005 2:38 pm

Thanks, djmaze. I think very highly of what you've done with CPG and also of your early and ongoing improvements to PHP-Nuke, especially in the area of performance. In fact, you will be listed in the credits for the many performance tweaks you contributed that still apply to Nuke.

I agree that it could end up being something very different down the road - but that could happen even if there are strict rules and a roadmap. Maintaining compatibility with Nuke addons and themes, but improving everything else - i.e. the Nuke core - will be important in the beginning. But, after that, if there is sufficient demand, it could evolve in a number of directions. For now, I think we are on the same page.

I also agree with your recommendation to take advantage of improvements in the underlying technologies. PHP 5 has built-in support for Tidy, for example, which could be used to reinforce W3C compliance. MySQL should one day have support for triggers, which could be used to eliminate many of the security issues, improve performance, and minimize code. But depending on MySQL limits the ability of Nuke to work with multiple database systems... So many things to consider!

At any rate, I'm glad to hear of your plans. Good luck and thanks for the advice.