WordPress: Remove/hide Google+ field from Contact Info on user admin page

This WordPress tweak is pretty unlikely to come up for most developers, but I was asked to remove the Google+ field from the Contact Info section of the User admin page. Here's a quick snippet to paste into functions.php to do so:

function custom_admin_js() {
  // hide WP's Googleplus input on user profile
  if( strpos($_SERVER["REQUEST_URI"], '/user-edit.php')) {
    echo '<script type="text/javascript"> jQuery(\'#your-profile input[name="googleplus"]\').parent().parent().hide(); </script>';
  }
}
add_action('admin_footer', 'custom_admin_js');

Checking A File's Upload Size In The Browser

This really just a quick note so I don't lose the code snippet I just used...

I'm working on a form which allows users to upload a file, but we want to stop them uploading giant things. Ultimately the server's maximum upload filesize will stop anything too huge getting through, but it's nice to remind people of the limit before they bother uploading.

This is a great little snippet to do that in current versions of Chrome, Firefox and Safari.

$('#contact_file').bind('change', function() { 
  filebytes = this.files[0].size;
  if(filebytes>1024*1024*5) {
    alert("The file you selected is TOO LARGE and will be rejected by the server. Please select a smaller file."); 
  }
});

If you can't work out what is happening there, then "contact_file" is the id from your file input and 1024*1024*5 is the limit you want to impose, in this case 5MB. Don't forget to check that the server side limit is in line with this.

It won't work in IE* or some older browser versions, but it's a nice extra courtesy for users where it can be executed. You could also hook it up to the submit button if you want to do a check at that stage.

*Apparently there's an ActiveX thing you can do for IE users, but I am not so inclined.

IE8 Ajax Caching/Session Issue

Today I spent a bit of time trying to track down an ajax problem the was only occuring in IE8.

The ajax funcionality was calling a static URL which returned a JSON result containing the html to display login buttons depending on the user's state. The call was made via jQuery.getJSON(), which is wrapper function for .ajax() and .parseJSON()

The problem was that IE8 was exhibiting fairly unpredictable behaviour, sometimes it seemed that call was not firing, other times it appeared to return the opposite result I was expecting.

Initially it looked like IE8 was not passing the user's session. A quick Google search returned a number of threads where developers had assumed this to be the case, but there were very few constructive suggestions in addressing the issue. Eventually I spotted something where the true issue had been identified as IE8 caching the ajax response.

I added a cache-busting parameter to my ajax URL using the following javascript and voila, everything starting working as expected.

"...&cachebuster="+Math.random()

Hopefully this short post will save you some IE8 related head-scratching.

Google Buzz Button IE8 Error

Recently Google introduced their Buzz buttons to "Help people post your content on Google Buzz". Share buttons are not a new idea, but Google Buzz is new and kinda shiny. Here's a quick intro if you're not up to speed yet:



And here's a Buzz button:   

A few days ago I implemented the Buzz share buttons on a website at the clients request and it all seemed to be working great, until this morning I found that some pages were failing to load in Internet Explorer 8.

I pointed IE8 at the development site and confirmed there was a serious problem. The error I recieved was thus:

Webpage error details
User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)
Timestamp: Thu, 22 Apr 2010 13:33:25 UTC
Message: HTML Parsing Error: Unable to modify the parent container element before the child element is closed (KB927917) Line: 0 Char: 0 Code: 0

I disabled the Buzz button to confirm it was part of the problem (which it was), and then checked my implementation against the documntation and other sites. Everything seemed to be OK. After a long period of debugging, and following up false leads it turned out to be that Internet Explorer was executing the Google Buzz button's javascript code too early - even when it was in the page footer.

The Solution:
Once again jQuery came to the rescue - I replaced this line:
<script type="text/javascript" src="http://www.google.com/buzz/api/button.js"></script>

with this line:
<script type="text/javascript">jQuery(document).ready(function(){jQuery.getScript('http://www.google.com/buzz/api/button.js');});</script>

jQuery image roll-overs

On the site I am currently working on I needed to implement hover/roll-over states for a number of image tags. Other elements in the site use the CSS based x:hover{background:y} approach, but that was not an appropriate solution for these instances - background images were not going to used, so I came up with a nice jQuery based solution that keeps my page-source pretty uncluttered too.

I added a class value of "hover" to the image tags I wanted to exhibit this behaviour. The replacement images all had the suffix _hover added (e.g. theimage_hover.png )

<img src="/images/theimage.png" class="hover">

Then in my main javascript file I added this little snippet:

function imghover_on(img){if(img.src.indexOf('_hover.')==-1){img.src=img.src.substr(0,img.src.length-4)+'_hover'+img.src.substr(img.src.length-4)}}

function imghover_off(img){img.src = img.src.replace('_hover.','.');}

jQuery(document).ready(function(){
jQuery("img.hover").mouseenter(function(e){ imghover_on(this);});
jQuery("img.hover").mouseleave(function(e){ imghover_off(this);});
});


This code declares two functions which add or remove the "_hover" suffix to the image tag's source, while not needing to know if the image is .png .gif or .jpg.

The jQuery statement waits for the page to load and then finds all img tags in the document with the hover class set and binds the function calls to the mouseenter and mouseleave. This saves me from having to add these events to every single image tag manually like this:

<img src="/images/theimage.png" onmouseover="imghover_on(this);" onmouseout="imghover_off(this)">

Notes:

• I used mouseenter/mouseleave as they fire a lot less than mouseover/mouseout (see: http://docs.jquery.com/Events/mouseenter )
  
• It's not infallable, a .jpeg file extension would fail, but it's working nicely for first cut.

Updating Google Map Marker's z-index

Lately I've been working on a web application that uses Google's Maps API. It's been an interesting and engaging project.

One of the limitations of the current Maps API is that the z-index of a marker cannot be changed after it has been created. The client requested that the selected marker "popped to the front" as some markers obscured others in certain map areas depending on zoom and closeness of coordinates. This was a reasonable request and would enhance the UI, but was not so easy to implement.


Mike Williams gives a good introduction to this issue and details of how to set the z-index of the marker when it is created with addOverlay() in his Google Maps API Tutorial. Having read this, I attempted to re-create each marker when it was clicked and keep track of the top most z-index. I had some success but had unpredictable z-index results and it was definitely an inefficient way to produce the desired effect.

I decided to browse the DOM and see if I could find a better way to do this. I found a guide to Undocumented Google API features which seems to be mostly out of date, but contained the very important details of how to calculate a Marker's default z-index:

Use marker.setZIndex(Math.round(marker.getLatitude()*-100000)) to get a moved marker to overlap correctly.

Even though setZIndex() and getLatitude() are not valid methods in the current API, it's easy to understand the calculation.

In my application I was already using a unique icon for each marker so that they displayed sequential letters (A,B,C...) and had added an index property to the marker object. I was able to leverage this with a bit of jQuery magic to find each icon in the DOM and alter the CSS z-index value. Since the default z-index is something like -108619296, I created a function to toggle the z-index between normal and front positions by multiplying it by -1.

icon = $("#mapbox div div div img[src='/images/markers/"+marker.index+".png']");
zidx = icon.css('z-index');
icon.css('z-index',zidx*-1);

Just to make sure that no other marker was still in the top position, I looped through my array of markers and reset the z-index with this function.

function reset_zorder(marker) {
$("#mapbox div div div img[src='/images/markers/"+marker.index+".png']").css('z-index',Math.round(marker.getPoint().lat()*-100000));
}

Obviously none of this is a copy+paste solution. but it should give anybody needing to manipulate Google Maps MAP Marker z-index a good example to work from.

How To: Android Scrollable Divs

Lately I've been working on a webapp for the Motorola Droid and a QNX CAR device. The application interface is a split screen with one half being a list of items of variable length. Neither of these browsers on these devices support iframes or scrollable divs, so the approach used in a traditional browser was not an option.

The application was using jQuery, so using the jQuery UI Draggable plugin was a natural choice. It was quick and easy to implement and worked well on the QNX device, but didn't work at all on the Android browser.

To get the prototype version of the application finished on time for the deadline, I resorted to adding up/down buttons to the interface that scrolled the div content by manipulating the margin-top via javascript. This satisfied the client, but as a solution it was less than optimal, and in my opinion it made the UI feel clunky.

At the time that I write this, there's not a lot of information about how to deal with this issue in the Android browser. It took me a while to discover that this issue is also a problem for the iPhone/iPod Touch browser and since Android's browser also uses WebKit, there is already a working solution called iScroll developed by Matteo Spinelli on Cubiq.org.

This code utilises WebKit's "touch" events, which are akin to click events, but are only fired by touch screens. You can find a great introduction to Javascript Touch Events on Michael's "Back To The Code" blog. If you're new to developing mobile webapps, you should probably also take a look at iPhone Webapps 101.

Hopefully posting these bits and pieces together here will help save somebody a lot of time searching on Google.