gizmola

Maybe this will help you determine where your logs are: It has been many a year since I have used a windows server with IIS, but I did find some tips that should help you out in your configuration, regarding downloads. This is part PHP and part IIS specific. Remember to restart IIS after you add/change these params. This assumes you want to support files as large as 20 megabytes. For PHP Edit PHP.INI: post_max_size = 21M upload_max_filesize = 20M For IIS: Edit MetaBase.xml AspMaxRequestEntityAllowed AspBufferingLimit These both need to be set in bytes >= the file size you want to support. You should be able to edit both files using notepad or wordpad. Best of luck.

You are on the right track. Simply have a counter variable that you initialize to 0, and check that out to determine whether or not you need to preface your WHERE clause criteria with an 'AND'. $critCount = 0; // Number of criteria if(isset($_POST['archiveoption'])) { if ($critCount > 0) { $query .= ' AND'; } $query .= " archiveoption='$_POST[archiveoption]'"; $critCount++; }; etc... This way, once the first criteria is added to the WHERE clause, any subsequent criteria will be added using the AND. [/code]

I see that your server is a windows OS? Are you running IIS, Apache or what?

You need to make those lines at the bottom be: <?php echo $row['FirstName']; ?> etc.

Why would you want to reinvent the wheel, not to mention add considerable load to your database, when there are numerous log analysis products out there? Don't get me wrong -- I have used internal logging many times, but never just to have something that comes easily from the logs. Your list of pages will come right out of the log analysis.

There are 2 sections: In your form code above, add this code at the top: require_once('recaptchalib.php'); $publickey = "..."; // you got this from the signup page Then where you want the recapctha to appear, you echo it out .. echo recaptcha_get_html($publickey); In your register_script.php -- require_once('recaptchalib.php'); $privatekey = "..."; $resp = recaptcha_check_answer ($privatekey, $_SERVER["REMOTE_ADDR"], $_POST["recaptcha_challenge_field"], $_POST["recaptcha_response_field"]); if (!$resp->is_valid) { // Redisplay the form -- would be good to pass an error message header("Location: --- your form script url"); // Do this die in case they are trying to game the redirect die ("The reCAPTCHA wasn't entered correctly. Go back and try it again." . "(reCAPTCHA said: " . $resp->error . ")"); } else { // Recaptcha was good -- go ahead and do whatever other processing you need }

Where is your closing '}'?

Step 1: Go to recaptcha site, do the signup get your recaptcha keys Step 2: Go to this page and read it: http://recaptcha.net/plugins/php/ Step 3: In step #2 there's a php library you download, so do that and put it in the appropriate place Step 4: Test out your new recaptcha'd page(s). Step 5: Come back here with problems, when you have already done step 1-4. Good luck -- recaptcha is a great solution, and works very well in my experience. It's nice to know that it is also helping to correct books that have been scanned for the benefit of future generations.

Answer depends on what the document root for your site is. You can get this from apache, via the $_SERVER['DOCUMENT_ROOT'] variable. Needless to say, if your site ever gets moved around, then this will all break -- so perhaps it would be good to fix up your application so that it no longer stores the absolute path to these images. Such a fix could be easily done against the database with a single update statement that would remove the portion which currently includes the Document root portion. In the short term however, you could fix up the paths using this simple code: // assumes that $imgpath has the retrieved path to the image from the db echo '';

So the fulltext index works very differently than a normal index because it's dealing with an internal score in regards to matching. With that said it has the advantage of matching phrases. I would fully explore it before you attempt to roll your own version of what it does, by breaking up everything into a giant keywords table, which inherently can't match phrases. You do have to read a bit on how it works. For example, you need to use the right query syntax -- in your case something like this I think: "SELECT * FROM table WHERE MATCH(title) AGAINST ('" . mysql_real_escape_string($search) . "') LIMIT 0, 15";

Yup! You are table scanning every time, because mysql can not use an index when you issue a like query, and use a wildcard at the start of the query as you are doing. LIKE 'Something%' --- will use an index LIKE '%Something%' -- no query can be used This is not a mysql issue, it works this way with all relational databases. An alternative is the full text index.

You didn't provide the code for login, so there's no way to know. Also, when you insert the row, I don't see you doing any md5() on it.

I think I've stated this several times already in this thread --- do not use an php for the timestamp! Insert the row, omitting the timestamp column from the column list, and do not provide any value for it. The server will set the time of the timestamp column for you, on insert.

If you read my blog posting it has examples of how to issue a create table statement. If the table already exists you need to issue an alter table. Since you stated you were using phpmyadmin, it gives you a facility to easily create a table or change one without knowing the specifics of the create table syntax, which isn't difficult in any case. The beauty of the timestamp is that you don't specify the value for the timestamp column -- it gets filled in automatically when the row is inserted. There are caveats to using a timestamp, as I explain in the article. You can also use a DATETIME column alternatively. In that case the sql would be as simple as: INSERT into your table (col1, col2, createdOn) VALUES ('some name', 'somename@somedomain.com', NOW()) There is no need to involve the PHP date or convert it, whatesoever. MySQL will take care of this all for you.

Please don't do this -- it's one of my pet peeves. You are using mysql, which has a built in timestamp column type. I wrote a fairly extensive article about the timestamp: http://www.gizmola.com/blog/archives/93-Too-much-information-about-the-MySQL-TIMESTAMP.html

Well you really didn't look at the link I provided did you?

Banner tracking is usually done as a series of redirects. The loader tracks the impression serverside, and returns the image/flash/html what have you content. In terms of bot suppression, it's actually worse than you know, because not only do you need to look at the user agent data, but you also need to look at the IP, since there are annoying bots that cloak themselves by spoofing the user agent. I might add that these are both reasons why serverside is a good way to do it, because the client does not have, nor can it be trusted to provide the IP address or the user agent. With that said, neither can be entirely trusted, but at least you get what the webserver sees. On one site where I do this type of logging, I implemented some code that checks both the IP range and user agent data against tables of known bots. While I didn't start with a database of known bots, there is a lot of info that can be found via googling, and on webmaster's world (which I personally don't subscribe to), as well as other sites. I found a site with a db that I could have started with, long after I'd already been manually updating my list based on bots that I saw. http://www.robotstxt.org/db/all.txt In my case, I have a page the summarizes visits by IP for a certain time period, and I allow drilling into that to see the useragent strings. I added some simple code to allow me to click and add that string to the exclude list. Same goes for IP addresses. I used to look at these stats once a week, and my stat system allows me to exclude and delete all the click rows for that IP address. It's worked fairly well over the years. The only concern is that this puts a transaction load on the mysql database, but the site in question doesn't get enough traffic for me to be concerned about the overhead.

Yes of course. Just check out the apache manual on the location directive. http://httpd.apache.org/docs/1.3/mod/core.html#location You can specify your access rules inside the location.

In order for Ajax to work, everything has to go right. The client has to - Fully load the page - Support javascript - Successfully initialize the ajax socket call back to the server - Successfully run the ajax post function There's a lot of things that can go wrong there. Needless to say, the gold standard has always been analytics built on top of the native webserver logs, although the roll your own serverside method, does have the advantage of awareness of the specifics of your application. Sometimes those metrics are more important to you than what weblogs might have. For example, a movie review site, can keep track of reviews read, and then provide statistics like "total reviews for Author Bob Jones" or "total reviews read of movies starring Brad Pitt". You'll never get those stats directly out of a web analytics tool. The other problem with analytics tools is that when you have a web farm, you have to really work on a scheme to combine logs, or deal with looking at each web server independently that is far from ideal. I've found the best combination personally to be a combination of a web log analytics tools, and my own serverside application specific logging. I don't think that ajax is a good match at all for tracking page views.

Well it looks kinda simple to me -- nothing that a few print_r()'s or echo statements for debugging wouldn't show you. For some reason you are looking for a get param named 'active_code'. However, your email creates a url, where the activation code in a param named: 'activationkey' ie. email=$email&activationkey=$activ_code So you compare this empty string and of course it does not match. Change if ($_GET['activ_code'] == $acode) ...... to if ($_GET['activationkey'] == $acode) And maybe you will have more luck.

Well i disagree a bit. I don't think PHP would have had the uptake it did, if it didn't have so much functionality. No matter how simple a language, if people can't do what they need to, be that interface with a particular database, or dynamically create images, or what have you, they would not have used it. When PHP started to gain traction, the leading web development languages at the time were vbscript, ColdFusion and Perl. So basically you had 2 commercial products with limited libraries, and one language that really wasn't built for doing web development specifically. While you could certainly do everything in those languages that PHP does, there wasn't the wide range of free extenstions, since traditionally commercial companies like Allaire and Microsoft would have satellite companies that would grow up to provide commercial addons. People who were on a limited budget, or hobbyists and developers couldn't or didn't want to pay for tools just to do things like create graphs, so when they looked at PHP and saw that it came with the ability to do all sorts of complicated things easily and for free, the adoption rate for PHP became very rapid. When I think about these things, it all reminds me that I'm starting to sound like an old man talking about "in olden times when we just had CGI and we used C for our web pages, and we liked it!" Anyways, I agree with you Daniel that PHP's surface level simplicity, which could also be thought of as, cutting out the needless complexity and focusing on productivity, certainly helped make the language popular, but I also was witness to that period of time, and PHP rode the wave of Open source and linux adoption. It wasn't all that long ago that most websites ran on Sun hardware.

Question 1: This is in the php manual spelled out really well -> http://php.net/manual/en/function.include.php -If you include a path with the include (absolute or relative) it will use that to try and find the file to include. -If you omit the path it uses the php include path, which is set up in the php.ini. In summary: - include, like all the PHP file related functions, works with the *real server path*, be that absolute or relative. Often people on hosted servers get confused about this, because they are not really aware where there web root is located. PHP usually will provide this in the $_SERVER['DOCUMENT_ROOT'] variable, so one strategy could be to set up a BASEPATH constant or variable which is equivalent to that variable ie. $basePath = $_SERVER['DOCUMENT_ROOT']; Then you can specify the path to your included files using an absolute path, by concating them to the base path: // You have a file that is in {webroot}/includes/ named functions.php include($basePath . '/includes/functions.php); Alternatively you can specify the path relatively, although this has the complexity of requiring that the script doing the include be aware of its relative relation to the included script(s). Question 2: Again, $_SERVER[] is your friend. $urlParams = explode('/', $_SERVER['REQUEST_URI']); Check out the contents of $urlParams.

Let's see your current code.

I don't think that there is a "best" language. Whatever you are most productive with, is the best language. If you're talking about PHP, I think one of the reasons for its success is that it was designed for extensibility. PHP's core, is really small -- basically the Zend Engine, which does the parsing, and the Server Application Programming Interface which talks to whatever server PHP is running against. Right away, when you look at that design, you can see how PHP is intrinsically built to do serverside programming, since it comes built in with the idea that it should work well with a variety of (typically) web servers. PHP is also written in C, and what we think of as PHP is mostly a bunch of PHP extensions. The PHP team realized early on that having tools and resources that made it relatively easy for C developers or interested parties to be able to make use of an existing library in PHP would provide all sorts of functionality to developers in a very short amount of time.

Not if you use mod_perl. Perl continues to be used for website development, however I think it fell out of popular favor for a couple of reasons. First it's syntax can be hard to read, because it uses a lot of unix shell stuff. Since Larry Wall was first and foremost a linux sysadmin/hacker type, he was catering to his audience and himself, and using things that were similar to bourne and c shell syntax which certainly made sense considering his primary audience. Perl was intended to be a swiss army knife for the unix sysadmin, and so in that way it's very general purpose. Since then, and especially with the success of CPAN, there's perl modules that allow it to do just about anything, but it isn't inherently focused on server side web programming. PHP on the other hand, started out as a toolkit for web development and form processing. It's primary goal was always to be a good serverside web development language, so it has features that focus on the problems web developers face. Some of PHP's best features were borrowed either in design (dynamic associative arrays) or implementation (the preg_* functions).