A few weeks ago Aaron Brazell mentioned on Twitter that he had been unable to run Silverlight on his brand new Macbook Air:

I have never been able to run Silverlight on my 3 month old Macbook Air. Can someone help me solve this? cl.ly/image/2r3U1H38…

— Aaron Brazell (@technosailor) December 25, 2012

This intrigued me, as many random things do. I love attempting to resolve obscure issues, and after watching him struggle for a few days I decided to help out. I spent about an hour, and learned some really cool things about the installation process for Mac apps packaged as ‘.pkg’ files, and how to go about installing them manually.

I had a hard time finding the information anywhere, and figured that, while this is somewhat specific to Silverlight, that it may be useful to others.

Although I use a Mac, and love the beauty of it’s UI, I spend most of my time on the command line. I am a Linux Systems/DevOps Engineer by trade, so I of course interact with most of my daily tasks from the command line.

I needed to download a copy of the Silverlight.dmg file, but quickly found that if you hit the Silverlight site, and already have Silverlight installed you couldn’t get to the download. Fortunately they link you to an uninstall page on their site, so I just deleted the paths specified there:

rm -rf /Library/Internet\ Plug-Ins/Silverlight.plugin /Library/Receipts/Silverlight.pkg /Library/Receipts/Silverlight_W2_MIX.pkg /Library/Internet\ Plug-Ins/WPFe.plugin /Library/Receipts/WPFe.pkg

I restarted my browser, hit the Silverlight site again, and downloaded the Silverlight.dmg file. I did take this opportunity, to inspect my HTTP requests from my browser, and determined the actual URL where the file lives for future reference.

After downloading and double clicking to mount, you can just navigate directly into /Volumes/Silverlight/Silverlight.pkg from the command line. On Mac ‘.app’ and ‘.pkg’ as well as many other items that appear to be files, are actually just specially named directories. Mac styles them to look like files. If you really want, you can right click on such an item and select ‘Show Package Contents’.

Once inside, I took a look around, and quickly noticed that the Contents/Archive.pax.gz file was where the majority of the data was located based on size, and looking in the Contents/Resources directory, I found some simple shell scripts and perl scripts.

There is an InstallationCheck perl script, that is used to validate that your system meets the requirements. After looking into it, I couldn’t determine why it would fail to succeed, and neither could Aaron. Attempting to modify this file and install, resulted in the installer reporting some generic error, which was the result of the signature of the InstallationCheck file being different than the stored value. With that option gone, I took a look at the other files.

I found preflight was a shell script version of the uninstall instructions on the site. And postflight went around cleaning some things up and generating CPU specific optimized libraries for Silverlight to use, as opposed to just-in-time compilation.

Back to Archive.pax.gz…

I quickly recognized the ‘.gz’ extension, as that is a standard gzip file extension. I however, did not recognize the ‘.pax’ file extension, although after reading a little about it), I am a little surprised I didn’t.

In any case, after gunzipping and unarchiving using pax, You basically get a directory hierarchy that can be dropped into the root (/) partition on your Mac. So to keep from wasting any more of your time, let’s get on to the actual steps to get it working:

Note: I wouldn’t try just copy/pasting that whole block. Run each command separately to avoid potential issue.

cd ~/Downloads
curl -A "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/536.26.17 (KHTML, like Gecko) Version/6.0.2 Safari/536.26.17" \
    -Lo Silverlight.dmg http://www.microsoft.com/getsilverlight/handlers/getsilverlight.ashx
hdiutil attach Silverlight.dmg
cp -r /Volumes/Silverlight/Silverlight.pkg ~/Downloads/Silverlight.pkg
hdiutil detach /Volumes/Silverlight
cd ~/Downloads/Silverlight.pkg/Contents/
sudo ./Resources/preflight
gunzip Archive.pax.gz
pax -r -f Archive.pax
sudo cp -r Library/ /Library/
cd Resources/
sed -i '.bak' -e 's/rm\ -rf\ coregen.*)/)/' postflight
sudo PACKAGE_PATH=~/Downloads/Silverlight.pkg ./postflight

Close your web browser(s) and reopen visiting the following URL to test Silverlight: http://www.microsoft.com/getsilverlight/default.aspx

At this point you should have a Silverlight working on your Mac, or at least it was for Aaron:

My Silverlight issue was solved manually by @sivel with this series of commands. Sheer brilliance. gist.github.com/b56105b0748f7e…

— Aaron Brazell (@technosailor) December 27, 2012

That Github Gist, still exists, and contains the same steps as outlined above.

Most of those instructions are pretty self explanatory, the one that is not is probably the sed command. Basically in postflight it kicks off a number of commands into the background that utilize a binary called coregen_i386. It also deletes the coregen_i386 binary. In my testing I found that it often deleted the coregen_i386 binary before all of the coregen_i386 commands had executed, causing some of them to fail. So the sed command does an inplace edit of the postflight file to remove the rm -rf commands to delete the coregen_i386 and coregen_x86_64 binaries.

Anyway, hopefully this helps someone else. Enjoy!

Normally I start these posts with “Every so often someone asks a question in the WordPress IRC channel that sparks my interest”, however today, to my great surprise someone actually caught my attention on the wp-hackers mailing list.

For those of you who didn’t click through, the question was:

Couldn’t find this on forums or anywhere else.
What can I test to check if wp_footer was placed on the theme?

Before any replies came in I was already interested and when Peter Westwood replied with “The other way to do it is to do a http request based test which a special query arg on which you output a string on wp_footer.“, I was on the hook.

I spent a few minutes writing up a test plugin, to perform only this functionality and responded back to the list. It was pretty well accepted and I got a few comments from Ozh and Andrew Nacin on Twitter. One of the comments was actually an idea, to extend the checks to make sure that the calls to <?php wp_head(); ?> and

<?php wp_footer(); ?> were in the proper places in the code.

Before I get to the code, I want to spend a little time talking about the significance of wp_head() and wp_footer(). These 2 functions are the key to functionality of a lot of plugins and are the real work horses of themes. The wp_head and wp_footer functions allow WordPress core and plugins to hook into your theme either directly before the </head> or </body> html tags in your theme and perform actions. The majority of the time these actions are used to output style sheets or JavaScript, for use by plugins. WordPress core uses it to output a lot of good functionality such as relational links to your RSS and ATOM feeds into the head of the document. Joseph Scott wrote about this nearly a year ago. His post is fairly short but does a good job at explaining why it is important to include these functions.

Back to the original discussion, which was how do we detect whether or not wp_head and wp_footer are called in the active theme, and if called are they called, was it from the proper locations?

In my proof of concept plugin, we hook into admin_init, which will actually use wp_remote_get() to retrieve the frontend of our WordPress site. It calls the url with 2 query vars, that if present will cause the plugin to hook into wp_head and wp_footer and output some content that we will later look for. If the response was successful, as in returning a 200 response code, we will look at the content to see if <!--wp_head--> and

<!--wp_footer--> are present. If they are not we will see an admin notice telling us which problems were found. If those strings were found but they were not found directly before

</head> or </body> the notice will alert you of such.

Without further adieu:

Just in case you cannot see the code above, use this link: http://paste.sivel.net/24.

I have a question for all of the users out there who are using the Shadowbox JS and Lightview JS WordPress plugins.

Would you prefer the plugin to automatically add the activator attributes to the links for Shadowbox and Lightview respectively, rather than having to manually add it to your links?

I am one of those people who believe that more flexibility is a better feature than ease of use by less typing.

With that being said I could see a situation where one would simply want to use Shadowbox or Lightview for all of their image links and where adding the activator attributes to the links would become tiresome.

Perhaps a good compromise would be to add functionality to either enable or disable global activation on image links? Perhaps making global activation the default would be beneficial?

I think I have already talked myself into adding this functionality but I would still like to hear some user feedback, so tell me what you think.