hmm recimo problemi sa modulima nakon upgrade-a problemi sa html blokovima ( banerima )
ukratko procitaj ovo :
inace prvo sto dobijes na googlu za to pitanje a imas jos milion mesta na kojima se prica i obrazlaze zasto ne !!!
sad tekst ! :
Originally published at http://64bit.us/article83.html
By: Steph Benoit, Webmaster
Okay, so maybe you haven't read any of my articles or forum posts (or those by others) at Nuke support sites including http://ravenphpscripts.com
[ravenphpscripts.com] and elsewhere regarding why nobody should use PHP-Nuke 7.7 or 7.8. Or maybe you simply just "don't get it".
Well, you aren't alone because even with all of this information out there, people continue to install these two versions and continue to be plagued by problems.
To help everyone out, I'm going to simply break things down as much as possible to explain several reasons why you (and everyone else) should avoid these two latest Nuke versions.
First and by far the most serious reason to avoid both Nuke 7.7 and 7.8 is that they pose tremendous security risks to your site and to anyone that may use your site.
The implementation of the, "TinyMCE" WYSIWYG editor (or, "What You See Is What You Get") creates these security threats.
In a nutshell, the problems are that the editor has three major obstacles, being:
1. Data submitted via the editor is not validated for W3C HTML presentation or formatting compliance. While this doesn't sound like a big deal, it is. The result is that any non-compliant data submitted will (that's WILL, not MAY!) affect the rest of your website.
2. The data submitted via the editor is not security screened (which some might call being part of a validation AND/OR another separate security filtering/validation process).
3. The convenience gained, pales in comparison to the limitations and restrictions of the TinyMCE Editor compared to the previous Nuke methods (without the editor). I will provide a few examples of what I mean later in this article.Let me start by being specific about the first problem of non-validation to presentation standards.
Let's suppose someone submitted a non-W3C-compliant news article (which happens almost, (if not) every time with Nuke 7.7 and 7.8, regardless of how 'good' or 'careful' you are to avoid it).
The first problem in this scenario is that not only will the article itself make your homepage non-compliant to W3C presentation standards [w3.org] (if you; like most webmasters, have the News module as your "home" module) but the problem will "ripple" throughout your website, and even potentially onto other websites making them non-compliant as well.
This happens because non-compliance in articles automatically translates as non-compliance everywhere else via your backend.php file (which provides the ability for you to syndicate or otherwise propagate articles and other information like forum posts, through an RSS output function).
While all of that is going on, the presentation compliance problem will make your "article.php" also non-compliant (in addition to whatever is displayed on your homepage) while finally ALSO making your AvantGo page non-compliant.
One non-compliant character, link or function would essentially remove your site's ability to present information in a cross-browser and W3C compliant manner, as well as remove your ability to syndicate that news (or even other, compliant news) or ANY OTHER DATA that is fed outside your domain to others reading it via either an RSS Reader, or via an RSS block or RSS/XML Module, on any website reading that data (by way of your backend.php file or any other RSS output files that you may host).
Even my own custom, "PHP-Nuke Syndicated News [64bit.us]" Module would identify your feed as being "non-compliant" and would thus reject it from being parsed. (Note: You can check your "backend.php" RSS output compliance by clicking the "Valid RSS" Icon at the bottom of this screen and then give it the URL to your backend.php file!). PHP-Nuke Syndicated News would also spit out errors to any webmaster trying to read data from a Nuke 7.7 or 7.8 domain and simply would not parse the data.
So essentially you are not only screwing up your own web site, you are eliminating everyone else's ability to display any of your site content on their sites or via any "compliance required" RSS newsreader, parser or aggregation software.
Okay, so you say, "So what?" or "Who cares!"
Well, let's move on to the second problem which is also a direct result of not validating or otherwise examining data, but in a more serious regard; specifically, filtering data that could pose a security threat.
In that scenario, let's also suppose that the malicious function was designed simply to steal your user's cookies and then to redirect people to an off-site server to perform some other unknown, yet nasty and malicious functions.
Now keep in mind, in any version of PHP-Nuke PRIOR TO Nuke 7.7, your mainfile.php would protect you from this type of thing and tell the jerk submitting this malicious function, "The html tags you attempted to use are not allowed", thus promptly stopping the hacker in his (or her) respective tracks.
With the TinyMCE editor however, a hacker could submit this function quite easily by using:
Now, what happens in this scenario is that your mainfile.php, which would normally protect you from such a function, can't. Why? Because the mainfile.php is not designed to filter ANY of the TinyMCE WYSIWYG Editor content.
Additionally, there are no other places within either PHP-Nuke OR the editor itself OR even via a third party script where the submitted information is analyzed, validated OR security filtered.
To make matters even worse, neither NukeSentinel™ [nukescripts.net] NOR Protector [warcenter.se] nor any other Nuke security solution can protect you from this or other WYSIWYG created problems either. You are quite simply, "Up The Hacker Creek, Without A Security Paddle."
Keep in mind that this particular editor was designed to be SMALL, with the least amount of performance overhead. Hence the name, "TinyMCE", with "Tiny" being the keyword.
The above is JUST ONE example of SERIOUS security holes that could lead to not only your site being completely compromised, but your users and their data being exposed and compromised as well! Also remember that this would be your fault! Thus essentially, you could be for all intensive purposes a hacker website that is hurting people, without even knowing it!
You should know that there are literally DOZENS of other holes created by the use of the TinyMCE WYSIWYG Editor, and they can't be stopped by either Nuke or any add-on security solutions. I won't publish any other of the weaknesses for obvious reasons, but I want to emphasize AGAIN that the above is just one example!
Next, I wanted to mention that some people also incorrectly think that they can simply change the editor or disable it. You should be aware that not only is the editor used in all of the base Nuke code, but in every base module as well! In addition, the base code and module code has been altered specifically to support and to accommodate the editor. Disabling it really isn't an option because of these facts, despite what others might argue to the contrary! Remember, if you simply remove it, you are now using inadequate baseline code because there are MANY things that had to be changed to accommodate the editor!
For example, in the Submit_News module, (as well as EVERY other module) you'll find code in all previous versions of Nuke, that is now missing from 7.7 and 7.8. Again, this is because of the TinyMCE Editor.
Here is what one portion of code looks like in 7.7 - 7.8:
Now here is that same section of code for Nuke 7.6:
Do you see what is missing?
And more importantly, this is also missing from 7.7 and 7.8:
Yes, there are additional things that are missing (and different) but again, this is all because of the WYSIWYG editor! This simply demonstrates a few key points to convince everyone that you CANNOT simply disable the editor without serious consequences if you don't recode every module and most of your 7.7 and 7.8 blocks!
What's more, using a different WYSIWYG editor won't necessarily solve these major problems either, UNLESS that editor validates data to 100% W3C compliance AS WELL AS screens all submitted data for forbidden tags by passing all data through the mainfile.php AS WELL AS screening and filtering data via whatever validation and security filters are used by that editor itself or via an external filtering script.
On top of all of those issues, the mainfile.php would itself need to be reconfigured and recoded to support such functions and processes.
Adding the final insult to your injury comes another major problem in that the editor features themselves (that you might want to use) have substantial issues and problems too.
I could give hundreds of examples, but I'll keep it simply to common problems that can't be overcome, from features that people use every day.
Let's say that you format a news article to include a link to whatever site, (and/or a link to whatever function that you are talking about) some pictures that you want to wrap around your text, and of course the text of the article itself.
Normally, you would add functions like "Title" tags for links and "Alt" as well as "Title" tags for images so people have "mouse-over" abilities to see something about either the picture or link. Like "Visit Joe's Website" or "This Is A Picture Of My Water Cooler".
With the TinyMCE editor, you can forget about all of that. Those features simply don't exist. This means that not only can you NOT use these common functions, but you are immediately becoming non-W3C-compliant by the fact that the editor is NOT capable of using them! Yes, "title" tags are required for links and "alt" tags are required for images for compliance, never mind the many other things that the editor doesn't do, that it should.
Additionally, where you could normally move pictures around and be creative in your formatting (like how I have formatted the pictures in this 100% W3C Compliant Article to wrap around on different sides of the text); once again, you have lost those capabilities. You have also lost the ability to display thumb-nailed pictures that are "linkable" to larger pictures and other multi-function features of using regular HTML formatting rules and expressions that exist in all Nuke Versions through 7.6!
Finally, you should be aware that as the Konqueror, Safari, Opera and many other browsers haven't fully implemented the "Midas [mozilla.org]" specification, anyone using these browsers is going to have substantial problems using your website (even if you use any other WYSIWYG editor as well). So now, it is as if you are saying to your users, 'Only "certain" browsers can access this web site'.
Okay, so you don't care about security, W3C presentation compliance, cross-browser functionality or formatting capabilities that are now gone and you actually live to have your domain broken into and taken down by hackers and script kiddies every day! In that ridiculous event, the last reason why you should avoid PHP-Nuke 7.7 or 7.8 at all costs is that literally hundreds of bugs that have been fixed (countless times in previous versions of nuke) have been re-introduced into these two latest versions. Even bugs that were fixed via previous "Patched" updates as far back as for PHP-Nuke Version 7.0 (as an example) and then finally gone from the base code by Version 7.5, are now again back in versions 7.7 and 7.8!
Many of these bugs have yet to be identified and fixed by the "Patched" series of updates (produced by "Chatserv" of http://www.nukeresources.com
[nukeresources.com]), so again you should know that from the time that you load either of these two versions of PHP-Nuke, you will have tons of bugs and problems! Even if you immediately load and install the latest "Patched" update! Yes, "Patched" will fix many baseline Nuke problems, but those updates cannot begin to address any of the other serious problems, unidentified baseline bugs OR ANY OF THE WYSIWYG editor problems!
If these are not good enough reasons to avoid these two latest versions, then coupled with the new WYSIWYG editor problems you should know that using either PHP-Nuke 7.7 or 7.8 is simply a bad idea. Neither version offers you or your users anything better, in fact only just the contrary. Both versions deliver nothing but headaches and heartaches for users and webmasters alike; by reducing everyone's abilities to be more dynamic in presentation, to be compliant to Internet presentation standards and to be secure.
I want to close by advising everyone NOT to ask me support (or any other questions) regarding either Nuke Versions 7.7 or 7.8. To put it simply, I refuse to waste my time on a ridiculously hopeless cause. There are far too many serious issues within these two versions of Nuke for me to address here or anywhere else for that matter, and frankly I have my hands full dealing with more important issues where advancements may be realized.
If you were foolish and said, "Damn the torpedoes" or just uninformed and have installed either version and are now wondering, "What the heck should I do now?", there (for the first time in Nuke history) is the unusual ability to actually downgrade to Version 7.6.
This excellent solution comes to everyone courtesy of Bob Marion, Owner and Webmaster of the NukeScripts Network and can be found at: NukeScripts Network PHP-Nuke 7.7 and 7.8 Downgrader [nukescripts.net]
I strongly urge everyone using PHP-Nuke 7.7 or 7.8 to deploy this solution before you are hacked and lose everything or compromise your user data; as yes, these are two versions of PHP-Nuke that could blow up in your face!
To everyone else that decides not to downgrade, I can only say, "Good Luck!" You'll need it!