Chris Oliver

Looks pretty good. I think if you have the has_one and belongs_to associations setup on User and profile, I would modify your create like this:

    if resource.save
        resource.create_profile
    end

That'll be a little cleaner and easier to maintain.

For the destroy, it might make more sense to use a dependent: :destroy callback on the User models: has_one :profile, dependent: :destroy. This way anytime you destroy a user, you can also destroy their profile. It will happen automatically.

Yeah, when you use BlogPost.new, that's creating a new object without errors, so those obviously won't exist on a new one.

One solution is to go in your app/views/blog_posts/new.html.erb you'll want to make sure you use @blog_post so that it has the errors when it renders. This way it will try to save, when it fails, it will render blog_posts/new and you'll have the errors on the @blog_post object that you can render.

The other alternative would be to submit the form with JS and use that to display the errors.

Ah! So if you've got it on the application layout, that means you need to set the @blog_post variable on every page. You've got two approaches for this.

1. You can create a before_action :set_blog_post on ApplicationController so it runs on every action.
2. Or I realized you could modify your form like this (I'd recommend this approach in this case):

          <%= form_for(BlogPost.new) do |f| %>
            <% if f.object.errors.any? %>
              <div id="error_explanation">
                <h2><%= pluralize(@f.object.errors.count, "error") %> prohibited this post from being saved:</h2>

                <ul>
                <% f.object.errors.full_messages.each do |message| %>
                  <li><%= message %></li>
                                        <div class="col-sm-2  pull-left" id="socialize">
                                <p>I'm a social persons find me :<br>fb tw insta</p>

                                        </div>

                <% end %>
                </ul>
              </div>
            <% end %>

            <div class="field">
              <%= f.label :title %><br>
              <%= f.text_field :title %>
            </div>
            <div class="field">
              <%= f.label :description %><br>
              <%= f.text_area :description %>
            </div>
            <div class="field">
              <%= f.label :status %><br>
              <%= f.check_box :status %>
            </div>
            <div class="field">
              <%= f.label :category %><br>
              <%= f.text_field :category %>
            </div>
            <div class="field">
              <%= f.label :post_date %><br>
              <%= f.date_select :post_date %>
            </div>
            <div class="actions">
              <%= f.submit %>
            </div>
          <% end %>

What I did here was change @blog_post to f.object which is a reference to the BlogPost.new that you passed into the form_for originally. This way you won't need the @blog_post variable at all.

What does your controller look like?

For code blocks, you can write backticks ` around your content so that it shows up as code and doesn't get eaten. :)

```
code
```

Sounds like you just need to set your @blog_post variable in your controller action. Have you set that? You'll also need to modify your form_for to be form_for(@blog_post) to be consistent.

@blog_post = BlogPost.new

Hey Stan,

You'd actually just put an if statement in the JS. If the length of the notifications > 0, display them, else, render your placeholder.

Something like this (I haven't tested this, so it may have some bugs):

  handleSuccess: (data) =>
    items = $.map data, (notification) ->
      "<a class='dropdown-item' href='#{notification.url}'>#{notification.actor} #{notification.action} #{notification.notifiable.type}</a>"

    $("[data-behavior='unread-count']").text(items.length)

    if items.length == 0
      items = "<a>No new notifications</a>"

    $("[data-behavior='notification-items']").html(items)

Something like this should fix it:

desc "Fetch anime info"
task :fetch_anime_info => :environment do
 require "open-uri"
 require 'mechanize'

 Anime.all.each do |anime|
  season_scrape = doc.css('div#content .borderClass .js-scrollfix-bottom div:contains("Premiered")').text.split(' ')[1..-1]
  season_text = season_scrape.blank? ? "" : season_scrape.join(' ')

  season = Season.where(name: season_text).first_or_create
  anime.update(season: season)
 end
end

This way you'll look up the season to see if it exists, otherwise create a new one, and then you'll associate the anime to the season.

Hey Sacha, you would just want to use a where query to scope to a date range before calling to_csv on it. You may need to change it from all.each to scoped.each in order for Rails to respect the scope if it wants to override your where query. That should do it!

Updating the season through the association works well.

And a side note: That url with the UUID at the end is what happens when friendly_id already detects a duplicate.

That's a good question. Aside from a brute force approach, I'm not sure. What I would probably do is just query for the record, make a copy of the object with .dup, switch the tenant to the new one, save the duplicate in the new tenant, verify it exists, switch back to the old tenant and delete the old record (if necessary).

Always something like that, cascading into a bug showing up elsewhere. :) Glad you got it fixed!

Oh interesting. In that case, is your stripeToken nil?

First I would check to make sure that the user has a stripe_subscription_id saved in the record. You might be passing a nil in on accident.

That's actually my cat. :) He does some chirp-y sounding meows when he sees things outside like birds or squirrels. I'll have to let him in one of the videos soon.

I definitely will and thanks for the support! :D

Yeah! So normally with subscriptions, I listen to the charge.created webhook and save a copy of it to the database as a Charge record. That's like the example I use. The reason for needing the webhook is that subscriptions charge the user monthly and they don't have to initiate anything in your app.

For one-time charges, you can create a Charge object immediately during checkout and use that.

And if you want to store the receipt PDF files instead of generating them dynamically each time, you can save the file it generates to S3 and save it using Shrine or Carrierwave, etc and just link to that file from your view.

Ali, great suggestion. I definitely will do that. There are only a handful of important concepts you really need to know, and I agree, I haven't seen many videos that actually cover this from a high level. I'll make sure I get to this soon!

1. When the user registers, do you want to have them fill out some of the profile information as well? If so, then I would recommend updating the Devise form to be a nested form. That way you create both together at once using accepts_nested_attributes_for.

2. When Devise creates a user, it does actually sign them in as soon as they're persisted to the database (it would be weird if you registered and then had to login immediately).

3. Depends on what you want to accomplish really. If you want two things filled out at once, the above solution in #1 is great and pretty painless.

The other option is just to create a blank profile during the registration process if that's what you're looking for. In this case, I would override the Devise controller, copy the create action, and then add in code on the save part to also create and save your profile for the resource.

For example, you could modify the default create action to look like this which would provide an atomic method of creating both the user and the profile:

class Devise::RegistrationsController
  def create
    build_resource(sign_up_params)

    resource.save
    yield resource if block_given?
    if resource.persisted?

      # We know that the user has been persisted to the database, so now we can create our empty profile
      resource.create_profile!

      if resource.active_for_authentication?
        set_flash_message! :notice, :signed_up
        sign_up(resource_name, resource)
        respond_with resource, location: after_sign_up_path_for(resource)
      else
        set_flash_message! :notice, :"signed_up_but_#{resource.inactive_message}"
        expire_data_after_sign_in!
        respond_with resource, location: after_inactive_sign_up_path_for(resource)
      end
    else
      clean_up_passwords resource
      set_minimum_password_length
      respond_with resource
    end
  end
end
``

You got it man! 👍 🎉

I made a related episode on this. :) https://gorails.com/episodes/inviting-users-with-devise_invitable