Hopefully, you have one of those friends who has your back, who will step in and stop you from making a really, really stupid mistake. Because we all are fallible and whether it be in a moment of rage, or just because we are in a rush, we will make mistakes.
This is why I have PHP Lint added as a pre-commit hook on my PHP Project repos. It only takes a minute to set it up and will have you a ton of time, and headache in the future.
First, you need to make sure you have PHP Lint installed on your system. If you are a PHP developer, then the chances are you have it.
Next go to you PHP project .git directory and add the following code to the file .git/hooks/pre-commit
And that should be it. Now every time you do a commit on some PHP code, your git workflow will send each file through the PHP Linter to check for errors. See the example below
Most editors will show you when you make an error, but we are rushing and don't notice that we forgot to add a semi-colon.
We add the file and attempt to do a commit but because of the hook, Git will refuse to commit the files, and we can sleep easier at night knowing we can't accidentally send broken code to our repo.
One thing to note, this git hook will only parse the files you are committing and not the entire project. Meaning if you have a co-working was not doing linting, and you pull in their changes but don't touch the file, your commit will not catch it.
When you heard that phrase in the 80's, you knew things were about to get funky. However, in the coding world, dealing with dates and time can be a real pain. I did a presentation for our Laravel User Group about a package that I enjoy called Carbon which makes working with dates and times a ton easier.
If you know me, you know I am a sucker for a good framework. Doesn't matter the language I am using, I will typically look for the hottest framework on the platform when I start a project.
In my primary development world of PHP, that framework had been cakePHP for a very long time. I had tried several others, but none of them stuck with me like cake did, that was up until a few years ago when a friend with our San Diego PHP User Group started pushing another framework on me called Laravel.
In that time, I've taken the Laravel framework further that I have any other including starting a development group that specializes in the framework. As typical, when I do something I like to submerge myself totally in it, and it wasn't too long before I found myself running a User Group for the Laravel framework.
During that time, I've had the opportunity to speak with a few of the key members of the Laravel community. The following two videos are interviews I did with Taylor Otwell (@taylorotwell) who is the creator of the Laravel Framework. The second video in my interview with Jeffrey Way (@jeffrey_way) who I consider the head educator for Laravel. Enjoyed talking with both these guys. They were super friendly and very, very accommodating.
First up is Taylor Otwell, the creator of Laravel. Great discussion with him.
This is Jeffrey Way's video, we had some major auto problems this night, sorry about that. We were able to mute everything when Jeffrey speaks. Also, the video should start at about the 15-minute mark. Everything before that is just some typical User Group meeting stuff.
This issue seems to have popped up a couple times over the past couple weeks so I figure I would capture the resolution here in the event someone stumbles onto this post and it's able to help them. Security is rarely convenient and this is an example of that.
CentOS machine running current on patches and running a current version of PHP, let's say PHP 5.3 or higher. PHP script is able to sent email from the command line, but when trying to send an email with PHP through the web browser it fails. Actually it doesn't "fail" it just doesn't seem to ever send.
SELinux is running on the machine and is preventing the Apache process to send out emails. There are a couple approaches you can take for this. To quickly test and confirm that the problem is in fact SELinux, and not something else, you can temporarily disable SELinux.
First verify SELinux is running with the command (as root) getenforce
Next, if SELinux is running you can disable with the command, again as root, setenforce Permissive
SELinux with be disable until you reboot the machine or enable it with setenforce Enforcing. You can permanently disable SELinux is you so desire editing the file /etc/sysconfig/selinux and changing the setting SELINUX=
Test your PHP Mail functionality now from the web application. If it works then you need to have SELinux allow the apache process to send emails. In order to do this, run the commands
setsebool -P httpd_can_sendmail 1
setsebool -P httpd_can_network_connect 1
You should now be able to re-enable SELinux and successfully send emails from your application in the browser.
A little while back I did a lightning talk at one of our SDPHP MeetUps on Composer. Composer is a fantastic tool and one that will change the way you approach PHP development. Using and managing external packages on a per project level has never been so easy in the PHP world.
I kept forgetting to publish my slides so for what it's worth, here they are.
If your organization has written off PHP from being a possible solution to its development needs, you may want to rethink that decision. PHP is making a strong comeback and with developers who have years of experience under their belt, a language that has matured with the Internet it helps run, and now new features, stronger communities, and interoperability high on everyone's priority list, PHP is once again a great solution for any development need.