Setup PHP Dev Environment on Mac OS X Sierra – Apache, MySQL & PHPMyAdmin

Getting the development environment right at the start is vitally important to productive application development. Here we will setup a flexible “LAMP” development environment on the latest Mac Os X, El Capitan. We will focus on keeping the development platform flexible and stable, centrally managing all system & application dependencies. Within a few minutes, we will hopefully have advanced PHP web applications serving up pages, but with the ability to integrate extra system components specific to your application.

System (optional)

Apple’s native development IDE is XCode, it’s not great for PHP but provides handy tools and installing it kind of tells Apple your computer’s being used for software development and to unlock related features. If you’re starting on a completely fresh system, it’s a good idea to install Apple’s Xcode tools. Open up the Terminal App, e.g. cmd + space then: terminal  and type:

sudo xcode-select --install
sudo xcodebuild -license

You will have to agree to some terms & conditions but prevents later problems using common tools like Git.

Install Apache and PHP7 (or other versions)

Install the amazing and free open-source Homebrew  package management system which will make open-source software development far more manageable. If you’re not yet convinced by Homebrew, check out its popularity on GitHub. Install Homebrew as such:

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

As of writing, the most recent version of PHP is 7.0, although Mac already has PHP and Apache inbuilt, we will install it using Homebrew to better manage all development services & dependencies – they’ll be all in one place, managed using a standard set of commands. Allowing us to easily upgrade & downgrade PHP, also since Apache (the web server / engine) keeps changing between MacOS releases, we will use Homebrew to manage and keep it consistent.

Fist stop the default Apache service, in the terminal type:

 sudo apachectl stop
 sudo launchctl unload -w /System/Library/LaunchDaemons/org.apache.httpd.plist 2>/dev/null
 brew install httpd24 --with-privileged-ports
 brew install php71
[short wait to download files]
 brew services start homebrew/apache/httpd24

This should take a minute or less and Homebrew is usually really good at providing helpful and clean output info, errors and ways to fix them. For example, it may give you info about where the php.ini file is, (e.g. /usr/local/etc/php/7.0/php.ini ) or suggest the following command to automatically start PHP7 at login:

 brew services start homebrew/php/php70

As mentioned, helpful and clean output info is one of Homebrew’s real strong points, always read what it outputs!

Verify PHP7 installation (optional)

These are a few really useful commands to check everything is working, or diagnose any problems:

Format:   command
                     output

    php -v

PHP 7.0.8 (cli) (built: Jun 23 2016 16:32:40) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies

    which php
/usr/local/bin/php

    ls -l /usr/local/bin/php
lrwxr-xr-x  1 maltronic  admin  36 30 Aug 19:20 /usr/local/bin/php -> /usr/local/Cellar/php70/7.0.8/bin/php

     php -i | grep php.ini
Configuration File (php.ini) Path => /usr/local/etc/php/7.0
Loaded Configuration File => /usr/local/etc/php/7.0/php.ini

If for any reason there’s a problem you can manually point php to the desired version. First, check what Kegs are have installed in your Cellar using:

brew list

If no version of php appears, try “tapping” homebrew to enable it to pick up more software kegs then installing php7 like so:

brew tap homebrew/dupes
brew tap homebrew/versions
brew tap homebrew/homebrew-php
brew install php70

You can link to whichever installed PHP version you like, say you wanted to use PHP 5.6 (and have installed it using brew install php56 then create a symbolic link to /usr/local/bin/php:

ln -s /usr/local/Cellar/php56/5.6.23/bin/php /usr/local/bin/php

Enable Debugging (optional)

Stop haphazardly print variables to the screen and become a real pro developer, use debugging! It’s so easy and better for fixing bugs. To install Xdebug and enable IDE debugging using popular IDEs like Netbeans and PHPStorm, install with homebrew:

brew install php70-xdebug

Install MySQL

Although MariaDB is slowly replacing MySQL in open source circles, either can be installed, as such:

brew install mysql

Just replace “mysql” with “mariadb” (for rest of article). The Homebrew MySQL/MariaDB server should now be running, this can be verified with:

brew services list

Typing just brew services lists the Homebrew’s service manager commands. If mysql isn’t already running, type brew services start mysql

Configure Apache

We will keep on using the preinstalled Apache server but edit the Apache config file to enable the PHP7 module. Use Mac’s inbuilt nano editor or another text editor (like Sublime Text):

sudo nano /etc/apache2/httpd.conf

Add the following line:

  LoadModule php7_module /usr/local/opt/php70/libexec/apache2/libphp7.so

Press ctrl + x to quit.

Now, every site we add will be a new VirtualHost in Apache, one of potentially many web applications running on your computer. Whilst you can edit the /etc/hosts file to enable local domain names, a quick and reliable technique is to use different ports to distinguish websites. First, make sure Apache is checking for Virtual Hosts and that there’s no # commenting out the file:

sudo nano /etc/apache2/httpd.conf

Go right to the bottom of the file (ctrl + v is PAGE DOWN) and ensure the following line does not have a # infront, it should look like the middle line below:

...

Include /private/etc/apache2/other/*.conf

...
(i.e. no #, although the * is ok)


Now edit Apache’s VirtualHost config file, using the nano editor command:

sudo nano /etc/apache2/extra/httpd-vhosts.conf

And add a VirtualHost config for your website:

Listen 81

DocumentRoot "/Users/maltronic/my_php_project/web"
ServerName "local.my_php_project"
ErrorLog "/var/log/apache2/my_php_project-error.log"



Options Indexes FollowSymLinks
AllowOverride All
Require all granted

Where the directory (“web” above) is the base directory that will appear on your website (i.e. where index.php or an equivalent would sit).

Now, finally, we restart the Apache server to apply our changes:

sudo apachectl restart

Some errors may appear (especially in regards to domain names), these generally don’t matter although if there’s an obvious problem stated you should fix it and re-run the restart command.

Install PHPMyAdmin

As usual, install PHPMyAdmin using Homebrew:

brew install phpmyadmin

And as usual, Homebrew will give some info on any final steps, which in my case means:

sudo nano /etc/apache2/httpd.conf

Then adding to the bottom of the file (ctrl + v is page down in nano):

Alias /phpmyadmin /usr/local/share/phpmyadmin

Options Indexes FollowSymLinks MultiViews
AllowOverride All

Require all granted


Order allow,deny
Allow from all

Install Composer (optional)

Composer is a near universally adopted PHP package manager that enables your PHP applications to use 3rd party libraries and manage their dependencies (very similar to Homebrew but for your PHP application (on any OS), rather than Mac Operating System).

It’s not needed yet, but most professional and open-source projects use it. For consistency let’s install it using Homebrew:

brew install composer

As usual, look at the screen output for any errors and info.

That’s It

Try loading PHPMyAdmin in a web browser at:

http://localhost/phpmyadmin

By default the MySQL admin user is: root (with no password).

You now have a fully functioning and extremely flexible LAMP development environment. From here you can easily add additional services like Redis, Memcache, RabbitMQ, other databases and whatever else you would like to use in your project


This guide gets updated based on reader comments. Any problems, please comment below or share on social media if you found this guide useful!

Advertisements

PyCharm Auto-import works differently to PHPStorm and IntelliJ

Having become used to developing in JetBrain’s PHPStorm & IntellliJ IDEs it nows seems tedious to break out of the programming flow to manually type out imports every time we introduce a new dependency.

However in that company’s Python IDE, PyCharm, auto-complete works differently. The:

  [ctrl] + [space]

keyboard shortcut still auto-suggests but doesn’t include non-imported classes, but the

  [ctrl] + [alt] + [space]

keyboard shortcut does! Displaying all available classes and auto-generating the import statement for you, just like in JetBrains other IDEs.

Different versions of shell commands like PHP, Vi – find the true location of Mac/Unix commands, aliases and links

Sometimes it can be a challenge to uncover what terminal command is actually being run on Mac / Unix / Linux systems. Over time, old aliases, links and the repeated installation, upgrading and removal of software can lead to existing and even untouched default commands either unable to be found or running a different version than expected.

Recently we have been using Homebrew to swap in and out multiple versions of PHP (5.4, 5.6, 7.1 etc.) on Macs. Whilst great for quickly testing and developing across versions, this makes it possible to have strange occurrences, like the $ which [command] returning a different version of the software to the one which the shell actually executes!

The following location mismatch demonstrates the problem:

# Problem: Command or Software (in this case php)
# Reported as missing or runs at different location


$ php -v
-bash: /usr/local/bin/php: No such file or directory


$ which php
/usr/bin/php


# WTF ???

Different locations are being referenced by $ which [command]  and the shell.

To fix the discrepancy, use the $ hash [command] to refresh the shell’s command location cache:

# Result before hash command
$ command -v
php /usr/local/bin/php

$ hash php
$

# Result after command
$ command -v php
/usr/bin/php

# Same version recognized everywhere
$ which php
/usr/bin/php

$ php -v
PHP 5.5.36 (cli) (built: May 29 2016 01:07:06)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2015 Zend Technologies

Great, order has returned to the universe and which is again pointing at the correct place. Keep in mind if you do replace (or re-link) the php at /usr/local/bin/php it will be executed instead of the /usr/bin/php, but now all commands should agree on the file’s location.

Debugging Aliases

The above situation can be particularly tricky when dealing with aliases.

If we define an alias and confirm it can be executed, the $ which [alias] and ls commands bizarrely return nothing! Where is the alias going? To find where and what the alias is actually running, utilise the $ type -a [command] command:

# Create alias and watch the confusing behavior
$ alias phpv='php -v'
phpv
PHP 5.5.36 (cli) (built: May 29 2016 01:07:06)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2015 Zend Technologies


$ which phpv
$


$ ls -l phpv
ls: phpv: No such file or directory


# The type command reveals all (-a)
$ type -a phpv
phpv is aliased to `php -v'

Debugging Links

Links act slightly different again. As discovered in this blog post, vi links to vim on a mac, however the which, type -a and command -v commands only shows the link name, not the target:

# These commands give information on links (ls -l is most useful)

$ which vi
/usr/bin/vi

$ type -a vi
vi is /usr/bin/vi

$ command -v vi
/usr/bin/vi

$ ls -l /usr/bin/vi
lrwxr-xr-x 1 root wheel 3 21 Aug 15:29 /usr/bin/vi -> vim

Here we can see that although ls -l was useless for aliases and commands, it is good for showing where links point to.

Although only a summary, these quick commands give a few pointers for when a command either cannot be found or a different version than expected is executing. If you’re still struggling to locate an executed command or know of other handy tips, please leave a comment.

Please share if you find our free website useful, it really helps us produce more tutorials!

When mocking a method in PHPUnit produces a “cannot be configured” error

When mocking an object in PHPUnit testing, if you receive the following error even when the function name  is correct. For example, if mocking non-custom Doctrine Repositories (i.e. no SomeEntityRepository class) will cause:

Error:
Trying to configure method “getUser” which cannot be configured because it does not exist, has not been specified, is final, or is static

This occurs on a PHPUnit_Framework_MockObject_MockObject object when using the PHPUnit_Framework_TestCase and PHPUnit_Framework_MockObject_MockBuilder.

In the case of mocking Doctrine find calls, often this error means $methodName parameter in the getMockBuilder($methodName) function is incorrect. For example the following code is incorrect:

// Produces error
$itemRepoMock = $this
  ->getMockBuilder('AppBundle\Entities\ItemRepository')
  ->method('find')
  ->disableOriginalConstructor()
  ->getMock();
$itemRepoMock
  ->expects($this->any())
  ->method('find')
  ->will($this->returnValue($itemMock));

Here you need to specify Doctrine’s base EntityRepository class instead, so:
AppBundle\Entities\ItemRepository
becomes
Doctrine\ORM\EntityRepository
The same example:

// Fixed
$itemRepoMock = $this
  ->getMockBuilder('Doctrine\ORM\EntityRepository')
  ->method('find')
  ->disableOriginalConstructor()
  ->getMock();
$itemRepoMock
  ->expects($this->any())
  ->method('find')
  ->will($this->returnValue($itemMock));

As a defined ItemRepository does not exist, neither dies its find function, even though you can usually use the inferred name.

Fix a Git Commit Message Typo

If after quickly typing in a commit you notice a typo, as such:

git commit -m "this is splet wrong"

You can quickly fix this using Git’s --amend flag, as such:

  1. Type: git commit --amend
  2. By default, the vi editor is opened. press a to enter INSERT mode and make changes
  3. Press ESC to leave INSERT mode and save by typing :wq (write and quit), if you accidently made everything 10x worse, you can cancel by typing :q! (quit, ignoring changes)
  4. Your commit now has an updated commit message and you can push as normal

No more embarrassing errors highlighting non-compliance with the absurd and illogical English (or other) written language.

Doctrine findBy and findOneBy Argument 2 passed must be an instance of […], none given

Argument 2 passed to AppBundle\Entities\WrappingPaperRepository::findWrapperInfoForProduct() must be an instance ofAppBundle\Entities\Product, none given, called in .. .php

This error sometimes occurs when converting a “findBy” call located outside the Repository into a named repository function. Whilst you can of course make repo custom function arguments also use arrays of parameters, often when writing a quick database lookup this is too much hassle and we just specify them like so:

  //Repository File
  function findInfoForProduct(Product $product) {
    // ..custom logic
  }

But this is different to how Doctrine’s findBy and findOneBy functions work – above we provide a single parameter of type product – they take an array of parameters as such:

  //Repository File
  $em->getRepository('AppBundle\Entities\Product')->findBy(['product' => $product]);

Remove the “array(” or “[” characters from your repository function call and your data retrieval service will work fine, or at least get you a bit further towards the next issue!

Doctrine convention adherence leads to much simpler entity classes, no picky join column specification. A standard bi-directional one-to-many join becomes simply:

<?php
use Doctrine\Common\Collections\ArrayCollection;

/** @Entity **/
class Product
{
    /**
     * @OneToMany(targetEntity="Feature", mappedBy="product")
     **/
    private $features;

    public function __construct() {
        $this->features = new ArrayCollection();
    }
}

/** @Entity **/
class Feature
{
    /**
     * @ManyToOne(targetEntity="Product", inversedBy="features")
     **/
    private $product;
}

Nice and straight forward.

Of course, if you do want to specify the join column manually, it would be:

/** @Entity **/
class Feature
{
    /**
     * @ManyToOne(targetEntity="Product", inversedBy="features")
     * @ORM\JoinColumn(name="product_id", referencedColumnName="id")
     **/
    private $product;
}

The getters & setters can be auto-generated with the following calls from the server’s command line:

app/console doctrine:generate:entities AppBundle:Product
app/console doctrine:generate:entities AppBundle:Feature

Alternatively, modern IDE tools like PHPStorm can also generate the standard for you. Chaining is a great feature to encourage on setter methods, simply return $this after setting an entity property.