wp-SwimTeam

There has been a lot of discussion on the wp-hackers mailing list about the upcomming 2.7 release of WordPress and the change to the Admin Menus.  I decided to load it up and see how it affected this plugin.  For the most part everything works the way it is supposed to.  I ran into a few oddities which were errors that weren’t obvious until I ran it with 2.7 but everthing worked as it is supposed to.

The big change is the location (left side bar) of the new admin menus and the change in terminology.  The change in terminology takes some getting used to.  We’ll see if it stays as it currently is in the development build or if it changes.  From the Admin perspective, the presentation is different but not markedly so.  From the user perspective, the Swim Team menu doesn’t show up and I am not sure why yet.

I committed a whole bunch of changes I had to make as a result of debugging the 2.7 presentation issues.  So far, all of the changes work as they should on 2.5.1, 2.6 and 2.6.1 as well.  Switching releases (2.6.1 and 2.7) and platforms (Windows and Linux) during development is proving to be a useful thing as it flushes out stuff earlier in the process.

As the Swim Team Dashboard menu has grown I have been thinking of changing how I present the various choices to both the Admin as well as a Subscriber.  While I have thought about it from time to time, I haven’t done anything about it.  I was recently looking for something in the WordPress plugin directory and found something called Lighter Menus.

Lighter Menus changes the Dashboard menus into a set of drop down menus.  It is very similar to Andy Staines’ Admin Dropdown Menus.  Unfortunately, Admin Dropdown Menus really changed with the WP 2.5 release and the author has subsequently stated he will no longer support it.  Lighter Menus looked like it might be a suitable replacement so I decided to give it a try.

I really liked the way Lighter Menus works except for one thing:  The custom Swim Team menu didn’t work right.  The URLs weren’t constructed correctly.  Bummer.  But I really liked the way it looked.  Was this the compelling event to fix the growing Swim Team menu?  The Swim Team menu was really unwieldy when using the standard Dashboard as well.

As I worked on phpHtmlLib I tested all of the examples and I kept coming back to the TabControlWidget thinking it might be a good solution for wp-SwimTeam.  The TabControlWidget is a CSS based solution which presents different content based on which tab is selected.

Earlier this week, I decided to try it and see if it would work.  The implementation turned out to be really simple and I was able to use all of individual page code almost verbatim.  I like this implementation much better and I think it is much, much easier to use.  This decision also let me clean up some of the code which had been duplicated between the Admin and User side and resulted in the elimination of a half a dozen PHP file.

Now that I have fixed the Google Maps problem, I have the demo site up an running at http://wp.winswim.com.  Feel free to register and play around.  In order to advanced things you’ll need to contact me so I can change your permissions.  The demo is hosted by WinSwim.

Last night I fixed the Google Maps problem by re-coding the way I was getting the data from Google.  I had been using a class called Phoogle but have eliminated it in favor of a direct AJAX solution using Google’s AJAX API.

Instead of embedding this new solution in the wp-SwimTeam plugin, I implemented as a widget in phpHtmlLib.  It works pretty well too!

I had another go-round with GoDaddy yesterday which resulted in another goofy e-mail.  I posted the fsockopen() example they had asked me to which timed out and GoDaddy responded with this:

Dear Mike,

I sincerely apologize for any confusion or frustration. You will need to specify the proxy in your coding. Applications that need to make outbound connections (port 443) will need to be made “proxy aware”. This will require additional coding to varying degrees, depending on the application. You will need to know the ip address and port of the proxy server in order to correctly modify your code. The ip of the proxy server is 64.202.165.130 and connections will be made on port 3128.

You will need to use this when coding with PHP:
curl_setopt ($ch, CURLOPT_HTTPPROXYTUNNEL, TRUE);
curl_setopt ($ch, CURLOPT_PROXYTYPE, CURLPROXY_HTTP);
curl_setopt ($ch, CURLOPT_PROXY, http://64.202.165.130:3128);
curl_setopt ($ch, CURLOPT_SSL_VERIFYPEER, FALSE);

I hope this information helps.

Please let us know if we can assist you in any other way.

Sincerely,
Lindsay C.
Online Support Representative

Right back to the cURL requirements which really don’t make any sense for fsockopen().  It really doesn’t matter as I chnaged the code which manages the Google Maps so it no longer needs it.

Over the past few days I have had a back and forth e-mail dialog with GoDaddy Support regarding their PHP support (or lack there of).  Some of their responses are just silly.  Since they don’t support allow_url_fopen, I wanted to use cURL.  Well, apparently cURL isn’t supported with their Windows hosting service and even with that, requires a proxy configuration.  So then I decided to use fsockopen() since GoDaddy states it is supported for all PHP hosting plans.

Well fsockopen() times out when I try using it.  I got the following from GoDaddy support:

Dear Mike,

We apologize for the confusion.  While fsockopen() is supported you would need to be on an account that fully supports PHP.  You would need to switch to a Linux Hosting account.  If you do not wish to switch to a Linux Server, you would need to use custom coding.  Unfortunately, we do not provide coding or scripting support through this forum. I recommend performing a search on a search engine. I apologize for any inconvenience this may cause.

Please let us know if we can assist you in any other way.

Sincerely,
 
John B.
Online Support
Technician 

What kind of nonsense is this?  No where is it stated that it isn’t supported.  So respond to them and ask for a list of what is and isn’t supported with respect to running PHP under Windows.  This is what I got back in response – it is just nonsense – it points to me to a Linux configuration, how helpful is that?  Not only does it point to the wrong platform, but what it reports would indicate that what I want to do is supported!

Dear Mike,

As our Windows IIS 7 plans support PHP 5.2.5, please refer to the following link for a full list of supported PHP options:

•  http://gilahacker.com/info.php5

Please let us know if you have any further questions, comments, or concerns. Our service departments and telephone lines are open 24 hours a day, 365 days a year to accommodate your needs anytime.

You can reach us by phone to the following numbers:
(480) 505-8877 Technical Support, Sales and Service
(480) 505-8855 Billing

Or, you can send an email for speedy electronic service to the following address:
support@supportwebsite.com – Technical Support, Sales and Service

We look forward to serving you in the future.

Please let us know if we can help in any other way.

Regards,
Stacey P.
Online Support

It makes one wonder if their support people actualy read what is sent to them. So I responde back to them pointing out that their response was not very helpful and ask my question again as well as another request for what is and isn’t supported with PHP running under Windows.

My most recent response was a request for a code sample to see what isn’t working, hopefully this will resolve the issue once and for all, stay tuned!  The response also included a statement that they, GoDaddy, don’t have a document which articulates the differences between PHP support running under Windows and PHP support under Linux.

Dear Mike,

We apologize for any inconvenience this may have caused you. Currently fsockopen() is supported on your hosting account. Please send us the full URL of a page we can duplicate the error you are having so that we can troubleshoot this error. Unfortunately, we do not provide technical support with third-party scripting issues. However if the issue is being caused by a misconfiguration on our server we would be happy to resolve this for you.

Unfortunately we do not have any documentation available that will show you the difference in the php configuration between out Linux and Windows accounts. We apologize for any inconvenience this may have caused you.

Please let us know if we can help you in any other way.

Sincerely,
Jeremy T
Online Support Technician

The members of the WordPress Hackers mailing list are really helpful and usually a very clever bunch.  I posted my dilema last night and received a couple suggestions, one of which was to abandon cURL and use Snoopy because it is embedded with WordPress and therefore would always be avaialble.

Sounds like a good idea so I check it out.  While I don’t care for the way the class is implemented (direct access to class variables), it if works, I don’t really care.  So I set it up and sure enough, it works in my development area.  Off the production server and nope, it doesn’t work either.  Snoopy depends on fsockopen which GoDaddy says is supported on all PHP hosting plans but it times out so I am guess what they have stated in their help system isn’t true.

Now I am not sure what to do other than to pursue a Javascript solution.  GoDaddy is quickly going on my “less than happy with” list.  I wonder if a Linux server would be any easier?

The overhaul of phpHtmlLib is largely complete, I just need to validate a few more things before I call it done.  One of the things I did during the overhaul was to add some things to the library so it will load as a WordPress plugin.  This will make installation and configutation much easier.  The changes to phpHtmlLib made the migration from PEAR to the WordPress database abstraction class much easier.

The nice folks at WinSwim are interested in what I am doing with this plugin and have offered to host a demo site.  You can find it at:  http://wp.winswim.com  The demo site is running for the most part, if you are interested in trying it out, go ahead and register with the demo site then drop me an e-mail so I can change your permissions so you can actually do something other than register sample swimmers.

I say the demo site is running “sort of” because just about everything is working although there are a few bugs I know of (e.g. defining age groups).  The one thing which isn’t working and it is driving me nuts is the ability to display a Google Map.  This is a really nice feature that my own team used quite a bit this year.

I have encapsulated a class called Phoogle within wp-SwimTeam and it worked just fine in my development area and on the MacDolphins site.  Phoogle relies on a PHP configuration option known as allow_url_fopen which basically allows PHP to open a web page on an external site and read the content like it would a local file.  It’s a nice feature but one that a lot of web hosting providers turn off.  In fact, the host for the demo site has it turned off.

There is another technology called cURL which for all practical purposes, accomplishes what allow_url_fopen does although it is a little more involved.  I enhanced Phoogle to use cURL if allow_url_fopen is disabled and it worked just fine in my development area.  Great!  The change was pretty simple too.  Uploaded to the production server and nothing.  It doesn’t work there.  It turns out that GoDaddy (the web hosting provider) has a goofy cURL implementation which requires the use of a proxy.

After a much trial and error and a couple e-mails with GoDaddy support, all I have accomplished is a partial cURL request.  I am unable to get a complete response which prevents the map from being displayed.  I then got another e-mail from GoDaddy telling me that cURL is only supported on their Linux hosting environments not under Windows (even though it is enabled in PHP.ini).  Bleh.  ;-(

I think for now when I find a short code, I will check the allow_url_fopen setting and if it is off, will issue a warning during the short code processing.  There is probably a way to interact with the Google Maps API via Javascript, I guess I will need to look into that.  It is really too bad, the Phoogle solution was really simple to use.

Getting a demo up and running on a new host has been very enlightening.  I have used the PEAR DB class for years because it works well and is usually available.  The host which is being used for the demo site doesn’t appear to have the PEAR DB class installed so this has motivated me to migrate the SwimTeamDBI class to make use of the builtin WordPress database access class instead of depending on PEAR.  I have considered doing this for a while but have put it off but it looks like it is time to deal with it.

My intial impression is it should not be to much of a change as my current database class abstracts the PEAR aspect away from the rest of wp-SwimTeam.  The bigger concern is the phpHtmlLib widgets which also depend on PEAR.   Those will need attention and I suspect I will end up implementing a new database abstraction class for WordPress as part of phpHtmlLib.

I have been doing a lot of work on phpHtmlLib over the last week and for the most part, it appears to be done.  All of the changes allow phpHtmlLib to now be loaded as a WordPress plugin which is much easier to support.