Modification suggestions and queries

Site Admin/Owner Joined: Aug 27, 2002 Posts: 17088

Quote:

Edited: I seen their url is not allowed here, hope I didnt do anything worng, looks just like a nuke development site to me

The only URL's that I absolutely prohibit are thosethat advertise Web Hosting. Where did you see this??

Regular Joined: Oct 17, 2005 Posts: 51

I posted the url to that site that makes this United Nuke install, and it said url not allowed here, It has a cz address. Looks like a czech site. Sorry Embarassed

Posted: Tue Oct 25, 2005 10:02 pm

That's interesting. Evidently my forum is now making decisions on its own Laughing

. Please PM me the address so I can look into this. Thanks.

Addendum: Indeed, I do block that url and it shall remain blocked Wink

Posted: Wed Oct 26, 2005 10:13 am

Quote:

PHP have session handling (objects if you prefer). mainfile.php does NOT necessarily get parsed everytime it is called as long as it is called with include_once or require_once. And, as I said earlier, the use of static variables in functions can and will speed up the redundant efforts of many functions in mainfile. I have been using them forever. In fact, it seems that the thread that first brought about those changes was started way back in my forums.

I apologize for perhaps taking the thread off track because after doing a global search for "mainfile.php" in my Nuke directory I found that it is almost always included with a require_once or an include_once. So Montego and Raven are of course right that it isn't parsed every time. It appears mostly in the index.php files of the various modules. And while this is off track, perhaps one of the experts here can provide an explanation of how this works that a simpleton can understand. Let's say that the index.php of the your_account module requires mainfile.php once. Mainfile then requires nukesentinel.php once. Is it then the case that these programs are "in memory" and available to the your_account module whenever it is accessed? I guess what I'm trying to understand is how sentinel is accessed after say, a user fills out a form in your account. I assume you would want to run the input thru the filters in sentinel before you would update the users table with the data.

Let me put it differently. Let's say you enter index.php of the your_account module for the second or third time. Is the logic in mainfile that is outside of functions automatically executed each time because it was required_once the first time? And if not, then how does sentinel get invoked to check the data?

Thanks.

Posted: Wed Oct 26, 2005 1:41 pm

fkelly wrote:

Let's say that the index.php of the your_account module requires mainfile.php once. Mainfile then requires nukesentinel.php once. Is it then the case that these programs are "in memory" and available to the your_account module whenever it is accessed?

Yes, it would be available to Your_Account.

Quote:

Let me put it differently. Let's say you enter index.php of the your_account module for the second or third time. Is the logic in mainfile that is outside of functions automatically executed each time because it was required_once the first time? And if not, then how does sentinel get invoked to check the data?

Yes, all the includes are done when you access the script. PHP is a scripted language, so everytime there is a file call, it has to parse the PHP script over and over again.

Posted: Wed Oct 26, 2005 1:43 pm

"After-Patched" (or whatever it is called) will of course be GPL.

Will people borrow code for other forks and solutions and possibly nuke itself. Of course they will. This is the nature of Open Source. Not much anyone can do about that, nor would I think there should be.

My major concern at this point is to let Nuke run it's course. By letting FB screw up Nuke, you get to the point where you decide that it is no longer desireable to run it. You being both webmasters as well as the peole that are patching and supporting nuke at this point.

The reason why I have not released after-patched is simple. I don't want to help FB, I want to wait until Chatserv, Bob, Raven, VinDSL, Telli and some of the other major players simply get sick of doing all of this work for HIM and decide that their efforts are better concentrated on a solution where they:
a) Get credit for their hard work
b) Don't have to patch the same bugs 1000 times
c) Don't have to patch brand new releases
d) It is right the first time, and there is an evolutionary process of internal work on the next revision which, when released is a final, (versus nuke which is alpha quality code).
e) Where security, compliance and it being right (as in correct) when released to the public is critical.
f) Where these people are part of a team and are working together instead of having to work as 10 seperate groups.

Now I'm not saying that this can be all things to all people, but what is important is that a development process actually LISTEN. People have different ideas and philosophies of course... We are all unique. But some things we KNOW can be done certain ways in compliance to what the programming language standards are. Sometimes, we don't get it totally right the first time (meaning, there could be a "better way".) But moving forward is critical. It is better to get it done and have it working and bug free and THEN to look at those better ways than to simply ignore the problems and hope they solve themselves.

I am a firm believer in people proving things and in the open source community, in people demonstrating by example. I can't be trusted or expected to "know" everything, nor to assume any one way is better than another. I need to see people explain and justify and demonstrate. It's really how my mind works, though I can't speak for others in that regard. I would go so far as to say that when having partners in this venture, this is the kind of thing I am looking for. For people that understand that nothing is really assumed, but rather everyone is open to hearing about everyone else's opinions and wherever possible the primary concern is for a nice, clean, well explained and justified evolution. It's not simply "I'm doing it this way because I want to", but rather, "I'm doing it this way because xyx and here is the benefit". I think when you have developer forums setup, this really helps everyone communicate with eachother and find a concensus. When you close everyone out, you end up with multiple methods and arguements. Now don't get me wrong, sometimes arguements are good, but only if they are productive and insightful, in good nature and with everyone's benefit as the goal. Cooperative comedy is what I like to think of it as. (Like the US Senate, without all of the backstabbing or politics Smile

)

This is really why I started this post in the first place. I wasn't trying to criticize the way it is done, I was ASKING if it needed to be done at all. My thoughts about this problem were not so much about the performance differences of asking the "if(file_exists" question, it was asking if this should be done AT ALL only because I THINK that the entire section of code in the mainfile can be removed completely IF you are running NukeSentinel... Again, I'm ASKING not telling.

I'm simply trying to find the most effecient and effective way to handle data manipulation (stripslashes, addslashes, htmlentities, fixquotes) as well as data and function filtering (chech_html, validation, etc...)

I'm still hoping to hear people's insights about what the best way to handle all of this is.

Steph

P.S. In closing, I wanted to mention that "After-Patched" is the ONLY 100% W3C Compliant and fully cross-browser compatible and standardized solution. There are NO others. United Nuke is not even close to compliant.

Posted: Wed Oct 26, 2005 1:56 pm

Personally I believe you should release it so that it can get into the hands of everyone. Once they can touch, taste, and feel it, as opposed to looking at white paper, it will be a much easier and more logical sell. I do nothing for FB. I do for the community. I not only service phpnuke but many other applications and systems. I support PHP, MySQL, and standard web development. I also do other areas of web support, but the point is I am here to service the Internet users who need help and I specialize in certain areas, of course. If/when you release yours I will support it whether or not I adopt it. OTOH, if I had it, was using it, and adopted it, I would then also be promoting it. And promotion by the major support sites is what will cause the paradigm shift Wink

At this point, I fear that all the chatter and no batter is starting to sound like Microsoft vapor-ware. Yours is not vapor-ware, of course. I just mean we talk and talk and brag and whatever but the public and even fellow developrs are not able to taste it.

Posted: Wed Oct 26, 2005 2:12 pm

My concern at this point is that it will all be simply rolled into PHP-Nuke and FB will be able to continue on with this screw everyone venture. I also think that it is not QUITE ready in that security filtering is no where near finalized, which I think SHOULD be the primary concern. Yeah, it is 100% W3C Compliant and totally recoded for cross-browser compatability, BUT the default nuke methodologies for handling input are flawed and I think the biggest selling feature would be to fix that one issue. If we could really lock all input filting functions down using some of the things we've talked about in the new directions threads, I believe this solution would immediately blow Nuke out of the water and would mark a major milestone in development. My personal problem is that there are people that are on the fence that on one hand say the Nuke cycle stinks, but in the same breath, they release updates and patches and say, here ya go.. use this and the entire cycle continues.

In the first regard, I am still trying to figure out the best way to handle filtering which definately needs to be done. I'm also trying to figure out a new groups system which I would hope that I could get some people that are better at this than I am to decide that they want to help and if so, how that all should be handled.

Finally, I think that this whole 8.0 scenario will really screw everyone (again, as was the case for 7.7 through 7.9) so I am hoping 8.0 will be the straw the breaks the camel's back if you will for those that have been not only supporting nuke, but those that have developed 3rd party modules and blocks that will probably not work with 8.0 anymore. You get enough people that are sick of this cycle and you create an opportunity.

So in other words, yes... politics is the main reason why I have not released it. BUT, unlike other people that simply make claims. At least (though I agree it's not much) everyone can see this solution in action and know that it proves every claim. That's the only thing that seperates it from the rest. Everyone else makes false claims (starting with FB and PHP-Nuke claiming W3C Compliance), I can at least demonstrate that this solution is indeed cross browser compatible in function and not, 20%, or 50%, or almost compliant... but rather 100% W3C Compliant.

I understand exactly what you are saying and really appreciate it, but I'm in no hurry to rush in and find all of this simply copied into every other distribution and then into Nuke. Again, I'd rather wait until I can put together a team of poeple that would agree not to distribute the code until it was ready and that would be committed to evolving it cooperatively. This way it would truly be better instead of just another release. I probably could have said all of this better, but I'm on another 22 hour day so please forgive me.

Thanks!
Steph

Posted: Wed Oct 26, 2005 2:27 pm

I understand now, I had just looked into that united nuke as an alternative to a complaint base if you was to charge for the AP. I look forward to the After Patched and I also understand why you havent released it yet. I do have to disagree about the united nuke, upon install it is complaint however not ever page, so in reality you are right but for whats out now it is the most complaint base. The pages that do display errors are like 1-5 small errors that can be fixed. but the compatibilty issues and just not knowing how its really recoded out weigh the benefits because every thing you add to the sql you have to change the prefix to unnuke. So this may just be another install someone put together and may not go anywhere, but I advise anyone to get their latest version and test it on a sub and you will see what Im talking about.

Posted: Wed Oct 26, 2005 2:34 pm

Steph, although FB has stolen code from other places over the years, has he really ever incorporated something as useful as Chatserv's endless patches (yes, pieces, but why not the whole thing???). Do you really believe he is even able to take what you have done and incorporate it? Do you really think he will steal the whole shootin' match and start over from what you have done? Pretty doubtful isn't it? He doesn't have the skills and is too proud to do that don't you think?

I encourage you to release it as Raven has mentioned too. However, I DO AGREE with you that getting the security "filtering" down right and possibly a good collaborative effort on the "groups" thing would be a tremendous benefit.

I am with Raven, too, in that I would support "After-Patched" in whatever form it is released as long as the community is not shut out of making it better and contributing along the way. I just don't have a clear picture of what you intend to do and how you intend on doing it.

Posted: Wed Oct 26, 2005 2:35 pm

j_felosi wrote:

I do have to disagree about the united nuke, upon install it is complaint however not ever page.

I'm trying not to be harsh, or to laugh.. but again, "almost" is not compliant. You either are, or you are not.

Posted: Wed Oct 26, 2005 2:39 pm

True, point taken.

Posted: Wed Oct 26, 2005 2:42 pm

Montego...

Given who is supposedly working with FB now, yes, I believe the entire soluton would be at risk of piracy.

Posted: Wed Oct 26, 2005 3:46 pm

Steph you cannot live your life in fear. Its either going to happen or its not. There really isnt anything you can do about it is there? (besides not releasing it at all)

Posted: Wed Oct 26, 2005 4:03 pm

No, but I can wait for 8.0. I can also decide to share the code with certain people that I trust to not release it publicly with the understanding that the intent is to work on it and make it better before an official public release.

Holding it back at this point is the only assurance that I have that it won't be part of 8.0. In other words, I'm not helping FB no matter what, and again, I think that once 8.0 is out, there will be no way for it to be incorporated into future Nuke releases.

Posted: Wed Oct 26, 2005 4:32 pm

True, but what is to stop it from being apart of 8.1 or 8.2? I mean it just seems like an endless cycle of possibilities. I understand your reasoning and I hope what you fear doesn't happen, but there doesnt seem to be any real safe gaurd against it.

Posted: Wed Oct 26, 2005 5:30 pm

It would be much easier to try to help with the security features if I had the code to work with. You know I would not release it. If you want others to help then I think you should make it available to that handful of people of your choosing with the understanding (prerequisite of course) that it is not for public consumption. But, I'm not here to harang you or to pressure. These are just my thoughts and that of others too. I just felt I should make them public so that it doesn't look like there is any conspiracy going on Wink

Also, on a personal, side note, it does not necessarily mean that I or others are "on the fence" just because we support the community. To me it's a cost of doing business. For example, I have money in a bank. I shop at certain stores. Both the owners of the bank and stores may be rotten scoundrels and may invest that money in ways that I am totally against. I may not agree with their life styles. But, I still utilize their services. It's not an exact application/analogy, but I hope you see my point. There are probably in the 10,000's of sites that use phpnuke or a derivative. They need supporting. And, there's really only one game in town right now. So, they d/l the latest and then immediately turn to a handful of support sites to make them safe.

The fact of the matter is, according to the lawyers for the GPL, if the code we write needs phpnuke to run, then the source must be GPL also - period. No if's, and's, or but's. Even if you take a stand alone application that is NOT GPL and you modify it for phpnuke such that it now needs phpnuke to run, then the phpnuke version is now GPL. So, the minute your After-Patched is released, it is, GPL. Why? because you have taken phpnuke and made it compliant, etc. But, it's still nuke and therefore, GPL.

Posted: Wed Oct 26, 2005 5:54 pm

64bitguy wrote:

Montego...

Given who is supposedly working with FB now, yes, I believe the entire soluton would be at risk of piracy.

It just seems a shame to not get your work out for the rest of us to benefit from. What good is it serving to hold it to your chest? Besides, if history repeats itself, it wouldn't take very long to get screwed up again if "they" get ahold of it right?

But, then again, I am not sure who this person is that is working with FB on this now. I suspect it is phoenix-cms from other posts, but I have no idea of his/her credentials, but maybe you do.

Just thought I'd provide my 2-cents worth. As you know, I've been holding off on a non-profit site proposal because I wanted to use AP for that effort. I just cannot see creating any more sites with the existing nuke we have.

Obviously your call to make.

montego

Posted: Wed Oct 26, 2005 10:40 pm

Raven... about GPL, yeah I knew that. That's why of course it would be GPL as I commented above. There simply is no choice in that regard. As GPL states, my only option if I don't want it to be freely distributed is to not release it.

Also, when I spoke about people on the fence, I wasn't talking about you... Smile

I know you're not a fence rider, you've vocalized your thoughts quite well. There are a couple of others that I also am pretty assured would not be on the fence at all if there was a better, more flexible solution at hand. I mean I'm still supporting Nuke myself by answering questions here, so in that regard, I understand completely.

Montego, the major advantage of me holding it right now is making sure that it is the best that it can possibly be. Also, I believe that 8.0 will mark such a divergence from Nuke design that it will leave a lot of webmasters knowing (not wondering at all) that Nuke is no longer a viable solution. The entire 7.x series has really contributed to this cause, but 8.0 I think will really be the last straw for a lot of people.

But I want to comment that even when I do release it to the select to be determined group, it will not be released to the masses until it is right. That is much more important to me than releasing just another fork. IMHO, this is where most of the forks have gone wrong. They have been "partial" solutions or buggy, or not as secure as they could be. It's better to take a little time and make it the best that it can be versus having to address 5000 forum posts about issues that should have been addressed up front.

I am seeking to offer what no other Nuke fork has which is completely compatibility with Nuke, without ANY of the Nuke problems and thus ensure a strong, stable and most importantly predictable future for everyone that uses it. Not this guessing game that is known as Nuke. It's better for webmaster, but it is especially better for developers that won't have to maintain 20 different versions of modules, blocks and themes.

The other major benefit is that this solution leads by example. In that the theme design code will teach theme designers how to do it right. You don't need to be a rocket scientist once you see the baseline code. The changes jump out at you.

The modules also demonstrate how to properly format queries and define input elements and much more. It's the little things that make this different, but more importantly the vast number of little changes that fix bugs and deliver total cross-browser compatibility and of course Pure W3C compliance. As time goes on, we can even improve that to deliver audio/visual aids and other W3C features, but a good baseline is critical.

Of course this will also be laid out in the documentation as well. That alone takes a lot of time and so I will of course be working on that more as time goes on. The biggest problem for me will be that solutions like Evolution and others may want to use the baseline, so a good model and update management path is critical. There won't be a "Patched" for it, changes will take the form of annotated listings and new versions. In other words, when a patch comes out, it will be a new version and will include everything. If phpBB updates, that would force a new version of AP and the intention would be to include all revisions to baseline code. It won't be a guessing game like it is now, all of that would be tested and ready to go before released to the public. The idea being to fix bugs, not to introduce new ones.

Anyway, that's all I wanted to say. I realize people are anxious, I am too. Hopefully I can scrape together the people that are capable of not only helping it leap to the next level of security and features, but also keep it in their collective pockets until we are ready for an official release.

Steph