Joomla Debugging.

I've gotten by without needing a real debugger for Joomla extension development, up until now, when I'm upgrading some extensions from V2,x to V3 conventions.  I've got a background in serious debugging (assembly, real time and networking, C++) but just never really needed more than I could get by with using JDump and other means of logging and debugging.

So, two days ago, I took what seemed to be the natural jump, installing Eclipse and LAMP with XDebug on a spare UBuntu machine.  After a day and a half , I managed to get a limping project to semi-reliably breakpoint in index.php, but then couldn't figure out what to do next.  And oh, why does Eclipse have to be quite so heavy in getting a working configuration without hiring an expert to set it up?

Dismayed about facing another day or so to get to the problem I'm currently trying to debug, I decided to give Netbeans a quick look.  I made one small false start, using UBuntu apt-get install netbeans, which installs V7 of the IDE which only supports up to V5.3 PHP (as of November 2014).  But that was just a 20 minute mistake, easily resolved by uninstalling and then using the Netbeans direct package download of the PHP-HTML version of the Netbeans package 8.x.  Ten minutes later, PHP plugin installed and a package created out of the joomla install directory.  Another 5 minutes to get into the debugger in index.php (had to figure out how to configure the port, added 3 minutes).  And lo, I could step out into other files, without figuring out anything else like setting up an ant build to create the information required for cross file debugging.  Another 5 minutes to learn how to get into my component's back end.

I don't know if in the long run I could do more with Eclipse, but given that I'm pretty attached to Dreamweaver and usually don't need serious debugging,  I give Netbeans / PHP / XDebug a gold star for the day, and assume tomorrow, I'll be able to figure out the problem that I couldn't resolve without a debugger, with little or no further futzing around to figure out how to get to HELLO, WORLD, WTF?  Good night!

Charlie

Subtle Patterns

While revamping our several year old website, I needed to find textures for backgrounds, and came across Subtle Patterns.  They provide royalty free textures, though the license requires a credit for commercial use. Here's ours!  Thanks,Atle!

Google Calendar API V3 php error exception handing

Google's V3 api doesn't have a lot of documentation, which makes a number of things you might want to do with the API either difficult or error prone.  ( Actually, it has a TON of documentation, just not enough in the right places with a good enough search engine to help you find it ... )

If you can get past the OAUTH2 hurdle and implement some of the simple event list / fetch / update functions from the php examples documentation, you probably won't have any error handling.  The code will work as long as you don't have any errors, but when you include that code in your websites, eventually your users will see the friendly  red box error screen with a cryptic message, such as a POST error 404, instead of your web page.

The problem is that the Google API uses exceptions, but the examples don't include exception handling or any easy to find documentation that says 'a simple calendar operation has to include exception handling for a user friendly website'.

So, where you see an example like the following:

$event = $service->events->get('primary', 'eventId');

$event->setSummary('Appointment at Somewhere');

$updatedEvent = $service->events->update('primary', $event->getId(), $event);

You need to add exception handling on each of the Google API calls, or if you don't want to learn the API's and figure out what types of exception each call may throw, just put an error catcher around the whole block, something like so:

try {
   $event = $service->events->get('primary', 'eventId');

   $event->setSummary('Appointment at Somewhere');

   $updated = $service->events->update('primary', $event->getId(), $event);
} catch(Exception $e) {
     // Do something with the error here
}

The calendar API can throw several types of exception, named Google_ServiceException, Google_AuthException, Google_IOException, Google_CacheException. Exceptions are thrown for any errors, including passing a bad event ID, having problems with internet connections, or various other things that happen often enough to turn your wonderful website into a terrible user experience.


Now that you know how to avoid the red screen of death experience for your user's, you can take it from here to decide exactly what to do with any particular exception. Cheers!

Securing your FTP transfers on a CPanel shared hosting site

If you use FTP to transfer files to your website, the user ID and password for the FTP account are transmitted in plain text.  Anyone snooping on your internet connection may be able to capture your login credentials, and from there they can gain control over your account.  They could also see any files you're transferring to or from the web server.

It is much better to use a secure encrypted connection for any access you make to copy files to your web server.  Many web hosts let you do that with a secure shell (SSH) , but some shared web hosts do not provide SSH access or secure FTP connections.

On CPanel, you normally connect to FTP on port 21, which is the default port for FTP.  However, some CPanel hosts  also allow secure ftp connections on a different port - port 7211.  I don't know where I found this, searching for it now I can't find it, but if you've got a CPanel hosting provider that does not otherwise provide a way to make a secure connection, it is worth trying SFTP to port 7211.

If you're using Dreamweaver, you can select the port by adding it to the end of the site URL.  So if your website URL is www.mysite.com  you would enter www.mysite.com:7211 as the FTP host, and check the SFTP checkbox.

Another CPanel option allows using a TLS connection for FTP access, as well as allowing full SSH over port 21, but those need to be configured for the server to allow those connections.  You can ask your provider if they support either option on your account, and if they don't, try the port 7211 connection for SFTP.  If you try to SSH to that port, you'll probably get a message that SSH connections are not supported, but SFTP might work.

While you're thinking about secure connections, you probably also should be logging in to CPanel using the secure option as well - for the same reason, anyone able to snoop your connection can hijack your website, and that might well be at least one more hacker than you want to give access to your website.  Most CPanel websites allow access to the secure control panel login by using mywebsite.com/securecontrolpanel .  You can do the same thing using port 2083:  mysite.com:2083 should bring you to an https: connection to the CPanel login.