kicken

You would have to implement your own timeout check by storing the last active time in $_SESSION and verifying it on every page load. If the time between now and $_SESSION['lastActivity'] is greater than 45 minutes, you destroy the session and show them a timed out message.

Use youtube's Data API rather than try and hack together a horrible screen-scrape solution.

Use number_format to add zero's to a number in PHP. As for the date, '2010-02-30' is an invalid date. You'd have to decide what you want it to be first, then change it to that date.

There is a notify button at the top and bottom of each topic. You can click that to add the topic to your notify list. Then you will receive an email about any replies to the topic.

Really it depends on how much work and time you want to invest into the proccess. Do you want to manually review every photo before it is allowed? Then do like you said and set a flag to no on upload and email yourself or build some kind of admin queue interface (or both). When you approve the image have a script toggle the flag so the photo is then allowed. Until it is allowed you can either a) Continue serving the old image (if one exists) or b) Serve some type of placeholder. This could be a plain silhouette image, a gravatar, or whatever really. The other option is to let the community police itself and just implement some type of report image function. Then whenever people see a bad photo they can report it. This would email you a notice about the photo so you can review it and then take it down if necessary. You'd have the same type of approval flag on the image in the setup, except it would initial be set to on and you would toggle it to off either after a report or after a review.

Your second line of regex's have no delimiters in them at all.

MySQL has a function which will return a 64bit integer unique id that you could use in your application. There is also a function that returns a 128 Universal Unique Identifier. UUID_SHORT() UUID() You would just use that function in your insert queries instead of (or in addition to) an auto_inc column, eg: INSERT INTO photos (PhotoID, UserID, Filename) VALUES (UUID_SHORT(), $UserId, $Filename) If you needed to know the value of the ID for the new row to do additional operations you'd want to select the id first, eg: $query = 'SELECT UUID_SHORT() as id'; $res = /* Run $query */ $row = /* Fetch from $res */ $query = 'INSERT INTO photos (PhotoID, UserID, Filename) VALUES ('.$row['id'].', $UserId, $Filename)'; ///and so on

Not all together no, just for certain things. Your current logged in user and their details can all go in $_SESSION without any issues. Things that apply to the current user as a whole and are session-wide can go in there as well (ie, shopping cart data). You just have to consider how storing information in the session might affect a person who is using multiple tabs. For example I used to work on a system that users would do a search and "open" a student account then browse through other pages which pulled up details on that student (courses, grades, invoices, etc). The way it worked is by storing that student id in the session and using it on each page. This was all built back before tabbed browsing became popular so nobody really thought about it too much. Fast-forward to current day where every modern browser has tabbed browsing and users take advantage of that fact, we had quite a few complaints about how if they tried to open a second student in a second tab it broke their first tab. As of my last day there the issue had not been fixed yet. It probably still hasn't due to how much of the system it affects that would need updated.

You could try using a different library such as [m=imagick]ImageMagick[/m] or maybe GMagick if your host has them available. Even if they don't have the ImageMagick extension they might have the cli apps which you can use exec to run separate from your script which would offload the memory usage to another process. You'll have to check with your host to see what options they have available for you to use. Running a separate program using exec is the only way to really reduce the memory usage from PHP's point of view though. Switching to another library within PHP might make small differences but ultimately processing images is just a memory intensive process and there is not much you can do about it.

Yes. One issue with relying on $_SESSION values though is that they can break the ability for people to use multiple tabs when browsing your site. As a bit of a contrived but completely possible example, lets say you have a page to view a user's friends list. So say I go to one of my friends and star looking over their friends to see if there is anyone they have befriended that I might want to as well. Next to each of the friends in that list you have a link/button that I can click to request to be friends. Being the tab aficionado that I am I find a few people and for each one of them I 'Open in new tab' that add to friends list link. Lets say I click the links for 'George', 'John', and 'Paul', in that order. I'll have three tabs open then one for each of them with a form to put in a message or something and click add to finish and send the request. Since the page for 'Paul' was the last one to be loaded though, his ID is going to be the one stored in the session. So when I go to the tab showing 'George' and enter my message and hit send, your script will pull the ID out of $_SESSION but that ID will be for 'Paul' not 'George'. As such 'Paul' will be getting my friend request with my message that was intended for 'George'. The same would happen when I submit the page for 'John' and then finally for 'Paul'. /end of little example story. That is why you should try and not use the session for such values. You will want to pass them through the URL or hidden form fields. As mentioned though, all form data can be tampered with so you always have to run your validation checks. In the case of this member id value, as mentioned, there area really only a few things you need to check. 1) That it is a number 2) That the user represented by that number exists 3) That they are allowed to request to be friends with that user (since you said anyone can request anyone this check is basically an always-true check thus not really needed) 4) That they are not already friends with each other. That's all. Fairly simple check which you could probably do all in one query plus a (int) cast on the value.

I don't generally care who I decline. Most of the time it's just spammers or random people I don't care about that I decline so I couldn't care less if I ever saw there name again in some list saying who I declined. Yes, you probably should. Like most things in life friend statuses can change. You don't necessarily need a separate page for this, just a button next to them on the current friends list to remove them.

You can't declare a whole class as 'static'. Only individual member variables or functions. Remove the static from your class definition and apply it to whichever members need it (if any).

Checking for empty includes !isset so all your additional isset checks are unnecessary and can be removed. If all those variables match up to keys in $_POST (or similar) then you could write a function which accepts the array and key names to check for. function hasEmptyFields($arr, $keys){ $error=str_repeat('0', count($keys)); foreach ($keys as $i=>$k){ if (empty($arr[$k])){ $error[$i]='1'; } } return $error; } $fields = array('register_account_type', 'register_fname'); //add as many as needed if (0 != (int)hasEmptyFields($_POST, $fields)){ //something is blank. } I coded it to replicate the way your $error variable is generated in case you use it to determine error messages or something. If all you need is a yes/no answer you can change it to just return true or false from the function rather than create that error variable.

For just CLI purposes I'd go with a VC9 build that is non-thread-safe of whatever the most recent version of php is (5.4.3 atm). There is no need for thread safety in CLI since each instance is it's own separate process, and VC9 is a more recent compiler. As far as cURL goes all you should need to do is load the extension dll via the php.ini file settings.

Check out the Eloquent Javascript book. The first couple chapters a kind of like programming 101 but JS is quite a bit different than PHP though so you'll probably want to have a look at least (skim maybe) rather than just skip them entirely.

I just created a wrapper for htmlentities with my defaults and a shorter name: function hent($str, $type=ENT_QUOTES, $char='UTF-8'){ return htmlentities($str, $type, $char); } To add your array support one could do: function hent($str, $type=ENT_QUOTES, $char='UTF-8'){ if (is_array($str)){ foreach ($str as &$v){ $v=hent($v, $type, $char); } return $str; } else { return htmlentities($str, $type, $char); } } Or if your on 5.3 or better: function hent($str, $type=ENT_QUOTES, $char='UTF-8'){ if (is_array($str)){ return array_map(function($s) use ($type,$char){ return hent($s, $type, $char); }, $str); } else { return htmlentities($str, $type, $char); } }

No, you have to update your code to use the new PDO object rather than the old mysql_* functions (or whatever you were using). How complicated that is depends on how your currently using the functions. If your using them directly on each page you'll have to update each page. If you use a wrapper library you'd only have to update the wrapper.

Why not just use one of the other languages that supports what you like rather than try and mess with PHP? I like my PHP just the way it is. Server-side JS with NodeJS seems to be the latest fad going around and it supports syntax like you want, give it a try. For what it's worth, Functional programming is beginning to move up into the "greatest thing ever" spot to replace OOP from what I've seen. Maybe in a few more years OOP will all "amature" code and real programmers use a functional approach.

I put all my startup stuff into a common.inc.php file and just include that on individual pages. My system composes mostly of classes so I use autoloading to include things on demand but you could just list out your includes. Including a file even if you don't need it is generally not a big deal. I will include checks for some constants too to help control some features such as doing: define('NO_DATABASE', true); define('NO_SESSION', true); require 'common.inc.php'; Which would cause my startup code to skip connecting to the database and starting a session.

Your missing a quote.

It would help if you actually stated what errors you were getting rather than just saying it doesn't work. It would also help if you posted the code you were using (within [code][/code] blocks please). You need to make sure you have enabled the proper drivers in your php.ini file for the database type you want to access.

On a somewhat related note, you can see what they have planned / what people are requesting by going tohttps://wiki.php.net/rfc. If one had an idea for something they wanted one could submit a RFC for review and it might get developed. You'd probably need to be willing to do some/most of that development yourself though.

I would probably go for the first one as well. As mentioned the incoming part is somewhat irrelevant (as far as a url goes anyway). I would probably go for something like this instead of either but it's not that big of a deal: http://local.debbie/account/messages/view/3

Yes, you are. There is no need to choose a query ending. You can use a clause like: WHERE ? IN (m_to.id, m_fr.id) AND pm.id=? That will cause the query to return a row only when the message ID matches what is in the URL and if the member id in the session matches either the to or from IDs.

So long as you validate that the selected message id has been sent to or from the currently logged in user then there is no problem. The user shouldn't be able to manipulate the member id in anyway since it is in the session.