Bugs Fixed
Things added
I also ran across another respond_to gotcha when testing. It appears that the functional test get, post, etc. methods don’t create mime-type headers correctly by default. That causes respond_to to handle the request in the order that’s listed. So if you have a test like:
get :edit, :id => 4
and your action is like:
def edit
#do stuff
respond_to do |wants|
wants.js
wants.html
end
end
The response during testing will be to render the edit.rjs response. During an actual browser request the proper edit.rhtml will be rendered. Flipping the order of wants.js and wants.html will fix the test.
When using IE or Safari to request a page by changing a document’s location (either through document.location or location.href) the respond_to method will act as if this is a js request. In other words an AJAX request. This was the case even if I changed to a page that simply caused a redirect to another page. This was causing a problem because I had an action that would render either a page or a part of a page depending if they were on the site or using a bookmarklet.
To get around it I had to fall back to using request.xhr? which accurately tells where the request was coming from. So keep this in mind if you’re using javascript to cause the browser to get pages.
There’s no real party but 0.9 has been released. This release is huge! It brings
And some minor updates as well. Mostly just updates to support the new major additions.
This update required a password reset for all users. You should have received an email to the password rest page. If not, go to the login page and click “Forgot Password”
ENJOY!
So Rails 1.2.1 (now 1.2.2) was released a few weeks ago and railsplayground updated. Well I got caught with my pants down. The site was down because it doesn’t play well with 1.2 and I didn’t see this until I needed a solution. I knew about freeze but only in the edge, play with future rails, way.So I went about trying to fix it and found that my particular error was caused by the Engines plugin. So I went to check that site out and found out that the Login engine was discontinued. Well, that was a problem, so I just froze at an old version of rails. Had some trouble with freezing on the server thought. It was missing files and that’s why the site wouldn’t load today.I uploaded the vendor/rails directory from home and now we’re back in business.
Well wishlist just got through it’s 2nd Christmas, 1st “real” Christmas(i.e. more than 3 people) and for the most part it was successful!
The successful group of people were able to all pick gifts for each other with out having to ask “what do you want?” and basically giving it away. I have to say even though I know what is on my list this is the first year I wasn’t able to guess what I was getting. I swear there were a few surprises! (If you’re subscribed to my list you’ll notice the wii is gone…)
The unsuccessful group was someone who only put 3 things on their list, one of which was something way out of anyone’s price range. So that left two things. The one that I picked was of course the one that he also told his Dad to get, and he did.
Yes, I know, “Why wasn’t he using wishlist?”. Well, the person in question claims that it’s too complex to use. I certainly don’t think that’s the case, and if it is I’d like to know how to improve it. I really want this to be so simple anyone can use it.
Well in the end I was paid a couple complements that were nice and I got a request for comments on items. This is something I planned for and should be pretty easy, so keep an eye out.
Yeah, so I didn’t really test the rewrite of the button generating code, and of course it was broken. When user A put something on hold or purchased for user B, subscribed user C viewing B’s page would crash.
I hope we all learn the value of writing tests AND not refactoring a major part of the code without writing test cases first. 
I just pushed another update. This is for “unactivating” items in your list so that you can effectively remove them from your list and tag cloud without deleting them. This is useful if you tell someone to get you something on your list and that person isn’t using the site, or if you know a new version is coming out and you want to hold off on it until that version comes out.
I just pushed a small group of changes. Most will be unnoticed because they are parts of features not completely ready for consumption.
So I’ve been asked how I got this blog installed when I was running a rails app on my site since the blog directory gets made in /railsapp/public/blog. Well it was pretty simple, here’s how:
Log in to your control panel. Should be http://[domain]/cpanel
Create a subdomain by clicking on the “Subdomains” icon.
This will show your current subdomains. Enter “blog” in the text box and pick your domain. It defaults to your RailsPlayground domain. Click Add.
(I can’t remember if it asks where to create the root directory, if it does leave it at the default of railsapp/public/blog)
This takes a few seconds to minutes but will let you know when the subdomain has been created. When it’s done go back to your cpanel home page.
Now scroll down to the bottom and on the right there will be an icon of a blue smiley face labeled “Fantastico”. Click this.
This is a listing of scripts that you can install for your site. Find WordPress under blogs on the left and click the link. This will open a description on the right. Click on “New Installation”
This will ask you where to install it. Select the subdomain you created above and it should default to your subdomain folder (Which is going to be /railsapp/public/, in our case “blog”)
It will then ask for an admin user/password combo. And then let you know that it is done installing.
Now, open up your favorite ssh app and log into your site. If you get a message telling you the shell is disabled, contact support with your railsplayground domain name and they’ll set it up for you.
Now cd railsapp/public and with your favorite *nix editor open .htaccess. I use Vi, so you know that’s there at least.
Theres a section commented out that says something like “use the following so Apache won’t rewrite requests”, under that there is a commented out RewriteCond and RewriteRule. Uncomment these by removing the #
Change those two to this:
RewriteCond %{HTTP_HOST} ^blog.$ [NC] RewriteRule .* - [L]
This will tell Apache to not rewrite any requests that look like blog.[your domain]. You might want to scroll down and change dispatch.cgi to dispatch.fcgi while you’re in here if you haven’t already.
You should now be able to hit blog.[your domain] and see the WordPress home page