scootstah

Yeah, that aggravates me to no end.

Sorry, but "it's not working" is not going to get you any answers. WHAT isn't working? Is the email not sending at all? Is the email sending but with incorrect/unexpected data? Is there a PHP error? We aren't looking at your monitor, we don't know what "isn't working" means. Also, remove the @ symbol from the mail function to see if it is producing errors.

What happens after that code? You are setting variables and then immediately setting them to null right after.

One way would be using AJAX to add the checked boxes to a SESSION, or temporary cookie.

Here is an excellent article for that: http://phpsec.org/projects/guide/4.html

Interesting...

Just throwing this out there, but there are services that exist whose sole purpose is to ensure mail delivery. Now obviously you can never guarantee 100% that mail will be delivered, but if you have properly configured servers you can be assured the problem is at least not on your end. If you're sending a very large amount of bulk emails I would recommend you take a look at them. You may run into some problems with bulk emails, it may raise some red flags and make you look like a spammer.

The $_POST variable is only populated after you send a POST request (like submit a form). So, you first need to determine if a POST request was even sent before you need worry about anything to do with the $_POST variable. If you try to use the $_POST variable without a POST request, you will just get index undefined errors as you did here. So either Drummin suggested or, an easier way that I like (since it doesn't require any specific fields) is this: if (!empty($_POST)) { // do whatever here }

Do you really not see a problem here?

How are you displaying the rest of the months? What does the data look like?

I don't really understand your question. What's the point of making a class if you're not going to use it? And I'm with thorpe, I think you are violating some OOP principles here.

I don't know if this helps or not but you misspelled "filter" twice. The function should be filter_var('[email protected]', FILTER_VALIDATE_EMAIL);

First of all, when you post code please use code tags. And for the love of god, format the code so it is actually legible. And secondly, whether or not it works is up to you to find out. We don't know or have access to your server environment; how are we going to know if it works or not?

The statistics would vary a lot based on the target demographic. For example, a tech-related site with mostly tech-savvy users probably won't yield too many ad clicks. Most likely the users will be using AdBlock, or they just learn to ignore ads completely while skimming the page. Depending where the ads come from you usually get paid just for page views, even though it is significantly less than actual clicks. What it really comes down to is having a shit ton of traffic. if .1% of 10 million visitors a month click an add, that's still 10,000 clicks - plus the page views on top of that.

Is "file_type.php" in the same directory as the script running this code?

I feel that checking the referer is pointless because it can be spoofed. Plus, as you said, it might not even bet set.

Why do you need to put that information in sessions? Where did the user input come from? It looks like this is in a class, which throws a red flag to me. It sounds like the class is trying to do too many things.

Yes. Also note that off-site solutions can really only guess what needs to be in the sitemap, and you (probably) have little control over it. It would be better to have a script that can actually interact with your database and such.

I validate CSRF for every POST request. If done properly it takes absolutely zero extra time to implement. There's no excuses for not implementing CSRF.

XML is just a markup language, like HTML. There isn't a whole lot to know, it is just data formatted in a specific way. Unless you have a completely static site I would use some sort of sitemap creator, be it your own creation or a third party script - just so that everything is automated and you never forget to update it. PHP works nicely with XML so it should be a fairly easy thing to do.

http://wiki.phpmyadmin.net/pma/Configuration_storage Did you read this?

The way that I imagine you are doing this is sort of wonky. I think you will end up with two identical items in your dropdown. Don't bother with changing the default option ("Select Player") to the selected option, just change the selected option to actually be selected. The reason I say that is because you have an $option_str variable, which I assume to be a bunch of other options. Unless you are removing the selected one behind-the-scenes, you will end up with two identical ones. With that aside, you didn't read my code properly. I am adding the selected attribute to make that option the default selected option. Instead of doing that logic at the top you should instead do it on each option so that you don't have any duplicates. It would help you out a lot to put your options into an array, then you can loop over them so you only need the logic once. Here's an example: $options = array( 'john' => 'John', 'dan' => 'Dan', 'michelle' => 'Michelle', 'robert' => 'Robert', 'jennifer' => 'Jennifer' ); echo '<select name="first_name">'; echo '<option value="">Select Name</option>'; foreach($options as $key => $val) { $selected = $_POST['first_name'] == $key ? 'selected="selected"' : null; echo '<option value="' . $key . '"' . $selected . '>' . $val . '</option>'; } echo '</select>';

You can change the login options in the config file.

The function parameters on separate lines bugs me too, but I almost always split queries up. Unless you are doing something like SELECT * FROM table, they seem to always be way too long to be readable. I tend to break it up on every keyword, and separate selected columns by table. For example... SELECT t1.first_name, t1.last_name, t1.email, t2.age, t2.gender, t2.location FROM table1 t1 LEFT JOIN table2 t2 ON t2.id = t1.id WHERE t1.first_name = 'John'

If you click "create table" on the navigation frame, it doesn't load a Modal window. As for your question, briefly looking through the changelog shows this for version 3.4.0.0 So maybe that's a start.