Chris Oliver

Yeah, you'd want to change your DNS to point to the new IP once the site is ready. Before you do that, you can change the TTL down to the lowest time so your DNS records will only be cached for the minimum time making the new IP change happen quick.

With your database on another server, you won't have to migrate that so it should be a lot easier then. 👍 You can actually run both copies of the app at the same time and make sure they can connect to the db and then change the DNS as the final step.

You'll also want to make sure any SSL certs are copied over. Forgot about that too.

If you spun up a new server and deployed the app to it with Capistrano, really the only thing you'd need to move over are any file uploads and the database. You can dump the postgres database then upload and import it on the new machine. Same with the files. That would be really all there is to it.

@oomis, take a look at the Pundit episode. Since I wrote this, I've used the Pundit gem for authorization over CanCanCan. It's less confusing to me. https://gorails.com/episodes/authorization-with-pundit

Hey Stephen!

The way I do it in JumpstartRails.com is we have a single User everyone logs in as and they have multiple Accounts they're associated with.

Each account could have a type of Coach, Client, etc and they switch between them with a session cookie. When they switch, we use current_account to load the account and we could use that to determine if they should see Coach or Client views.

Yep, that's the built-in way. Sounds like your code doing the validation is strict about what type of object it is (a Hash) and that's the part that's not very Ruby-ish.

Ah, well you can always cast it to a hash with to_hash

It's the same. Strong params is just a Hash-like object so you don't have to do anything special to it. It's designed like that to work seamlessly but be secure.

Not with Apartment since they're in separate schemas. If you do row-based multitenancy you can. Check out acts_as_tenant. That's what we use for JumpstartRails.com and it's a lot more flexible and scales better.

Webpacker doesn't make require available in the browser window, so you have to set that explicitly.

window.toastr = require('toastr')

Working example here for you: https://github.com/excid3/rails_toastr_example

Example code I forgot to paste:

def toastr_flash
  flash.each_with_object([]) do |(type, message), flash_messages|
    type = 'success' if type == 'notice'
    type = 'error' if type == 'alert'

    text = <<~EOF
      <script>
        document.addEventListener("turbolinks:load", function() {
          toastr.#{type}('#{message}', '', { closeButton: true, progressBar: true })
        });
      </script>
    EOF
    flash_messages << text.html_safe if message
  end.join("\n").html_safe
end

Hey Tom,

That would be giving you the error because Javascript with inline script tags (that your helper is generating) are executed immediately. It does not wait for your webpacker Javascript to finish loading toastr before it runs. Hence the error.

You will want to wrap your code in a turbolinks:load event so that it waits until Turbolinks is ready and all your JS is loaded before it executes.

Yes! I've been meaning to get to that for a long time. ViewComponent is awesome.

Hey Tom,

You'll have to share what you've got so we can help. If you can push up a repo to github, that would be most helpful. Otherwise just post your steps to reproduce the issue and we'll get you sorted. 👍

It's pretty simple and the only things that would affect it are possibly major Rails versions, so there aren't many changes to be made to it.

@Howard OLeary, if you want schema based multitenancy, sure. It's still the best bet for that.

I more often do row-based multitenancy. That's what we do in the JumpstartRails.com template. The ActsAsTenant gem is pretty good for that.

Probably need to do some more work with pgsearch. 👍

Weird, you'd think they'd prompt for the username / password!

RSS is working just fine for me. What do you mean it no longer works?

Hey Nelson,

You should be able to listen to the change event on the file field. That fires anytime the input value changes. Use that to fire off the form submit.

Hey Rick,

Absolutely. If you can imagine it, you can build it. For following hashtags, you'd want to create a model for the Hashtag and then very similar to following users, you'd create a model to join the two records. I'd call it UserHashtag or something and just belongs_to :user and belongs_to :hashtag