What a morning.

One of my other websites, Higher Ed Careers Canada, was built with Node.JS and WordPress. The user-facing website is WordPress and the backend/engine is Node.Js. They communicate via Atom Publishing Protocol. I know that AtomPub isn’t the most popular protocol, but it had exactly what I needed vs the other options.

About the time I was finishing everything up with the Node.JS engine portion of the project, I saw that WordPress.org was removing AtomPub from the core and moving it to a plug-in. Not ideal, but I wasn’t going to throw away hours of programming and start over because of this.

I had had some previous bumps getting it to work with the Dreamhost FastCGI setup, but it was click along working very reliably for months. WordPress 3.5 was released and I was holding off updating until I had a chance to fully test/debug the new plugin. Last night, Dreamhost decided that they would automatically roll out 3.5 in the middle of the night without warning. Eeek.

Since it had already been rolled out and rolling it back wasn’t a good option, I just had to see what happened. It looked like thing were going well until I saw that the AtomPub was not working even after installing the plugin.

After examining what responses were being sent back after my Node script had sent a post with Atom I saw that the following message was being returned:

Fatal error: Cannot redeclare class wp_atom_server in /my/path/to/wordpress/wp-includes/class-wp-atom-server.php on line 10


Okay. So, I renamed both the class-wp-atom-server.php and the wpapp.php files after looking at what the new plugin was doing – creating a virtual file with rewriting to replace wpapp.php. This stopped the runtime errors.

But things still were not working. I was getting a 401 Unauthorized from as a responses from my atom post. I had run into this problem before – it was a tweak in the .htaccess file – I thought maybe the update had overwritten my changes. Nope – this was all fine.

Looking at my previously working .htaccess file I saw that it would never get to the rule that rewrites the HTTP:Authorization to a server var because the index.php had an “L” flag (stop evaluating the rest of the file). I changed the .htaccess file to this:

RewriteRule . /index.php [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]

and commented out the line (like so):

#RewriteRule . /index.php [L]

Now I knew that the index.php file would be able to pass http authorization to the virtual wpapp.php file. But still no dice. Through the magic of a print_r statement in the class-wp-atom-server.php file I knew that the server var “REDIRECT_REMOTE_USER” was not being set, but it did have a server var of “REDIRECT_HTTP_AUTHORIZATION” that I could parse using the same process. Bam! That was the problem.

I’ll be submitting the fix to the AtomPub plugin later today, but it was an adventure fixing this problem withAtom Publishing Protocol and CGI – two forgotten WordPress edge cases.

This entry was written by Kyle, posted on December 15, 2012 at 12:12 pm, filed under node.js, wordpress. Leave a comment or view the discussion at the permalink and follow any comments with the RSS feed for this post.

I’ve been working on a new project, higheredcareers.ca recently. It is a high post-volume WordPress blog. It averages about 50 posts per day.

Publicize is an amazing part of the also amazing Jetpack plugin. Publicize automatically posts to social networks upon publishing. For Twitter, this concept works even at 50 posts per day. People are more sensitive with their Facebook feeds – this can easily overwhelm a Facebook feed, pushing the feature from ‘useful’ to ‘spam bot’.

What I’ve been able to do is get the best of both world using a couple of WordPress plugins – a daily digest of all the links posted in a day.

First, install the following plugins:

• Remove Posts in Category From Homepage plugin
• RSS Digest

Setup a new category, call it “Digests” or something. When you add the category – click both the “Remove from main loop” and “Remove from RSS feed”.

Settings when adding new category

Now, go to the settings for the RSS Digest plugin. Point the “Feed URL” to your own blogs URL. I also had to increase “Maximum number of items per digest.” With these settings, you’ll get a nice clean digest of all your blog posts each day.

Next, change the “Author for digest posts” to a user that only has a Publicize connection with Facebook. Your other user can be connected to Twitter – all of your posts will be auto-shared to Twitter and your Facebook will only get a single, digest version once per day.

This entry was written by Kyle, posted on November 23, 2012 at 1:07 pm, filed under wordpress. Leave a comment or view the discussion at the permalink and follow any comments with the RSS feed for this post.

I recently started work on a project hosted with Dreamhost. At work, we self-host our projects but I want to focus on programming rather than site administration, so I decided to go with a VPS on Dreamhost as I needed the flexibility of having root access.

This project uses WordPress for ease of updating and consistent security updates. Another part of the project uses Atom Publishing Protocol to push data into WordPress posts. On my development server this worked well, however when I moved it to the Dreamhost VPS, Atom Pub was just consistently rejecting the credentials. I double checked, changed user roles, did just about everything in my power to troubleshoot.

Annoyed, I started reading the codex page for AtomPub searching for anything related to this issue (Google is not very helpful in this area). Low-and-behold their is a whole section about Authentication – I remembered that Dreamhost runs PHP in FastCGI rather than as a Apache module. The codex has one link regarding authentication and it isn’t WordPress specific. The linked article says to add the .htaccess file and make modifications to the file attempting to do authentication.

I didn’t like the last bit – making modifications to WordPress itself is not a road I wanted to go down. So I changed the .htaccess as mentioned in the article:


<IfModule mod_rewrite.c>
RewriteEngine on
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]
</IfModule>


I tested it before making changes to any wordpress files. Bam! It works. No other modifications needed, thankfully. The codex could be a little more helpful in this area – I’m sure that some non-programmer types have really struggled with this issue.

UPDATE: Spoke too soon. Just blindly uploading the snippet above to your .htaccess will bork over the entire permalink system if you are using anything other than the query string method (/?p=123). To make it work add the last line (RewriteRule…) to the .htaccess file wordpress generates. If you make changes to your permalink settings, you’ll need to modify .htaccess again. WordPress apparently just appends the new rule to the end instead of actually parsing the file.

This entry was written by Kyle, posted on October 21, 2012 at 11:23 am, filed under server stuff. Leave a comment or view the discussion at the permalink and follow any comments with the RSS feed for this post.

I’ve been at my day coding day job for quite a while now. I really enjoy the daily challenge – sure there are frustrations, but my days go quickly and I feel more accomplished than at my previous non-tech university administration gigs. Working professionally doing Javascript day in and day out hasn’t made me a ‘better’ coder. Sometimes, I feel like I’m a worse coder as the imposed deadlines have occasionally pushed me to implement messy or inefficient code to get to the goal of ‘works’ and ‘out-the-door’. But what it really has done is made me faster. I’m remembering little used syntactic structures, writing code more quickly, and solving those irritating browser quirks with less googling.

Luckily, I’m still motivated when I get home to do my own stuff. I’ve heard from some people that a professional job will suck that motivation away, but so far I still have the desire. My most recent side project is MooBreakpoints, a Mootools plug-in for responsive javascript. Essentially, it allows you to specify screen width breakpoints and fire off Mootools events when you enter or leave these widths – a great compliment to media queries or other responsive design techniques. Google even recommends adapting your javascript behavior in responsive situations.

I can’t say that the concept is my own, Ben Brown of Xoxco released a great jQuery project late last year. I’m working on MooTools project and I cloned his functionality – the code is pretty different, which I find interesting. It just shows how much coder ‘voice’ javascript has and how the different dialects (mootools, jquery, etc.) affect how you code. I’m not saying my is better or worse than Ben’s – it is just more moo and less j.

MooBreakpoints is my first plugin for the Forge. I found the forge submission to be a frustrating process. First, I’m not great at git – I can use it and I’m getting better, but I don’t think I’ve fully digested the process. Secondly, the yaml headers and package file were the bane of my existence. Yaml is supposed to be simple and clean, but it seemed very picky and hard to see where it was malformed. Thirdly, the forge process was frustrating because the error messages weren’t very helpful (not being able to find ‘provides’ was a constant problem – it wasn’t that ‘provides’ wasn’t in my header, but that it wasn’t in the format it was expecting. Put your provides in brackets, kids.). Also, forge weirdly find tags in git – v0.1 was found as the latest over v0.12. It is a quirky process. In my next plugin submission I plan on documenting everything from start to finish as a public service.

This entry was written by Kyle, posted on July 29, 2012 at 9:36 am, filed under HTML5, javascript, moobreakpoints, mootools, thoughts, Uncategorized. Leave a comment or view the discussion at the permalink and follow any comments with the RSS feed for this post.

It has been a while since my last post, but things have really been changing for me. I took a job as a web programmer – this is a big leap for me. I’ve been doing this stuff for a while in my spare time and now I get to do all day long. It was a good move.

In this new job we do a lot of corporate work with strict brand guidelines and standards. Much of this is hand coded HTML. Hand coding makes sense as each project is a little different but it is somewhat error prone when we have to follow strict guidelines. Part of these guidelines are the requirement for alt text in img tags. It is a great guideline that a big part of the web doesn’t follow. Because the work is under NDA and behind login screens, we can’t just run it through a validator to check for these issues. It is also often done in snippets instead of a raw html file.

Checking things like alt tags is a tedious process – often our quality assurance team mouses over the images and wait for the tool tip to appear. On a big site this is big, boring, and repetitive job. I knew that I could write a script that would do it better and faster.

For the security reasons mentioned above, I decided that a local bookmarklet would best fit the job. I liked the challenge too – 2000 characters, regular expressions, and library-less pure Javascript. First was to determine a way to detect a image tag without an alt attribute. This was harder than I imagined – google proved seemed to have lots of people asking, but not a lot of good responses – HTML and regular expressions rarely mix well. I don’t think it could easily be done in one pass – so I figured out that I could easily get a regex that would find all the img tags and one that would find all the img tags with an alt attribute. If you take the resulting arrays and get the difference, you’ll have the img tags without the alt attribute. Grab the html from the page – run the two regexs and then dump it with console.dir and you’re in business. Then I ran it through a URL encoder and popped it into a link with “javascript:” and I was in business. Easier than I thought!

I’m sure it won’t catch everything but I was shocked to see how many very popular sites forget the alt attribute. Here is the code:

Because this uses Array.filter, it is a no go below IE 9 and I didn’t have room for the polyfill.

This entry was written by Kyle, posted on July 5, 2012 at 7:35 am, filed under javascript, regular expression. Leave a comment or view the discussion at the permalink and follow any comments with the RSS feed for this post.

One thing I love about working the web is the opportunity to find new solutions to problems. Sometimes, though, I just find a new solution to a problem that doesn’t exist.  In my last post, I shared a solution I worked up to replace a few background pngs with CSS gradients. I was using a CSS gradient to create a sharp line by putting two color stops together. It is nothing new, really – people have been doing stripes with CSS gradients for a while.

What is neat about this process is that you can effectively run-length encode a row of pixels using CSS gradients with stops. If you manipulate the background-size and background-position attributes and add multiple background gradients, you can then create an entire image. Other people have done similar things with box-shadow hacks, but I’m not aware of anyone doing this with gradients.

Anyway – here is a Mario sprite (from SMB2) using only gradients, background-size, and background-position.

A word of warning – this is a really stupid way of rendering an image. Incredibly stupid. Don’t do it. It is huge, difficult to program, and turns my macbook pro into a hairdryer when rendering. The only thing I could see this technique possibly work for is maybe email marketing – but we all know that you do horrible, bad things with html in emails.

This entry was written by Kyle, posted on May 4, 2012 at 11:05 pm, filed under css3. Leave a comment or view the discussion at the permalink and follow any comments with the RSS feed for this post.

Okay. I know setting style inline is bad in most cases. Keep your styles in your CSS file, your HTML in your HTML file and your javascript in your js file. CSS vendor prefixes are bad too. However, some cases dictate breaking some rules.

Right now I’m working on another game. Some elements of this game make use of multiple backgrounds and images that change color depending on the game state. The problem is that half of an image might be one color and the other half a different color. As I started proving my concepts, I used a background image that had the image details and another background image tucked behind that had the colors. This worked well enough, but to achieve some states, I would have one game element with three background images – too many http requests and hard work to render.

I realized that the image(s) that provided my split background colors could be replaced by a single CSS3 gradient. Nice! Because I was changing with the game state and I could have hundreds of different combinations of background details and background colors, using CSS classes would be impractical and a nightmare to maintain. I needed to set the style inline with Javascript. I realized that those darn prefixes could cause a problem.

In a CSS class you might have something like this:

.myClass {

   background: -moz-linear-gradient(-45deg, rgba(30,87,153,1) 0%, rgba(125,185,232,1) 100%); /* FF3.6+ */

   background: -webkit-gradient(linear, left top, right bottom, color-stop(0%,rgba(30,87,153,1)), color-stop(100%,rgba(125,185,232,1))); /* Chrome,Safari4+ */

   background: -webkit-linear-gradient(-45deg, rgba(30,87,153,1) 0%,rgba(125,185,232,1) 100%); /* Chrome10+,Safari5.1+ */

   background: -o-linear-gradient(-45deg, rgba(30,87,153,1) 0%,rgba(125,185,232,1) 100%); /* Opera 11.10+ */

   background: -ms-linear-gradient(-45deg, rgba(30,87,153,1) 0%,rgba(125,185,232,1) 100%); /* IE10+ */

   background: linear-gradient(-45deg, rgba(30,87,153,1) 0%,rgba(125,185,232,1) 100%); /* W3C */

}

This is fine for something declared in a CSS file. When parsing the CSS file the browser will just ignore all the other junk and find the syntax that works and ignores rest. When you try to do this with inline styles through Javascript, you’re having to manage a lot and cause quite a bit of work for the browser. Considering that this operation would happen hundreds of times over the course of my game, setting all these vendor prefixes were out of the question.

My first thought was “Hey – can Modernizr detect this?” Not really – at least not out of the box and Modernizr is pretty heavy if this is the only thing I’m doing. But I wanted some of this type of functionality. I know that when you try to set a style and the browser doesn’t understand it, it just ignores it. So, doing something like this in Mootools:

   $('someElement').setStyle('background','-notvalid-gradient(red to blue)');
   alert($('someElement').getStyle('background'));

Would result in a blank alert (not undefined or -notvalid-gradient(red to blue)) – expanding on this, I can figure out what syntax(es) are understood by the browser by testing each syntax once per session. I put together this jsfiddle to show how to detect CSS3 gradient syntaxes. You could even expand this to deal with other non-standard prefixes in a pinch.

A couple of notes – the order which this is evaluated is important – the webkit old syntax(-webkit-gradient) is evaluated before the current standard syntax – this means that only browsers that need the old syntax will use it. Also, the prefixless syntax is last – so in the future, when browsers support this, it will be used. This is also a relatively expensive test cycle – absolutely do this only once and cache the result to use throughout the session. Better yet, store it in a cookie or something so it doesn’t even need to be done each page load.

This entry was written by Kyle, posted on April 29, 2012 at 11:35 am, filed under css3, javascript. Leave a comment or view the discussion at the permalink and follow any comments with the RSS feed for this post.

OpenID is grand. I use it in m.easur.es and I use it for some internal tools. You don’t have spend time writing a user administration logic and users don’t have know another password/user name combination. However, it doesn’t come without it’s perils.

For my host, I use HostGator. It is cheap and reliable. On a shared plan, however, it does have a few limitations. One being that the use mod_security which limits a few things, things like URLs being passed in a GET query string.

I lost an entire night of my life debugging why, suddenly, my OpenID based project stopped working. It all started when I logged into one my tools and I got a WordPress 404 page. Why? I hadn’t the foggiest. My first thought was that WordPress was somehow seeing this tool (which is a sub-directory off of that blog) as a post and rewriting it. So, I made a few modifications and moved the tool to a subdomain. Then, it just wasn’t working. I would attempt to log into the tool and it would just send me back to the index page but keep the URL would have the OpenID return query string. WHY?!

I fired up Chrome Developers Tools and noticed that I was getting a 403/Forbidden in this situation. I remember, then, that I had some problems initially my first OpenID project to a production Host Gator server and giving 403/Forbidden page. This became so confusing because I later realized I didn’t have a 403 error page defined for that subdomain, so it was redirecting back to the /(root) of the domain but the URL remained the same. At least I knew what my problem was at this point.

At 5:00 in the morning today, I got in chat with a HostGator representative. An hour in, I realized that he had no idea what was going on. This happens. At this point he was confused and convinced that I was crazy as the page didn’t show a 403 error. I tried to explain it to him, but there was no point.

Later, I was able to build a small script and define a 403 page  to show the representative what was going on – I also asked if he understood OpenID, which he honestly responded that he didn’t. I took time to come up with a small script to show what is going on (just a html form on a php page that shows the results of $_GET – then you could see the 403 only when you passed a url).

Here are a few things that you should really do to prep for working with OpenID:

• Setup all your error pages
• Understand the security limitations you might be working with on your host
• Test
• Test again
• Check in to make sure things are working later
• Understand the flow of OpenID enough to where you can explain it to people

This entry was written by Kyle, posted on April 20, 2012 at 1:05 pm, filed under Uncategorized. Leave a comment or view the discussion at the permalink and follow any comments with the RSS feed for this post.

…about object and array comparison in Javascript.

Despite having produced a few projects that get the job done in Javascript, I’m never surprised when I find a quirk of the language. I am, however, surprised how it manifests in my code.

So, I am getting coordinates off of a multidimensional array. The coordinates are stored in an object something like this:


var newCoords = {'left':1,'bottom':4};
var oldCoords = {'left':1,'bottom':4};


Now, I’m trying to compare these two sets of coordinates I try

console.log((newCoords === oldCoords)); //I think this should return true


It returns false. Okay, so how about:


console.log((newCoords == oldCoords)); //I think this should return true


It returns false. Why, god, why?

In a language like PHP you can do this, as it turns out the Mozilla Developer Network article on Comparison Operators has an important line:

If both operands are objects, then JavaScript compares internal references which are equal when operands refer to the same object in memory.

So, the implications of this are that you can’t even compare arrays to see if they have same values because arrays are objects. You could compare the properties of the two objects manually, but that seems like a good way to repeat yourself. I found a nice little solution for arrays, but I’ve generalized it a bit to compare arrays or objects:

function areEqualObjects(firstObj,secondObj) {
        if(firstObj.length !== secondObj.length){
            return false;
        }
        for(var i = firstObj.length - 1; i >= 0; i--){
            if(firstObj[i] !== secondObj[i]){
                return false;
            }
        }
        return true; 
}

It isn’t exactly elegant but it gets the job done.

This entry was written by Kyle, posted on March 30, 2012 at 11:10 am, filed under javascript. Leave a comment or view the discussion at the permalink and follow any comments with the RSS feed for this post.

One theme of this blog has been to force my own hand to release work. In the past I’ve let stuff languish on my own little web server until I deemed it was perfect. And we all know how many perfect things exist.

I can’t say that I’ve been in a releasing cycle as-of-late, however I have been in an updating/refining cycle. I’ve updated both letter pile and m.easur.es to have pretty decent Internet Explorer functionality. They don’t look quite as nice as they do in a real browser, but it does open up a bigger user base.

In the past I’ve always dreaded this phase but Modernizr and JS Lint have reduced the pain. Modernizr eases the layout woes and JS Lint has really improved my code consistency and quality. IE seems to appreciate better JS.

On a side note, I’ve been traveling a lot on the weekends, I haven’t been letting this eat too much into my coding time, however. Train rides with wifi and some down time at the in-laws have been good to me and I may have some new stuff to show very soon.

This entry was written by Kyle, posted on March 17, 2012 at 8:54 am, filed under thoughts, tools, Uncategorized. Leave a comment or view the discussion at the permalink and follow any comments with the RSS feed for this post.