Chris Oliver

So one thing here is your set_forum_thread method is trying to do something that doesn't quite make sense. Your URL has an ID in it and that represents one single record, but you're using it to find two records. Really you want this to

Assuming you're using nested routes, you will have a URL like this: /forum_threads/:forum_thread_id/forum_posts/:id and you want to make sure you use the correct one of those params for looking up the different tables.

def set_forum_thread
  @forum_thread = ForumThread.find(params[:forum_thread_id])
end

It sounds like your forum_post.user.email isn't working. Your forum_post must not have had it's user_id set in the database. It looks like your controller is setting it properly, but you should check it out in the console to make sure it's actually saving it.

Sounds like your JS isn't sending over a token through to the server.

You can use the regular form field helpers like input_tag to make that easier.

Yep! Just like you would with a normal form. This one isn't really much different aside from it taking the credit card fields and handling them specially with JS. The JS will submit the form like normal, so your other fields will get treated just fine.

So ActionView::Template::Error (First argument in form cannot contain nil or be empty) means that when you call your form_for, one of the variables you passed in was nil. That means either forum_thread or forum_post in this was nil <%= form_for [@forum_thread, @forum_post] do |f| %>

It looks like you've got the before_action to set the forum_thread variable, but none on the edit action (or update) to set the forum_post. So most likely the forum_post is nil causing it to throw that error. Set that variable and you should be all set!

That form should work just fine for that. If they're submitting other information, for those fields you'll want to make sure they have the 'name' attribute so they get submitted (unlike the credit card fields). Aside from that, make sure you're permitting those extra params and that should probably do the trick.

It looks like in a couple of your controller actions, you're overwriting the variables incorrectly which might be the issue:

# show
@forum_posts = ForumThread.find(params[:id])
@forum_posts = ForumPost.paginate(:page => params[:page], :per_page => 3)

That first part there should probably be @forum_thread = ForumThread.find(params[:id]) so that you assign it the right name.

Then the second one, you need to reference that @forum_thread in order to use it's associated posts only. It should look like this: @forum_posts = @forum_thread.paginate(:page => params[:page], :per_page => 3)

I think if you get that fixed and any others like that, that should fix your issues with ActiveRecord.

Oh that's a super simple solution for paperclip. I love it!

That's a really great question. Personally, I like to either record example urls and JSON that the frontend devs can work with or I'll give them example code that works already that they can modify. It all kind of depends on the situation and what we're trying to accomplish. A lot of times we'll pair programming at that point to hand make sure we're both on the same page and the integration can work well between the two.

What issues are you guys running into with your approach?

So browser these days try to be helpful and not force downloads by default. The way you can get the old functionality is to set the Content-Disposition header on the request to attachment which will cause the browser to download the file instead of showing it embedded on the page.

I'm not entirely sure how you'll need to go about that, but it looks like you're able to add the header to S3 requests. http://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectGET.html

The best way is really to load up all the user's likes for those related objects in a single query. Then you can check those post against the likes result with Ruby and that will be 2 queries instead.

You'll have to do some custom SQL to pull off #2, but it's not so bad. Check this out: https://robots.thoughtbot.c...

Looks like they recently renamed these to "Aggregations". The SearchKick readme has some code there, but you'll have to adapt it for the UI. You'll want to render out the aggregation names as links and then pass those into the URL as params so you can pass them into the search query. I'll do an episode on this sometime soon!

Yeah, you could probably do a special route to the notification. It would mark as read and then redirect you to the actual item in the notification. Either that, or you could mark any notifications for the object loaded in the show actions.

Yes! Definitely an awesome topic to cover. Quick outline of what it would look like:

class Notification < ActiveRecord::Base
  belongs_to :user
  def mark_as_read
    update(read_at: Time.zone.now)
  end
end

You can look up the unread notifications for the nav, and send over an AJAX request to the Rails app to mark all those as read.

Hopefully able to do a screencast on this soon!

Check boxes make for great easy additions and you can hide/show them with some javascript based upon the plan that's selected.

My suggestion would be to make a pricing page that have links to the checkout page and you put a "plan" in the URL with the ID of the plan to sign them up with. That way you can store the plan_id in a hidden field in the form nicely.

Basically you're wanting to build a nested form, where you have one main item (the Order) and many nested items underneath it (the OrderItems). Cocoon is a cool little library that lets you dynamically add those nested items to the form. It might do what you're looking for: https://github.com/nathanvda/cocoon

You'll want to probably use an if statement there to send it without the subdomain option. I know you can include helpers into the mailers so that could be a nice place to put the logic for the subdomain option.

I saw that recently and haven't had a chance to use it yet, but it seems like a wonderful option. I think that'll be the way to go especially if it's a seamless experience. The one question I have is how database migrations are handled between promotions. The code's the easy part, but the db migrations can cause some trouble.