Use consultants, but don't rely on them. They are great people who deserve a lot of respect. Since they can see a lot of different projects, they often know more about specific technologies and even programming techniques than you do. The best way to use them is as internal educators who can teach php development by example.
However, they usually can't be a part of the team the same way regular employees do, if only because you may not have enough time to learn their strengths and weaknesses. Their financial commitment is much lower. They can be more easily mobile. They may have less to gain if the business is successful. Some will be good, some decent and some mediocre, but unfortunately your selection of consultants will not be as neat as your selection of employees, so you end up with poorer ones.
If consultants are called upon to write code, you should reread it carefully as you go. You can't come to the end of a project with the risk of a big chunk of code that hasn't been proofread. This is true for everyone on the team, actually, but you will generally have more knowledge about the team members closest to you.
How to communicate in the right way
Take a close look at the cost of a meeting; it costs its duration multiplied by the number of participants. Sometimes meetings are necessary, but shorter meetings are preferable. The quality of communication in small meetings is better, and less time is wasted. If someone is bored in a meeting, take that as a sign that the meeting should be shorter.
Everything must be done to encourage informal communication. More useful work is done during lunches with colleagues than at any other time. It's a shame that there aren't more companies that recognize or support this fact.