KevinM1

Eric, the problem has been that the ads have either: 1. Broken the forum layout (the first batch). or 2. Obscured content (this batch). It doesn't seem like there's any real testing going on, and each attempt has negatively impacted the user experience at a fundamental level, at least initially. This is compounded by a lack of communication from your end. This is a community - let users know that you're experimenting with ads and that their UX input is valuable in shaping the way ads will ultimately be displayed here. That way, it's not jarring to your user base, and they're not scratching their heads thinking, "What the hell happened here?" FWIW, to me, this kind of thing ties directly with our little schism/pow-wow a month or so ago. If you really mean that you want to re-engage the community and make it grow, then you need to communicate with your users in a way that's more meaningful than simply "Hi, welcome, please stay." Alerting them of a change that may impact their viewing/posting habits is a good place to start. Keep them/us in the overall loop. No surprises, unless they're obviously beneficial to all. Finally, I don't think many of us would have a problem with sidebar ads, or ads below the header/above the footer (which there currently are). The key is for them to not break the layout, or otherwise block users from viewing or creating posts.

Gah, didn't see the OP date. @neta1o, don't resurrect 4 year old threads.

Have you tried stripping it down to just: tinyMCE.init({ mode : "exact", elements : "contents", theme : "advanced" }); ? Start with that. If it works, then start adding the other theme options. This kind of approach was what I was trying (and obviously failing) to convey last night. Start with the least amount of code to get it to work, then add the extras.

Try putting your width and height within double quotes. You're passing them into the editor's generated CSS, so it's most likely anticipating a string value. See: http://wiki.moxiecode.com/index.php/TinyMCE:Configuration/width which gives its examples as strings.

= is the assignment operator. == is the equality operator. Use == for your comparison.

Can you show your HTML?

Have you tried looking at the TinyMCE documentation itself? I believe they have a wiki. Also, try implementing the editor in waves. Try the bare bones editor, followed by the various options you want, one at a time. That way you can pinpoint exactly where/when it breaks. Debugging 101 - when in doubt, read documentation straight from the source, and always try the most basic use case/functionality before getting fancy.

For me, if a page has PHP code in it, it's a .php file. Makes things far easier that way. Keep in mind that regardless of file extension you use, your current context determines which comments will work. You can't expect HTML comments to work correctly in a PHP context, nor PHP comments to work correctly in an HTML context.

Yes, please show your code. There's no way for the doctype to be the source of your problem. PHP generates HTML, but cannot be affected by it.

Hi Bob, sorry to hear about your physical limitations. I was born physically disabled myself, so I know some of what you're going through. The extra hurdles we're faced with make success taste all the sweeter. I hope you stick with PHP. It can be very rewarding.

I don't see why pointing out where somebody is wrong can't be part of the learning experience. I'd much rather receive blunt criticism of my code and design than be strung along by someone who doesn't want to hurt my feelings. In fact, I have received that kind of treatment here in the past. It made me a better programmer. Telling me my code sucks fires up my desire for competition, which spurs me to learn and improve. For me, I personally grow frustrated when I see the following things: 1. Someone wanting to be fed the answer. 2. Someone who panics because their code doesn't run correctly the first time. 3. Someone who hasn't attempted to do any troubleshooting on their own. All three tend to indicate a lack of patience or work ethic. I react far more favorably to those that have demonstrably put forth an honest effort in solving their problems. It's not 100% accurate, but it's served me well in the vast majority of cases I've encountered. Finally, RTFM is a perfectly reasonable answer in many cases. In fact, we have a smile for it: Like I said before, it should be among the first steps someone takes before coming here.* *Yes, yes, there are exceptions. I try to treat obvious newbies with kid gloves because they often don't know any better. But someone with a few hundred posts to their credit? I'm going to have the expectation that they can at least perform basic tasks, like read and follow documentation written at an 8th grade level.

Looking through the manual should be one of the first steps one should take to address a problem they have with the language. Reading through documentation is something all developers should be comfortable with. PHP's documentation is some of the best. It's clear, easy to read, and uses very little jargon. I don't think it's unreasonable for someone to be directed there as an answer. Also, while this is a place for people to get help, one shouldn't expect to be spoon fed the answers they are looking for. I found requinix's answer to be more than sufficient. He provided both functions the OP should use. Further, the manual pages do an exquisite job describing what the functions do, with relevant examples. Short of writing the OP's code for him, it was as good an answer as could be expected.

Am I missing a fundamental definition of what static means? Yes, you are: http://php.net/manual/en/language.oop5.static.php

Like Thorpe said, you're calling your methods wrong. :: is the scope resolution operator. When used in the manner you're using, it means one is trying to invoke a static method. Neither of your methods are static.

See my edit.

Don't use globals. You shouldn't use globals in procedural code. In OOP, they essentially destroy one of the basic principles of OOP itself. Argument lists exist for a reason. Pass in what you need as function/method parameters. EDIT: You really need to stop and look at what you're doing. You clearly don't understand when/why inheritance is used. What you need to do is compose objects, not simply create a whole long list of parent/children objects. Searching for a User makes sense from the context of a db, not from the context of a User itself. A User object should be returned from the search.

MVC is a design pattern. OOP is a programming methodology. The two are perfectly compatible.

Your design is all sorts of messed up. You don't need to create a child class every time you want to gain some functionality. Objects can contain other objects. Also, your User activities should be methods as they act on a User. Classes denote things. Methods denote actions on things. Further, does it make sense to have a User be a Database? Roughly, you should have something like: abstract class Database { public static function searchUser($info) { // search for the user and return the User object if it is found } } class User { private $_db; public function __construct(Database $db) { $_db = $db; } public function saveChanges() { // search the $_db to see if $this exists. If so, create a new User and save. Otherwise, update existing User } }

Protection from injection doesn't mean the db magically blocks the input from being saved. Also, do you know what HTML entities actually are? You seem to have an unrealistic idea of how this all works. Unless you put in some validation (like I mentioned before), if someone writes 'OR 1=1; DROP TABLES; it will still be inserted into the db as data. It just won't be executed as a SQL command. Similarly, look at your source code after you output some data... what do you see?

Do me a favor and stop listening to the people on the other forum. They're confusing you, and making it harder for me to set you straight. One of your problems is that you're freaking out and trying to throw a bunch of code at the wall to see what sticks. Take a step back and look at it as a series of steps. First, you nested your function calls backwards. You need to use: $comment = mysql_real_escape_string(stripslashes(trim($_POST['comment']))); Look at it one step at a time: 1. trim is called first. 2. stripslashes is called second (this removes the non-secure slashes potentially added by magic quotes) 3. the proper escape function is executed last, properly securing your data from injection. Notice that htmlentities is not in this chain of events. That's because, like I said before, it's used when outputting items that have already been stored in the db. $query = "SELECT * FROM Comments WHERE user_id = $id"); $result = mysql_query($query); while($row = mysql_fetch_assoc($result)) { echo htmlentities($row['text'], ENT_QUOTES, "UTF-8"); } For the tightest security, use the two options I gave above. Note that this won't block scary-looking data from being inserted into your db. You need to actually validate your form data to ensure that the data you expect to get is what you really get (e.g., if you're expecting a number, you shouldn't get a string).

Keep stripslashes where it is. In fact, don't touch your code, as what you have has nothing to do with htmlentities.

And you didn't ask for an explanation? htmlentities should be used if you're going to output info a user saved to your db. It ensures that any potential HTML or JavaScript they tried to insert will instead simply be displayed as HTML entities, thereby stopping the code from being rendered/executed.

You don't. Re-read my post.

You use stripslashes before using mysql_real_escape_string to combat against magic quotes. The escape function escapes the data, but the slashes don't/shouldn't remain when you retrieve those values from the db. What do you mean by 'I got htmlentitied'? EDIT: @Vitamin - never use addslashes to escape data. It's not secure. Instead, use the escape function of the type of db you're using.

To be honest, I'm not sure. I think it depends on your country's/state's laws. Online credit card security is generally a can of worms an independent developer probably shouldn't open. The liability alone would make me weary.