Our scary plastic halloween pumpkin, I finally get around to shaving, and a pic using the iPhone app PhotoFunia.
Our scary plastic halloween pumpkin, I finally get around to shaving, and a pic using the iPhone app PhotoFunia.
Getting back into vlogging. Discussing our upcoming trip to Kenya and Turkey.
This is relatively straightforward to do, but I’m posting it so I have the Javascript next time I need it. On a Magento client site, all PDFs needed to be opened in a new window. Why? No clue. The Magento template wasn’t doing anything fancy, it was simply using the standard Magento Prototype.js library. Not having used Prototype.js in a long time, it took me a while to figure out the function calls to set the target attribute on all PDFs links to _blank, but here it is:
This is pretty much self-explanatory, but I’ll go through it anyway. document.observe(“dom:loaded”) is the jQuery equivalent of $(document).ready. readAttribute is like jQuery.attr(), include is like a Javascript IndexOf.
Thats pretty much it.
Working on a client site, we ran into issues with Internet Explorer, iFrames, and transparent PNGs. For the site, we are using an iFrame to load content when the user clicks on a button. On the fly, with javascript, a bit of code gets generated like:
Code snippel from fooFrame.html:
The background image is bazImage.png, a transparent PNG. This worked fine in Chrome, Firefox, and Safari, but all the transparent pixels turned up as white in IE. My first thought was we needed to apply a PNG fix.
But that didn’t help.
Not so surprisingly, Internet Explorer handles transparency differently than other browsers. Elements have an allowTransparency attribute that defaults to false, so embedded iFrames won’t be transparent. Simply set it to true.
One final step, set ‘background-color: transparent;’ in the body element.
Currently, this site is running WordPress MultiSite + Headway Themes. The main site is information I think other folks on the intertubes might find helpful. My Stream is generally junk that I find interesting. So, there is not one big RSS feed for the site. Don’t want the main site feed to get polluted by the stream feed.
I don’t know how many folks actually use auto RSS browser discovery, so I wanted to get rid of the RSS links that Headway makes automatically and replace it with a general RSS page that can be reached when the user clicks on the RSS icon.
So, lets see how Headway Themes adds feeds to the HTML. Towards the bottom of wp-content/themes/headway-version/library/core/head.php, you have Headway code being added to the standard WordPress header hook:
Slightly higher up in head.php, the headway_head_extras function is defined and set as a hook itself:
Its important to notice that this bit of code has the feed and pingback URL. We do want to keep the pingback URL, so we’ll need to handle that.
To stop headway_head_extras from being called in general by the WordPress header, I did the following:
Yes, I really should come up with a better function name than my_headway_head_extras, but thats not the point.
I first define my own function that includes the pingback URL. Then I stop the headway_head_extras function from being called by the WordPress header. And finally, I add my pingback function to the WordPress header instead.
I stuck the above code in wp-content/themes/headway-version/custom/custom_functions.php. The main RSS feed and comment RSS feeds disappeared as expected. But there was no change to the Stream site. I decided to put the code in wp-content/themes/headway-version/custom/sites/subsiteidentifier/custom_functions.php and it worked.
This may not be Headway Themes way of doing this, and might not be maintainable through upgrades, so try at your own risk. But I would imagine the custom_functions.php should be copied over as the theme gets upgraded, so it shouldn’t be an issue.
As a continuation of a project to move a CMS Made Simple site from one webhost to another, I ran into some caching issues.
Having successfully moved the CMS Made Simple files and database over, and editing the configuration file to use the right path and DB credentials, I went to the homepage. I was unceremoniously presented with:
string(103) “Smarty error: [in template:20 line 3]: [plugin] unknown tag – ‘title’ (core.load_plugins.php, line 124)” string(106) “Smarty error: [in template:20 line 4]: [plugin] unknown tag – ‘metadata’ (core.load_plugins.php, line 124)” string(108) “Smarty error: [in template:20 line 5]: [plugin] unknown tag – ‘stylesheet’ (core.load_plugins.php, line 124)” string(110) “Smarty error: [in template:20 line 6]: [plugin] unknown tag – ‘cms_selflink’ (core.load_plugins.php, line 124)” string(106) “Smarty error: [in template:20 line 43]: [plugin] unknown tag – ‘content’ (core.load_plugins.php, line 124)”
Nice.
Having never worked with a CMS Made Simple site before, this was really not helpful. My first assumption was that it was a caching issue. But I didn’t have the admin login information, so I couldn’t go into the backend and delete the cache. I would have to delete the cache manually.
When uploading the site, I noticed that there was a tmp directory. I imagined thats where the cache files would be located. Turns out I was right.
Deleting the contents of the tmp/cache and tmp/templates_c got rid of the nasty error and you can see the contents of those directories being refreshed once you hit the site.
Today, I was helping to move a CMS Made Simple site from one webhost to another. It seemed easy enough. I was provided a database dump and copy of the files. It should have been just a matter of importing the database dump with phpmyadmin, scping the files to the new host, editing the config.php, clearing the cache, and refreshing the browser. Right, right? Of course not.
The export of the original tables from MySQL were pretty standard: drop the table if it exists, recreate it, lock it, populate it, unlock it:
At the new webhost, in phpmyadmin, when importing the SQL, I kept getting the following error:
How can I not have the permission to lock tables? So I wanted to figure out if this lock really was the problem. Opening up the original SQL dump in Notepad++, I wanted to find the LOCK TABLES lines and remove them, and the corresponding UNLOCK TABLES. Now, there are way too many tables, so removing the LOCK TABLES by hand is a serious PITA.
Good thing Notepad++ supports regular expression in search. Use this to find all the LOCK TABLES:
and replace with nothing. You can find UNLOCK TABLES; directly and remove them.
Turns out after doing that, the SQL imported just fine. So that meant the stupid webhost didn’t allow LOCK TABLES access for the user. Why would you not let users lock their own tables? Plain retarded. There was nothing really wrong with the SQL, just a retarded host.
Thankfully the client got wise and moved to a better host where we had no such problems.
One of Run Level Media‘s project involves migrating a Windows application over Terminal Services, to the web. A previous programmer had started building the web app in C#, ASP.NET MVC 2. We decided to upgrade for the sake of maintainability and wanting to use some of the newer features in MVC 3 (like Razor).
After upgrading and trying to debug code, I kept running into the following error on every page load: ![]()
It was true that the favicon.ico was missing, but we didn’t want to make a temporary one. We just needed requests for dot files to the root directory to be ignored.
Most Global.asax have route definitions like this:
There are really two problems here. First, the controller looks for something to handle favicon.ico. More than likely, you don’t have a function to deal with favicon.ico (why should you). Second, the HttpException should be caught and dealt with. Either log it or provide a more helpful message. Otherwise you’ll see ‘HttpException was unhandled by user code’ errors.
To fix the controller, try this:
new { controller = @”[^\.]*” } means ignore anything that matches that regex.

While walking through an ASP.net MVC3 app, I noticed that Ajax calls resulted in nothing happening. Debugging in Visual Studio, I noticed a SerializationException at the following code:
The JSON response from the Ajax was supposed to be read here, but it was failing. It was a runtime exception, “SerializationException was unhandled by user code.” Turns out InputStream wasn’t being read from the beginning of the stream, so the JSON couldn’t be deserialized properly.
Resetting the position in the current stream to the beginning should make it readable again:
Chinese for dinner at Little Schezuan, frozen yogurt at Pinkberry for dessert.