I’ve been using git and GitHub in my workflow for a while now and the only thing that has bothered me about the process is that every time I want to deploy a new version of the site I have to push it to GitHub and then SSH into the server and manually do a
git pull. Needless to say it’s a giant hassle.
What I really wanted was a way to just push the commits to GitHub and then have the server automatically pull the updates. Initially, I thought I would just write a crontab script that would do a pull every couple minutes but I knew there had to be a better way. It turns out with GitHub’s Service Hooks we can do exactly that. Continue reading
I was working on a client’s website and they wanted to have the color of each of the labels for a group of radio buttons be a different color. If you use
$form->setAttrib('class', 'className') it will set the class for the form element but not for the label. It turns out you need to use
$form->setAttrib('label_class', 'className') and then it will the way you anticipate.
I found this article while looking through the Programmer Reference for Zend Framework 2 on running ZF1 and ZF2 in the same project.
We’re very slowly porting a large application from an old system (no MVC framework) into ZF 1. The process is similar but we actually have ZF encapsulating the legacy files so we can use the ZF1 classes in the old code as we convert it. I think after that transition is done we’ll start worrying about ZF2.
Awesome site wide license from CSS-Tricks.
I think this section really embodies what my goals on TPT are:
I don’t give two hoots what you do with any of the design or code you find here.
Actually, I do. I hope you take it and use it, uncredited, on a super commercial website and get wicked rich off it. I hope you use it at work and your boss is impressed and you get a big promotion. I hope it helps you design a website and that website impresses somebody you think is super hot and you get married and have smart, chill babies. I hope you use the code in a blog post you write elsewhere and that website gets way more popular and awesome than this one.
If you copy an entire article from this site and republish it on your own site like you wrote it, that’s a little uncool.
Since I started using Vagrant I noticed that I’ve been having problems with not having enough free disk space. This is mostly my fault because my primary hard disk is running low and I haven’t taken the time to clean everything out and reinstall the operating system. When I tracked down my usage, I found that several gigs (I know it’s almost nothing but not when you have less then 500 MB free) was being used by VMs created by Vagrant. After some Google searches I found that Vagrant stores the VM files in the default location used by VirtualBox. Below are the instructions for changing this directory.
Open the preferences
In the “General” tab click the drop down for the “Default Machine Folder” and click “Other…”
Browse to the directory you want the VMs to be in and select it.
You’re done. When Vagrant creates a new VM it will automatically be put in this directory.
An excellent article that explains password security and how we should be storing passwords in the database.
http://threetwelvecreative.com/blog/bid/266517/Developers-You-re-Probably-Doing-Passwords-Wrong-Too via reddit
The only thing I would add (and I did in the comments) is that as an added layer of security you can add a site wide salt that is stored in a file. Even if an attacker gets your database, they realize that you’re salting your passwords, and they do a brute force lookup they will still be missing information and won’t be able to determine the passwords.
I agree with the concept but I disagree with the implementation. I think this problem is best solved using PHP’s header function:
header('Content-disposition: attachment; filename="' . $filename . '"');
Hopefully we can use the download attribute in a couple years when the rest of the browsers get caught up.
In all of my Zend Framework applications that have user logins I like to display if the user is logged in and provide a link to login or logout depending on their current state. In Zend Framework 1 it was easy, I would define a function that would get called at the start of every action (
_initView()) and then it would be easy to set any variables that needed to be set on every page.
$this->view->currentUser = Application_Model_User::getCurrent();
Then in the layout.phtml file you can easily access the variable like so.
In Zend Framework 2 it isn’t as easy.
Nettuts has a nice article that explains PSR-1, PSR-2, and PSR-3. I’m going to do my best to start using these coding standard going forward and I recommend you do the same.
Ideally, we should all be developing our code in our own little space on our little local server. This allows us to easily make changes without messing up production code or stepping over other’s work. This is usually cost prohibitive so we use virtual machines to make this a reality.
The problem we face is that each developer needs to have a virtual machine that is setup exactly (or nearly exactly) like our production server. This requires a long list of configuration changes that need to be made on every machine. For example, install the apache package, update this configuration file, setup Samba so you can access the files remotely. Then we run into more problems when additional changes are needed because the developer has to take time out of their schedule to make them on each machine. There are also passwords that have to be remembered and /etc/host changes that need to be made. You’ll be in even worse shape if the deployment consists of multiple VMs. Continue reading