gizmola

This is basically the idea behind the popular idea of class relationships via dependency injection/inversion of control/loose coupling. Nice article by the architect of the symfony framework explaining the idea in more detail here: http://fabien.potencier.org/what-is-dependency-injection.html It's great to start with private variables, but frequently you want to take a step back from that and use protected variables, unless you are certain you will not be using inheritance.

That is only something you would do if there is a public facing aspect to the system, where other users would be able to see information about the user in question, or interact with them in some way. Facebook and Twitter are both social networks that are driven by that design. Most systems don't do that unless it's specifically for the reason of providing a public facing page for others. When you login to Facebook, your url's don't all become Facebook.com/yourname/....

We discussed this a long time ago, and the consensus was that we wanted to keep everything positive. "Disagree" would carry with it negative connotations, and the argument is/was that if you disagree with some advice you are always free to post an alternative. A quick "thumbs down" button is also prone for abuse.

I've also found the strip format button to be useful on occasion.

FWIW, this was because the time on the host machine was off. Phpfreaks is running in a virtual server, so any attempts to fix the time locally were doomed. We had to get the host server date/time fixed, and Eric setup NTP so hopefully this problem will not re-occur in the future.

How about: $string = $_REQUEST['sched-date']." ".$_REQUEST['sched-start']; $date = DateTime::createFromFormat('Y-m-d H:i', $string); echo "String: $string\n"; echo "ISO Format: " . $date->format('c');

I don't see the "reservation" aspect of this app. What problem(s) are you actually trying to solve? You're down in the weeds and you have to start with the requirements of the app.

You took a clean simple idea and delivered a solid working system in a short time frame. The end result is well thought out. This project demonstrates that you are a very flexible developer with a lot of domain knowledge in a number of hot areas, from PaaS to clouds api usage, to git, to Devops, to the Laravel framework and it's ecosystem, etc etc. It's a nice portfolio piece, and something you can continue to tweak and work on in your spare time. We could quibble with individual decisions you made, but that's true of every system I've ever been involved with. Logical extensions? Your sharing/social bar could be more effective. The UI could be a little prettier. Add a Rest API, and create some mobile apps. Allow people to comment. Add a mail list subscription feature and email out a "picture of the day" with ad. Really there are a lot of things you can do with this to add to it that will allow you to keep experimenting. If more people took the approach you have, there would be a lot more competent developers in the world.

Neil, you left out: Make a sandwich Take power nap $$$ Profit!

They have a Vim plugin. You can run vim in the terminal. Why not just use that? There are also extensions for chrome, firefox and safari.

You can hook up xdebug to a lot of different editors. With that said, in order for a debugger to work, you need some sort of editor to load code and display it for step through. Most people are using one of the more popular PHP IDE's (PHPStorm, Eclipse PDT/Zend Studio/ Netbeans, etc) and understanding how xdebug works and what you have to do to utilize it isn't exactly point and click, depending on your development setup. For example, I wrote an article on how to get things setup with Eclipse/PDT some years ago, and it's not the easiest thing in the world to get started with. Take a look at it if you're interested.

JonL, I know you are doing your best to try and help increase the knowledgebase. This is one of those questions we get a lot where the OP was not clear and that's a big reason why this never seemed to get a satisfying conclusion. Let's be clear about some web development related definitions. cookie A cookie is a key/value pair that is stored (or not) by the client (browser). There are plenty of issues and gotchas in regards to cookies, specifically in how to set their expiration and the relevant domain that could explain problems the OP had. Cookies are set by the browser when a request is sent to do so in the HTTP header. So this requires that the setting of a cookie needs to occur before any output has been sent. Once a cookie is set by a browser, it then sends the cookie data in the HTTP header of any subsequent requests, and php makes this cookie data available in the $_COOKIE superglobal array. It's important to note the importance of HTTP headers in both cases. You can't for example, set a cookie in your script and then go read it from $_COOKIE in the same script (chicken and egg). session cookie A cookie that will be automatically deleted when the browser "session" ends, or in other words, when the browser is closed. A cookie is a "session cookie" when you don't specify an expiration when the cookie is created. By default the php session id cookie happens to be a "session cookie" in that it does not set an expiration date, although like just about everything else with php sessions, this behavior can be modified. php session A php session is an automated serverside mechanism that will associate a bundle of data with a session id, and serializes/unserializes it for every request where sessions are invoked. Note that a "session cookie" has nothing to do with php sessions. The preferred way that the php session data is associated with a browser/user/client is through the setting of a cookie. php session variables These are created by making an assignment to $_SESSION for an active session (one where session_start()) was called. $_SESSION variables are just like any other array when a php script is executing, except for the fact that the values are serialized to disk (by default), and will be automatically unserialized and made available in the script in the $_SESSION superglobal array. Given all the confusion possible, it is understandable that there are various ways to approach doing something in particular related either to cookies or to sessions. Again, while it was never clear from the question, many people need to know how to terminate a session, usually because they want a logout feature or redirect that clears things out. PHP provides a way to do that: session_start(); session_unset(); session_destroy(); Some people have claimed that the values in the $_SESSION superglob will live on in a script beyond the session destruction functions unless you assign it to an empty array. I haven't had this problem myself so I can't speak to it. Rather than unset($_SESSION) which will completely disable php session functionality in the rest of the script, you can instead do: session_start(); session_unset(); session_destroy(); $_SESSION = array(); The PHP manual specifically advises against using unset($_SESSION) so I don't think we should endorse it. I think it's worth going back to the original question. Can you make the browser delete a "session cookie" as defined above? The methods he tried did not include simply setting the cookie with an empty value: setcookie('account', ''); Again it has to be emphasized that if I made that call in a script, I would still find $_COOKIE['account'] to have a value even though I requested that the client browser "overwrite it with nothing". On further requests however, the value would not be there. It's also important to note that the OP never provided code that had anything to do with php sessions. He seemed to be setting his own cookies and using them for whatever reasons, so discussion of $_SESSION is probably a complete tangent from the the original post.

Looks to me like this rule is rewriting everything to www.....