kicken

The PDO object will close the connection when it's destroyed. This will happen once it goes out of scope and is no longer accessible. There is no need to explicitly set it to null or call unset() for this. In your case, the object will go out of scope when you leave the function, so it will be destroyed automatically at some point after that. In any case, it will be closed when the page is done executing as everything is destroyed at that point. Note that the connection may not be immediately cleaned up when the object goes out of scope. It will happen during the next GC cycle which might occur a little later, or at the end of the script, depending on PHP's memory needs.

This topic has been moved to PHP Coding Help. http://www.phpfreaks.com/forums/index.php?topic=355799.0

JS doesn't allow a string to span across lines like that. I believe you can place a \ at the end of each line and it will work. Otherwise you concatenate the strings together. $("ul#wall").prepend("\ <div class=\"comment-main2\">\ <div class=\"commentname\">\ <a href=\"/profile/index.php?id=1\" title=\"Eric\">Eric</a>\ </div>\ "); //or $("ul#wall").prepend( "<div class=\"comment-main2\">" + " <div class=\"commentname\">" + " <a href=\"/profile/index.php?id=1\" title=\"Eric\">Eric</a>" + " </div>" );

So do you plan on making them re-input their password and then checking it when they try and update their email? Because unless you do that you won't be able to re-generate a hash as you won't have a password to hash. Following that, you can't generate a new salt without re-generating the hash. So either you have to ask for their password again when they input a new email address(kind of silly and unnecessary), or you leave the salt and password alone (nice and easy).

Your topbar is convering up the link in IE as well, IE is just letting the click get through for some reason (maybe a z-index difference). The issue is that you set the height of your top bar div to be 256px which makes it drop down that low. I'm not sure why you did this, disabling the height did not seem to have any effect on the page layout.

That was the idea behind it when the directive was created. It failed horribly at doing it's job and caused far more issues that it solved though, which is why it has been disabled by default for a while, and is finally being outright removed from PHP all together (as of 5.4). You should always assume these settings when you code: error_reporting=E_ALL magic_quotes_gpc=Off register_globals=Off short_open_tag=Off And code your scripts to work in that environment without errors. In the case of magic_quotes_gpc, if it is on then you have to un-do it's effect by running everything in $_POST, $_GET, $_REQUEST, and $_COOKIE through stripslashes(). You can do this using a recursive function fairly easily, google can probably find you an implementation if you don't know how to make one.

When I copy-paste the code and run it things seem fine, all the links in both lists activate. Based on your description the only thing that comes to mind is maybe you have an element styled in a certain way that causes it to cover the first few links. Adding the print_r caused them to be pushed down far enough that they are not covered. In chrome try hovering over one of the non-working links, right-click it and do 'Inspect Element'. See if it brings you to the link tag or some other element. Is it possible for you to link a live page where you see this happening?

Put all your conditions into an array then implode it with whatever operator you need (AND or OR) $where = array(); if ($blah){ $where[] = ' field >= whatever '; } if ($bleh){ $where[] = ' this=that';} if ($blargh){ $where[] = ' thisway!=thatway '; } $sql = 'select ...'; if (count($where) > 0){ $sql .= 'WHERE '.implode(' AND ', $where); }

You can build up some more complex join conditions by using the join syntax. Aside from that though the main reason I prefer them is it keeps your join conditions separated from your where conditions and makes the query easier to read, especially when you get into some bigger more complex queries. For example SELECT sesuni.ADM_UN_ID as universityId, sesuni.ADM_UN_name as universityName, sescam.ADM_CAM_ID as campusId, sescam.ADM_CAM_name as campusName, ses.ADM_SES_ID as sessionId, ses.ADM_SES_name as sessionName, cat.ADM_CAT_ID as catalogId, cat.ADM_CAT_name as catalogName, sesoff.ADM_SES_OFF_ID as offeringId FROM session ses INNER JOIN academic_years sesay ON ses.ADM_SES_ADM_AY_ID=sesay.ADM_AY_ID INNER JOIN campus sescam ON sesay.ADM_AY_ADM_CAM_ID=sescam.ADM_CAM_ID INNER JOIN universities sesuni ON sescam.ADM_CAM_ADM_UN_ID=sesuni.ADM_UN_ID INNER JOIN session_offerings sesoff ON sesoff.ADM_SES_OFF_ADM_SES_ID=ses.ADM_SES_ID AND sesoff.DBODeleted=0 INNER JOIN catalog cat ON sesoff.ADM_SES_OFF_ADM_CAT_ID=cat.ADM_CAT_ID AND cat.DBODeleted=0 WHERE ses.DBODeleted=0 AND SYSUTCDATETIME() BETWEEN ses.ADM_SES_reg_start_date AND ses.ADM_SES_reg_end_date vs something like SELECT sesuni.ADM_UN_ID as universityId, sesuni.ADM_UN_name as universityName, sescam.ADM_CAM_ID as campusId, sescam.ADM_CAM_name as campusName, ses.ADM_SES_ID as sessionId, ses.ADM_SES_name as sessionName, cat.ADM_CAT_ID as catalogId, cat.ADM_CAT_name as catalogName, sesoff.ADM_SES_OFF_ID as offeringId FROM session ses, academic_years sesay, campus sescam, universities sesuni, session_offerings sesoff, catalog cat WHERE ses.ADM_SES_ADM_AY_ID=sesay.ADM_AY_ID AND sesay.ADM_AY_ADM_CAM_ID=sescam.ADM_CAM_ID AND sescam.ADM_CAM_ADM_UN_ID=sesuni.ADM_UN_ID AND sesoff.ADM_SES_OFF_ADM_SES_ID=ses.ADM_SES_ID AND sesoff.DBODeleted=0 AND sesoff.ADM_SES_OFF_ADM_CAT_ID=cat.ADM_CAT_ID AND cat.DBODeleted=0 AND ses.DBODeleted=0 AND SYSUTCDATETIME() BETWEEN ses.ADM_SES_reg_start_date AND ses.ADM_SES_reg_end_date In the first all the conditions related to how the tables join together are nicely separated and associated with their particular join. In the later it's all just one big mess in the where condition. That's actually a pretty simple and basic query compared to a lot of what I do each day.

You could put them in either direction for the most part. I find it easier to conceptualize a query using left joins. I usually will have one table that would be considered the source table of the data, and another that has additional information. I make the source table the left and the additional table the right. For example, if I wanted a list of all students and their invoices I'd do: select * from students left join invoices on students.StudentId=invoices.InvoiceId As conceptually to me I want to first grab a list of all the students, then look into the invoices for any matching rows. Use which ever form makes the most sense to you though when your writing your queries.

Yes, that is a multi-dimension array. You would access the value 1 of key b using: $array['a']['b']; The first level you need to get into is key 'a', then you need to go into key 'b' to get the 1. The value 'c' would be assigned to index 0. When PHP auto-indexes it uses either 0 if there are no existing numeric indexes, or whatever the highest numerical index is, +1 as the new index

You can read through this other thread for a rather in-depth discussion of web vs filesystem roots and when/where to use them.

That code would be no better than just using a timestamp directly in the name really. If two people uploaded a same-named image during the same second, you'd still generate the same final name for each. You need some kind of randomness to prevent this. I prefer to simply use the uniqid function for this. As an additional safeguard you'd want to include the code in a loop checking if a filename exists. based on the OP's code: foreach ($_FILES as $file) { $fileName = $file['name']; $tmpName = $file['tmp_name']; $fileSize = $file['size']; $fileType = $file['type']; if ($fileName != ""){ $filePath = $uploadDir; $fileName = str_replace(" ", "_", $fileName); //Split the name into the base name and extension $pathInfo = pathinfo($fileName); $fileName_base = $pathInfo['filename']; $fileName_ext = $pathInfo['extension']; //now we re-assemble the file name, sticking the output of uniqid into it //and keep doing this in a loop until we generate a name that //does not already exist (most likely we will get that first try) do { $fileName = $fileName_base . uniqid() . '.' . $fileName_ext; } while (file_exists($filePath.$fileName)); $result = move_uploaded_file($tmpName, $filePath.$fileName); } }

Welcome to the club scootstah! Dues can be paid directly to me

Your already in PHP mode as part of your outter if statement. As such your <?php ... ?> tags are not counted as php tags. Since your code is contained within a string as part of an echo, it is not run. What you need to do is either leave PHP mode or use put the checked value into a variable and use that in your echo. <?php if ($id != "4" ) { $checked = $myPageActive=='Yes'?'checked':''; echo "<input type='checkbox' name='myPageActive' value='Yes' $checked> Yes"; } else { echo "<span class='myDeleteMessage'>Homepage must stay active</span>"; } ?> As a side note, you should always use <?php, never the short form of <? as it's possible for that tag format to be disabled which would render all your code using it useless.

The point being made is that the current working directory is not necessarily the same as the directory that contains the file being run. It can be changed either through the use of chdir or by how you run your script. For instance in PHP-CLI, lets assume the following layout: /root/myscripts/script.php /root/myscripts/config.php And your currently sitting in the /root directory. When you run php myscripts/script.php then the current working directory is /root, not /root/myscripts. As such, a relative path of "config.php" would be incorrect and cause a file not found error, where as using __FILE__ to generate an absolute path would work. As has been noted though, PHP's include apparently will take this into account on it's own and locates a file using a process like: Does the given path exist? Yes, Include it Can we find it by searching include_path? Yes, include it Does it exist in getcwd()? Yes, include it Does it exist in __DIR__? Yes, include it Else, fail. That is specific to include/require though. If you were to do something like fopen or file_get_contents it would fail with a file does not exist error.

There's no way to open an actual unmovable window in javascript. What you can do is open a DIV on top of your page and dim out the page using an overlay div. Then you can control whether that div is movable or not. For an example of this setup check out Thickbox

It's their position relative to the JOIN. FROM tableA JOIN tableB tableA is the left table tableB is the right table. When you specify LEFT, RIGHT, or INNER join it determines what happens when rows don't match up. For an INNER JOIN if a match can't be found in tableB for a row in table A then the row is dropped from the result set. Likewise only rows from tableB that match a row in tableA are kept, the others are dropped. For a LEFT join then all the rows from the LEFT table (tableA) are returned. If a matching row cannot be found in the right table, those columns are filled will NULL values. For a RIGHT join then all the rows from the RIGHT table (tableB) are returned. If a matching row cannot be found in the left table, those columns are filled with NULL values. There's also a CROSS JOIN where all the rows from both tables are kept. There's no condition for this type of join, each row from tableA is matched up to all rows in table B.

No, your not understanding what I am saying. Yes, you have that. But That file is NOT included The code in that file is NOT run Therefore, you do NOT re-connect You could just delete that line from your script, it would function the exact same way.

No, because that file is not included and thus, the code inside of it is not run. It's not included because it's already been previously included in your last_activity.php file. Because it's not included and the code is not run, it will not re-connect to mysql. The once-ness of require_once/include_once is not per-file, it's per-request. It does not matter if the file was included first in some other file. If it has been included at all during the current request, it will not be included anymore. No, it would not. It's quite common to let PHP handle closing the database resources on script end rather than trying to manage it yourself.

Since your using require_once that file is only ever going to be included in your script ONCE. Since you already included it in your last_activity.php file, this second call to it is essentially ignored. PHP will automatically clean up any open connections when your script ends. Unless your writing a long-running script but don't need the DB access for the whole duration of the script, you don't really gain anything by trying to close the connection early. It just adds confusion and complication to your code by making you have to remember when a connect is or isn't open. Also it's better to open the connection once, do everything you need then close it instead of opening a new connection for each query (or group of queries).

I always like the idea of some contests and challenges. I'm not sure how much I'd be able to participate, depends on my schedule and what not. I'll help contribute to a prize fund though.

Output is, roughly - Anything you echo or print - Anything sent by functions like print_r, var_dump, readfile, etc. - Anything that is outside of <?php ?> code blocks - Any error messages generated by PHP and sent to the browser (Warnings, notices, etc) Ultimately, if you can see it in your browser it is output. Anything you have to do prior to output such as use header() or call session_start() has to occur in your code prior to any of this. Once you have even a single byte of output, you can no longer use those functions. Output is this

Ideally you would use a single query and a JOIN to get the data you need. You would do your headings by tracking the value of the field used for the header and only output the code for a header if it changes. Switching to this single query method would likely result in a considerable speed-increase of your page. Executing multiple select queries in a loop as you described is one of the biggest performance no-nos you can do. You can use ob_flush and flush to clear out PHP's buffers and send the data. Whether that makes it all the way to the browser and gets rendered is a whole different story that you cannot control though. There may be other buffers such as a proxy server or the browsers internal render buffer.

That would be because your not echoing anything. Also you're calling file_get_contents which is php's built in function, not your get_url_contents function. As such, you could just remove that whole function as your not using it. echo $str;