Ubuntu 16.04 and PHP 7 not rendering

After reloading my working laptop with Ubuntu 16.04 LTS (I prefer to do a reload versus an upgrade, for each LTS version) I was very excited to install PHP 7, and installed Apache2 and PHP7 using the standard Ubuntu repositories. I used the typical commands:

$ sudo apt-get install apache2
$ sudo apt-get install php7.0

However, after doing the installs I discovered the PHP scripts would not render in a browser. After a small amount of digging I realized that doing the installs did not include one important piece. The package ‘libapache2-mod-php7.0’ was not automatically installed as expected, and as it did in the past. (I don’t remember needing to install it separately in the past.)

$ sudo apt-get install libapache2-mod-php7.0

So one quick install like shown previous and all is working fine.

Happy PHP’ing.

Using an SSH tunnel to step debug through a firewall

In a previous post I covered how to set up step debugging in Zend Studio. But if that doesn’t work there may be a firewall in between the server and the debugging client, or IDE, preventing the connection. Here is a possible way to get around that.

Note: Of course there is no way to avoid the firewall, but this post assumes a connection to the server using SSH is possible. What we’ll do is allow communications from the server to the client using the Zend Studio default debugging port (10137) forwarded through an SSH tunnel which uses port 22 by default. For this to work an SSH connection must be possible from the client to the server.

While it is possible to do this using command line from Linux or Mac, or using PuTTY on Windows, this example will use the built-in SSH capabilities of Zend Studio 13. For older versions of Zend Studio I recommend using command line or PuTTY linked above.

Assuming step debugging in Zend Studio was already set up as outlined in my previous post we will continue using that setup, but enhance it with an SSH tunnel.

In Zend Studio open the preferences. (Windows|Preferences) With the preferences open, expand the PHP node to get to Servers. Highlight the server configuration to work with, and click Edit.

Screenshot from 2016-04-18 15:07:40

When the Edit Server dialog opens select the SSH Tunneling tab. Check the box to Enable SSH Tunneling, and populate the desired Username and Password. If your server requires the use of an SSH Private Key in order to login, please supply that.

Screenshot from 2016-04-18 14:41:34

Now that the SSH connection is set up we need to add the Port Forwarding for the debugging port. Do this by clicking the Add button in the Port Forwarding section.

Screenshot from 2016-04-18 14:43:45

Select ‘remote’ to specify which side of the tunnel will be sending communication on the forwarded port, enter the local address the remote side (server) will use and port number to send to. Then enter the port number on the receiving end (the client). Now click Finish to apply the setup, and click finish to exit the preferences.

In the PHP Servers view (Windows|Show View|PHP Servers) right-click the server we just added SSH Tunneling support to and select Open SSH Tunnel. You should then see a brief dialog letting you know the connection was made.

Screenshot from 2016-04-18 14:52:41

We are ready to debug!

Since I was using Zend Server in this example I have Z-Ray available, and while on a page I wished to debug I could simply click on the debug icon and select any of the debugging options.

Screenshot from 2016-04-03 15:24:13

This will cause Zend Debugger to contact Zend Studio for debugging, which in turn will ask the user if they wish to open the debugging perspective.

IMPORTANT NOTE: Debugging over an SSH tunnel is not fast. Therefore you may notice a lag between initiating the debug session and your IDE reacting. After that things speed up, but the initial connection is slow on many networks.

Screenshot from 2016-04-03 15:24:44

If Yes is selected the IDE is now ready to perform any debugging the user desires.

Screenshot from 2016-04-03 15:27:24

Happy debugging!!!

This post is one in a series on debugging. For others click below:

PHPStorm and debugging issue
Setting up step debugging in Zend Studio

Setting up step debugging in Zend Studio

Recently I was helping someone set up step debugging in Zend Studio, and had some difficulties. Therefore I decided to create a blog post to remind me later, and perhaps help others get it set up.

I was doing this on an Ubuntu laptop, so while menus may vary slightly the process should be very similar. Also, I did this using a local virtual machine in VirtualBox, but using Bridged networking mode to simulate a remote server. In Zend Studio I had a project created with the Zend Framework Skeleton Application, and created a virtualhost in the virtual environment that mirrored that.

NOTE: If the desire is to use a local server the setup is similar.

Server setup

While this post doesn’t cover how to install Zend Debugger or Xdebug, ensure these are set up correctly. Also, ensure the debugger of choice “knows” where to find the IDE to be debugging from. Zend Debugger can try to do this automatically, or an IP can be manually specified with Xdebug. Also, if using Zend Debugger ensure the IP of the client is added to the whitelist. More on how to verify this IP from the client later.

Aiming at the server

The first step is to add a server to a Zend Studio project configuration. Do this in the preferences. (Windows|Preferences)  With the preferences open, expand the PHP node to get to Servers.

Screenshot from 2016-04-03 15:17:07

From there click “New”, and follow the wizard for setup. The first step is to specify the type of server. In my case I was using an install of Zend Debugger that comes with Zend Server, so selected Remote Zend Server. Alternatively I could have easily selected Generic PHP Server and arrived to the same endpoint later.

Screenshot from 2016-04-03 15:17:47

Next, after giving this server a name and URL (ensure the URL actually hits the server), I am prompted for the Zend Server login credentials to gain access to the Zend Server Web API.

Screenshot from 2016-04-03 15:19:09

Entering the user and password authorizes Zend Studio to pull down an API key for interacting directly with Zend Server if I desired to later. (This creates a new API Key on the server specifically for this client.) Alternatively it is possible to click Cancel and enter the credentials manually.

Again, this is not really required for simply debugging, but I’m including it for completeness sake.

Screenshot from 2016-04-08 09:25:43

At this point a test can be ran to ensure we are hitting the server as expected by clicking the Test button.

NOTE: If this doesn’t end in a success you may have some network issues to overcome. See my post on using an SSH Tunnel if you need to.

Screenshot from 2016-04-03 15:20:12

After a success click OK and then Finish the wizard. If you had troubles, please see my post for using an SSH tunnel.

Enable debugging for the project

With the server set up it is now possible to set up debugging for the Zend Studio project.

In the Preferences (Windows|Preferences) click on the Debug within the PHP node.

Screenshot from 2016-04-03 15:21:16

Though it is possible to specify the PHP Server globally from the resulting option screen I prefer to set up preferences for each project, since most of them are different in any way. So I click Configure Project Specific Settings… and am prompted to specify which project I desire to configure.

Screenshot from 2016-04-03 15:21:57

After selecting the appropriate project I can then appoint the server I just added above, and then specify the Base Path and ensure the Auto-generated Base URL is correct in the lower section.

Screenshot from 2016-04-03 15:22:26

After approving and closing the Preferences, we are ready to debug!!!

Test: If the following step doesn’t work it may be because the debugger on the server cannot find the IDE. In a browser check what ports the IDE is listening on by entering the following URL to hit Zend Studio’s built in web server.

Screenshot from 2016-04-08 09:48:52

If the debug_host doesn’t show an IP address reachable by the server then it may be necessary to manually specify the IP in Zend Studio by altering the server configuration we created previously.

If the IP address should be reachable by the server the issue may be in the configuration on the servers end, or perhaps a firewall or load balancer in between is limiting. Please see my post on how to get around this with an SSH tunnel.

Since I was using Zend Server in this example I have Z-Ray available, and while on a page I wished to debug I could simply click on the debug icon and select any of the debugging options.

Screenshot from 2016-04-03 15:24:13

This will cause Zend Debugger to contact Zend Studio for debugging, which in turn will ask the user if they wish to open the debugging perspective.

Screenshot from 2016-04-03 15:24:44

If Yes is selected the IDE is now ready to perform any debugging the user desires.

Screenshot from 2016-04-03 15:27:24

I hope this helps others. Happy debugging!!!

This post is one in a series on debugging. For others click below:

PHPStorm and debugging issue
Using an SSH tunnel to step debug through a firewall

PHPStorm and debugging IP issue

Recently I was helping someone troubleshoot an issue using PHPStorm and Zend Debugger. In this case Zend Studio was able to debug an application using Zend Debugger while PHPStorm was failing unless an SSH tunnel was used. The error received was:

Host ‘127.0.1.1’ is not allowed to open debug sessions – please configure zend_debugger.allow_hosts in the ini file.Failed to connect to host ‘127.0.0.1’, reason: ‘Connection refused’.

The person experiencing this issue was attempting to debug a site in a VirtualBox virtual machine from the host machine. Both the host machine and the virtual machine were running Ubuntu 14.04. At first glance I thought adding 127.0.1.1 to the allowed hosts would do it. But turns out it was more than that.

In this case we knew there was not a firewall blocking access, so it had to be networking.

To start things off I wanted to take a look at what PHPStorm was listening to, so I used the broadcast port 20080 to see this in a browser:

Screenshot from 2016-04-04 16:13:09

So it appears PHPStorm was attempting to use the IP addresses linked to the host systems ‘localhost’ and ‘hostname’, but not an IP address accessible via the network. This meant the server would never be able to send information back to the IDE without the use of an SSH tunnel, because it could not reach 127.0.1.1 or 127.0.0.1 of the host.

Unfortunately PHPStorm doesn’t provide a way to alter the listening IP addresses in the preferences, so we were left with either using an SSH tunnel to allow port forwarding of the listening port (10137) back to the host, or manually informing Zend Debugger where the IDE would be located.

Zend Debugger Tweak

By default Zend Debugger will automatically attempt to detect the IDE settings, as shown below:

Screenshot from 2016-04-04 16:23:04

However, this wasn’t working because PHPStorm was not reporting a usable IP address, so we needed to update the settings manually:

Screenshot from 2016-04-04 16:22:37

NOTE: Checking the box “Use browser’s IP Address” did not fix the issue. The IP address needed to be entered.

With this done, the server now knew where to reach the IDE for debugging sessions. One downside to this is if the host machines IP address changes, this setting will need to be updated.

This post is one in a series on debugging. For others click below:

Setting up step debugging in Zend Studio
Using an SSH tunnel to step debug through a firewall

Edit: Please head out to the PHPStorm ticket system and +1 this fix to make this a thing of the past. https://youtrack.jetbrains.com/issue/WI-7465

SunshinePHP 2016 Recap

The Good

SunshinePHP 2016 was an awesome event! Not only were we sold out of tickets for the 4th year in a row, but the attendee list was truly amazing! Each year more and more companies in South Florida send most if not all of their PHP developers to the conference. This year we saw at least 20 companies in South Florida send 5 or more of their developers, and around 8 of those sent around 10. We love seeing our work take hold, and with this many companies embracing the conference it is obvious we are doing a good job. Thanks to all for participating.

SunshinePHP CrowdsThis year we had 14 of our amazing 19 sponsors represented in the exhibitor area, handing out Lego pieces and speaking with developers about how they could help them enhance their careers in one way or another. We are happy that every sponsor raved about the event, attendees, the amount of contacts they made, and the overall organization of the conference.

SunshinePHP exhibitor areaAttendees told us they loved the Lego puzzle idea, and really enjoyed collecting the Legos from the sponsors.

We had some amazing talks and keynotes this year, and really pulled some topics that were outside the box we typically see at PHP conferences. Two talks were about the brain and mental functionality, and how rest and downtime can affect our thought processes and how we learn. There were talks about dealing with customers, and how to help them help us. The keynote speakers shared tips on collaboration and teamwork while sharing stories about Pacific Ocean crossing, and growing up with physical and/or mental disabilities.

Or course these off-the-wall, but very valuable, subjects joined our already mind blowing lineup of topics and speakers.

We also had a very gender diverse attendee and speaker lineup with 16 female speakers (or 36%) and around 20% female attendees! This is a step in a very positive direction, and SunshinePHP continues to lead the way through non-biased speaker selection and responsible marketing.

The menu each day was slightly altered from previous years, with some healthier choices. The quality of the food was another nice touch as the venue really stepped up to provide some tasty items.

Evening events went well with games and panel discussions about API building indoors, and an open bar with some food items outdoors on the pool patio. (Yes, it was nice and warm.)

SunshinePHP tasty food

Overall the event went amazingly well.

The Bad

We didn’t receive too many complaints in our feedback from the event. Some mentioned that the temperature in one room was a bit cold for awhile. Others mentioned that we could have added the technical levels of the talks on the printed schedule. (We had them on the site, but overlooked adding it to the printed materials.)

One complaint, which we loved, was that we made it very difficult to improve the event for next year. 😉

The Ugly

Yes, unfortunately there was some ugly. With the recent awareness of codes of conduct and with the increase in gender diversity there is bound to be more visibility as victims come forward rather than remaining hidden. (Because even though we didn’t hear about these incidences in the past, they were already happening.) We are relieved to report that each incident below was handled professionally, and to the satisfaction of the victims.

One report was about a male attendee offering 2 separate female attendees a private sampling of relaxation techniques in his room. And when the women refused the man did not continue or push. When the incidences was brought to the man as being inappropriate he apologized and said he meant well, and he would not do it again.

A second report was made about a man in the pool area, long after the conference had ended for the day, who approached the girlfriend of an attendee and flirtatiously claimed that she could do better than her current boyfriend. We recommended that the man retire to his room (to prevent an assault) and get some rest for the next day, which he did. Nothing further was said, and no additional actions were taken.

There was a third incident reported which took place before the conference actually started, but was reported after the conference ended. A male offered to take a female shopping some distance away from the venue. Allegedly, while they were shopping the man touched the woman in an inappropriate manner. Because of the lateness of the report there were no further actions.

In a fourth report, allegedly a woman was swimming with a group, long after the conference had ended for the day, and one of the men in the group touched her in an inappropriate manner. The following morning this was brought to our attention as a 3rd party story by someone who was not present. We spoke with the man, who remained in his room except for meals over the remainder of the conference.

And finally in a fifth incident, also reported by a woman but late into the following day, it was stated that a man in the pool area the night before was over-aggressively tugging on the straps of her swimsuit. The apologetic man was questioned and promised to refrain from such activities in the future. The woman said this was an acceptable outcome.

My desire, and the reason I am being open about these incidences is to help others. Other conferences need to be aware this happened, so they can also keep their attendees safe. And attendees need to know about these things so they can watch for it, report it early, and help keep each other safe. Because whether we admit it or not, these types of activities happen everywhere. If you organize an event or group, please do not fool yourself into thinking your event is immune.

Conclusion

While SunshinePHP was very organized, and was an awesome event, sometimes things can happen that are out of an organizer’s control. I feel the SunshinePHP staff did everything in their power to ensure the safety of our attendees. We are looking forward to next year.