{"id":4479,"date":"2011-02-26T03:01:48","date_gmt":"2011-02-26T11:01:48","guid":{"rendered":"http:\/\/www.oeconomist.com\/blogs\/daniel\/?page_id=4479"},"modified":"2023-11-02T14:09:04","modified_gmt":"2023-11-02T21:09:04","slug":"favicons-apple-touch-icons-site-thumbnail-images-php-and-wordpress-coding-issues","status":"publish","type":"page","link":"https:\/\/www.oeconomist.com\/blogs\/daniel\/?page_id=4479","title":{"rendered":"FavIcons, Apple Touch Icons, Site Thumbnail Images: PHP and WordPress Coding Issues"},"content":{"rendered":"

This is the third part of a three-part discussion of favicon<\/code>s, Apple-Touch icons, site thumbnail images, and how to tag pages (especially WordPress pages) to associate them with such graphics<\/a>. The first part<\/a> explained the purpose of these graphics, and the required HTML<\/abbr>. The second part<\/a> provides working code that can be dropped into a WordPress<\/a> theme (specifically, into functions.php<\/code>). This final, very boring<\/em> part motivates that code, and provides some more general discussion which could be applied to PHP<\/abbr><\/a> other than WordPress<\/a>.<\/p>

In discussing the nature of favicon<\/code>s, Apple Touch icons, and thumbnail graphics used by linking sites<\/a>, I tried to give some indication as to how I thought the HTML<\/abbr> ought to be handled. Even in the case of dynamically generated webpages, some of the code that I've seen out there just hard-codes the HTML<\/abbr> for these graphics. Such code is very breakable, as when, for example, a 'blog is relocated to a different directory (perhaps of a different domain). And, in the case of dynamically generated individual posts and pages which are to have their own thumbnail images, the handling too must be dynamic.<\/p>

There are further issues in how generating PHP<\/abbr><\/a> code should be designed, some general, and some specific to WordPress<\/a>.<\/p>

[Up-Date<\/span> (2020:05\/19):<\/span> I up-dated the code to-day, but have only partially up-dated the discussion around the code. So the explanations<\/em> are a bit crufty<\/em>.]<\/span><\/p>

General PHP<\/abbr><\/a> Issues<\/h4>

From the perspective of user-friendliness, perhaps the best route would involve creäting a webpage interface that would allow the user to upload graphics files, and declare these or files already present to be the favicon<\/code>, Apple Touch icons, or default thumbnail graphic icons. For the aforementioned sorts of files, my code just looks for candidates from within restricted sets of names, and uses the first of each that it encounters. In the case of favicon<\/code>s and thumbnail images, the differences amongst allowed file names is to support different extensions, corresponding to different formats; but a single file-name could have been imposed, with no extension or with the extension ignored. In the case of Apple Touch icons, the names themselves pass further information to the client device interface.<\/p>

The basic<\/em> idea is just<\/p>

$filespec = \"\";
if (file_exists("candidateNameFirst<\/var>")
  $filespec = $siteURL<\/var> . "candidateNameFirst<\/var>";
else if (file_exists("candidateNameSecond<\/var>")
  $filespec = $siteURL<\/var> . "candidateNameSecond<\/var>";
…
else if (file_exists("candidateNameLast<\/var>")
  $filespec = $siteURL<\/var> . "candidateNameLast<\/var>";
if ($filespec)
  echo "<tagStuff<\/var>" . $filespec . "moreTagStuff<\/var> \/>\\n";<\/code><\/blockquote>

for each sort of image (the favicon<\/code>, the Apple touch icons, and the default thumbnail images). The site URL<\/abbr> isn't in the code as a (sub)string literal so that the user doesn't have to mess with it at each installation. The major complication is when the user has selected a distinct image file to be used as a thumbnail graphic for a particular page. That file then has to be invoked.<\/p>

\/* First Attempt *\/
function getimagemimetype ($filespec)
{
  $imagesizearray = getimagesize($filespec);
  return($imagesizearray['mime']);
}<\/code><\/blockquote>

Unfortunately, while I found that this worked fine for GIF<\/abbr>, JPEG<\/abbr> FIF<\/abbr>, and PNG<\/abbr> files, it returned an empty string for MS<\/abbr> icon files. In cases where an empty string is returned, I resorted to reading the first four bytes of the file, and comparing these with the first four bytes of the MS<\/abbr> icon file specification. (The comparison itself is somewhat kludgy, because PHP<\/abbr><\/a> is not good about reading bytes as such nor about comparing characters in strings to integral values, and treats a byte 0x00<\/code> as an EOS<\/abbr>).<\/p>

function getimagemimetype ($filespec)
{
  $imagesizearray = getimagesize($filespec);
  $type = $imagesizearray['mime'];
  if (strlen($type) == 0)
  { \/* See if it might be a .ICO *\/
    $identifier = fread(fopen($filespec,'r'),4);
    $bytes = "\\x0\\x1\\x2";
    if ( ($identifier[0] == $bytes[0]) && ($identifier[1] == $bytes[0])
                               &&
        (($identifier[2] == $bytes[1]) || ($identifier[2] == $bytes[2]))
                               &&
        ($identifier[3] == $bytes[0]))
      $type = "image\/vnd.microsoft.icon";
  }
  return ($type);
}<\/code><\/blockquote>

Hypothetically, I could have just punted to looking for a file-name extension of .ico<\/code><\/q> exactly and only when getimagesize<\/code> failed, or even never invoked it for files with that extension. Also, the results of experimentation suggest that setting the type<\/code> attribute to an empty string will not prevent a MS<\/abbr> icon from working as a favicon<\/code>.<\/p>

Another possibility would be to read the first few bytes of any<\/em> file, rather than calling getimagesize<\/code>. A GIF<\/abbr> file begins GIF87a<\/code><\/q> or GIF89a<\/code><\/q> and its proper MIME<\/abbr> type is image\/gif<\/code><\/q>; a JPEG<\/abbr> FIF<\/abbr> file begins \\xFF\\xD8\\xFF\\xE0\\xdd<\/var>\\xdd<\/var>JFIF\\x00<\/code><\/q> (where d<\/var><\/code><\/q> is some hexadecimal digit) and its proper MIME<\/abbr> type is image\/jpe<\/strong>g<\/code><\/q>; an ICO file begins \\x00\\x00\\0x00\\0x01<\/code><\/q> or \\x00\\x00\\0x00\\0x02<\/code><\/q> and its proper MIME<\/abbr> type is image\/vnd.microsoft.icon<\/code><\/q>; a PNG<\/abbr> file begins \\x89PNG\\x0D\\x0A\\x1A\\x0A<\/code><\/q> and its proper MIME<\/abbr> type is image\/png<\/code><\/q>. But (as noted parenthetically above) PHP<\/abbr><\/a> is not good about handling the comparison in cases where a zero byte is part of the header; it might be best to provide a separate function to handle the byte comparisons as such, if there are going to be many of them.<\/p>

The code to identify MIME<\/abbr> type could be put in-line everywhere it were used; but, unless it is going to be from bald acceptance of the file-name extension (in which case it might be done when the file existence were detected), there would be dubious efficiencies in doing that.<\/p>

My code for the favicon<\/code> conforms pretty closely to the basic structure sketched above, but the MIME<\/abbr> type is handled by introducing a variable $favicon_type<\/code>, set as part of the positive outcome of any condition.<\/p>

if (file_exists("favicon.xxx<\/var>"))
{
  $favicon_spec = get_bloginfo('siteurl') . "\/favicon.png";
  $favicon_type = getimagemimetype("favicon.xxx<\/var>");<\/u>
}<\/code><\/blockquote>

(NB<\/abbr>: The function get_bloginfo<\/code> is here drawn from WordPress<\/a>.) My order of preëmption was fairly aribitrary.<\/p>

My code for the AppleTouch icons actually just puts the echo<\/code> commands within the conditionals.<\/p>

$siteurl = get_bloginfo('siteurl');
$apple_touch_icon_possible_size = array(\"57\", \"72\", \"76\", \"120\", \"144\", \"152\", \"180\");
foreach ($apple_touch_icon_possible_size as $apple_touch_icon_size)
{
    $apple_touch_icon_sizes = $apple_touch_icon_size . \"x\" . $apple_touch_icon_size;
    $apple_touch_icon_name_partial = \"apple-touch-icon-\" . $apple_touch_icon_sizes;
    if (file_exists($apple_touch_icon_name_partial . \"-precomposed.png\"))
        echo \" <link rel=\\\"apple-touch-icon-precomposed\\\" sizes=\\\"\" . $apple_touch_icon_sizes . \"\\\" href=\\\"\"
                 . $siteurl . $apple_touch_icon_name_partial . \"-precomposed.png\\\" \/>\\n\";
    else if (file_exists($apple_touch_icon_name_partial . \".png\"))
        echo \" <link rel=\\\"apple-touch-icon\\\" sizes=\\\"\" . $apple_touch_icon_sizes . \"\\\" href=\\\"\" . $siteurl
                 . $apple_touch_icon_name_partial . \".png\\\" \/>\\n\";
}<\/code><\/blockquote>

The order of preëmption conforms to what an standard client would do in the absence of tags.<\/p>

My code for the thumbnail graphics is very much like that for the favicon<\/code>, except that it first looks for a page-specific image.<\/p>

WordPress<\/a> Issues<\/h4>

The first question is of what, if anything, to put in functions.php<\/code> and of what, if anything, to put in header.php<\/code>. In order to use the featured image<\/q> facility of WordPress<\/a> version 2.9 and later, functions.php<\/code> must have<\/p>

add_theme_support('post-thumbnails');<\/code><\/blockquote>

(preferably prefaced with if (function_exists('add_theme_support'))<\/code><\/q>) inserted into it. All of the remaining code here could be put into either .php<\/code> file, though getimagemimetype<\/code> should probably be defined in functions.php<\/code>.<\/p>

I chose to put everything remaining also into functions.php<\/code>. That meant wrapping it into one or more functions, and then adding each such function as an action<\/code> to wp_head<\/code>. If, instead, that code were placed in header.php<\/code>, then the code should be inserted somewhere within the head<\/code> element, and only the code of getimagemimetype<\/code> should be wrapped into a function. Given that the code is all being placed in functions.php<\/code>, the next question is of whether to put the code for all three sorts of graphics into just one function. If one is always going to use all of the functionality, and never modify the implementation once it's effected, then one function is fine. But, for ease of maintainability, I chose to creäte three functions, one for each basic sort of graphic; that required three calls to add_action<\/code>, one for each of those functions.<\/p>

I've seen code for the thumbnail graphic that provides a default for singular<\/code><\/q> pages (individual entries, and those pages which WordPress<\/a> calls Pages<\/q>) that do not have a Featured Image, but that does not<\/em> provide thumbnails for non-singular<\/code> pages. I don't see why the default thumbnail graphic should not be used in such cases. In any event, the code for extracting the page-specific thumbnail specification is a bit rococco.<\/p>

if (is_singular())
  if (function_exists('has_post_thumbnail'))
    if (has_post_thumbnail())
    {
      $image_array = wp_get_attachment_image_src(get_post_thumbnail_id());
      $thumbnail_graphic_spec = esc_attr($image_array[0]);
    }<\/code><\/blockquote>

get_post_thumbnail_id<\/code> (with no argument) returns an integer associated with the featured image for the present page. Basically by look-up, wp_get_attachment_image_src<\/code> converts that integer into an array, the initial element of which is a URL<\/abbr> for the featured image. esc_attr<\/code> makes sure that characters that could cause awkwardness are removed or escaped.<\/p>

Comments<\/a><\/p>","protected":false},"excerpt":{"rendered":"This is the third part of a three-part discussion of favicons, Apple-Touch icons, site thumbnail images, and how to tag pages (especially WordPress pages) to associate them with such graphics. The first part explained the purpose of these graphics, and the required HTML. The second part provides working code that can be dropped into a […]","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"open","ping_status":"open","template":"","meta":{"_bbp_topic_count":0,"_bbp_reply_count":0,"_bbp_total_topic_count":0,"_bbp_total_reply_count":0,"_bbp_voice_count":0,"_bbp_anonymous_reply_count":0,"_bbp_topic_count_hidden":0,"_bbp_reply_count_hidden":0,"_bbp_forum_subforum_count":0,"footnotes":""},"class_list":["post-4479","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.oeconomist.com\/blogs\/daniel\/index.php?rest_route=\/wp\/v2\/pages\/4479","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.oeconomist.com\/blogs\/daniel\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/www.oeconomist.com\/blogs\/daniel\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/www.oeconomist.com\/blogs\/daniel\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.oeconomist.com\/blogs\/daniel\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=4479"}],"version-history":[{"count":1,"href":"https:\/\/www.oeconomist.com\/blogs\/daniel\/index.php?rest_route=\/wp\/v2\/pages\/4479\/revisions"}],"predecessor-version":[{"id":12170,"href":"https:\/\/www.oeconomist.com\/blogs\/daniel\/index.php?rest_route=\/wp\/v2\/pages\/4479\/revisions\/12170"}],"wp:attachment":[{"href":"https:\/\/www.oeconomist.com\/blogs\/daniel\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=4479"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}

Some of the tags to be generated have a type<\/code> attribute, in which a MIME<\/abbr> image type is supposed to be identified. The easiest<\/em> way to infer an image type is from the file-name extension<\/em> (eg jpg<\/code><\/q>), but I've encountered many files of one sort with the extension of another. So my thinking was to call a function to identify the MIME<\/abbr> type. I didn't find a standard function that did just that, but the ill-named getimagesize<\/code> function actually returns an array, one element of which (since PHP<\/abbr><\/a> version 4.3.0) is MIME<\/abbr> type information. So I could call getimagesize<\/code> within another function, which would just return that type information.<\/p>