Calendar-Plus renamed to Enhanced Calendar

I just received the approval from the WordPress plugin repository for Enhanced-Calendar.  The WordPress plugin I previously called Calendar-Plus will now be known as Enhanced-Calendar.  Once I get the code all checked in and the proper structure, it should be available from the plugin repository.  Hopefully that will happen in a day or two.

More Menu Changes

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.

UI Change for wp-SwimTeam

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.

GoDaddy’s PHP support is questionable

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

More on Phoogle & Google Maps

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 trickle down effect

While trying to get a demo site up and running I ran into an issue that has taken me down a path I didn’t expect to head down at this time.  But now that I have run into it, I have decided to fix it correctly.

The wp-SwimTeam plugin depends on phpHtmlLib and the 2.x version of the library requires that it be installed in the web site’s root directory.  This typically isn’t a big deal but in some cases can be inconvenient.  It also requires the library be named phphtmllib as the path is (was) encoded into quite a few of the widgets.

When I uploaded the library to the new demo site, it didn’t run correctly.  The demo site is running PHP5 which I immediately suspected as the problem.  So I loaded PHP5 and phpHtmlLib into a new virtual machine (I love VMware, it is wonderful for configuring different environments) and all the examples ran just fine.  Odd, very odd.  Digging into it further, it looks like the hosting provider’s PHP virtual directory support setting is different than what I had locally and affects how include files are handled.

A couple of tests confirmed my suspicions.  Since this hosting provider is large, I suspect this PHP configuration is pretty typical and it provided sufficient motivation to go back and fix phpHtmlLib 2.x so it can be loaded with appropriate configured PHP define() statements.  If you look through the phpHtmlLib forums you’ll find this is a fairly regularly requested item (including by me) and phpHtmlLib 3 (which requires PHP5) is configured this way.

Over the last couple days I have been updating the phpHtmlLib 2.x branch to support this configuration method and now have it all running correctly in my development area.  Before I commit all the changes, and there are a lot of them, I need to verify it all works in the suspect hosting environment.

The trickle down of setting up a demo site resulted in an overhaul to phpHtmlLib.  It needed to be done anyway and doing it will allow phpHtmlLib to be loaded as a WordPress plugin eventually.

Generating SDIF

Last night I completed the initial PHP include file for SDIF support.  As I mentioned previously, I thought it would take a while and it did.  The upside is taking the time to go through the specification to create all the PHP constants has made me more familiar with SDIF.  I don’t think it will be too hard to generate SDIF from the registration information the plugin already collects however, there are parts of the plugin which will need some additions.  For example – the SDIF team records (there are two of them) require detail which wasn’t collected previously and the swimmer records prefer to have the middle name because the USA Swimming Id is constructed from portions of the swimmer’s first, middle, and last names along with their birthdate.  Looks like to me like you can still end up with conflicts but that is  what the specification outlines.  So now off to enhance the team and swimmer forms.