Chris Oliver

You'll have to check your Rails logs in production to see what the error is. There error isn't necessarily related to this code, but it could certainly be. Whatever error is in the logs will give you insight as to what's going wrong.

There's nothing special to these gems especially considering jquery-rails shipped with Rails every single release between like 3.1 and 5.0. GoRails itself uses that and the bootstrap-sass gem.

Yep, you're spot on. Basically what you did was replicate the setup from Rails 5.0 or earlier to a T. With jQuery being a dependency of the Bootstrap JS, you just include jQuery ahead of the bootstrap JS.

You don't need the jquery_ujs file because that's for handling the remote: true things which is done with the new Rails ujs that doesn't need jQuery. It doesn't really make much difference in this case, but using the new rails_ujs will be better going forward.

Until Bootstrap removes jQuery as a dependency, this is pretty much the way to go.

Hey Ernesto, yeah it sounds like the JS is running on document ready, but not turbolinks load (which is run every single time you visit another page since turbolinks fakes those second page requests).

This is the case from the example because of this code:

jQuery ->
  new Notifications

The jQuery -> is a function for saying when the document is ready, then run this code.

If you change it to this it will work on every turbolinks page:

$(document).on 'turbolinks:load', ->
  new Notifications

Hmm, hard to say. I would start by inspecting the HTML and then stepping through the JS code line by line and making sure those are working as expected. You'll figure it out pretty quickly if you break it down and find the spot that's not working like you want it.

Doh. I still got notified. It ain't done yet! :)

Awesome. I just muted this thread so next post in here I shouldn't receive an email...feel free to post a reply to test it. :)

Alrighty, it's live (and hopefully all working!).

You can find it on the left side underneath the categories. I should probably put it in a better spot, but hey, I'm no designer yet. 😜

Agreed, this is something I've been meaning to build for a long time. At this point I question whether or not I should have just used Thredded instead, but it's fairly late now. :P.

I think I'll be adding the ability for you to both subscribe and unsubscribe from threads. Since you're kind of automatically subscribed by posting in a thread, it'd be nice to unsubscribe as well.

Agreed. :) I'm going to update the list to include the durations shortly.

And yeah, my ideal length is 15-20 minutes, but because the audience is a wide range of beginner to advanced Rails devs, it's hard to cover everything in that time. I should probably start splitting episodes up into two parts to handle that better.

Makes sense. Well if you're using friendly_id, the only ID that users will see will be the slug, not the database ID. As long as you don't have a count as part of your slug you'll be fine. You can even have it generate a random string for the slug if you want.

Yep, something like that could work. That should print out true or false in the data attribute (you can inspect the html to verify) and sure give you back a Javascript boolean you can use when you query for it.

Yeah I think you're correct.

From the Rails guides:

In order to run your tests, your test database will need to have the current structure. The test helper checks whether your test database has any pending migrations. It will try to load your db/schema.rb or db/structure.sql into the test database. If migrations are still pending, an error will be raised. Usually this indicates that your schema is not fully migrated. Running the migrations against the development database (bin/rails db:migrate) will bring the schema up to date.

If there were modifications to existing migrations, the test database needs to be rebuilt. This can be done by executing bin/rails db:test:prepare.

Yeah, db:schema:load will load whatever is in the schema.rb file. You could have migrations that haven't been run yet and as such, they wouldn't show up in your schema or after a load.

Your migrations are just records of changes to the database but that doesn't mean it has recorded all changes to the database correctly (you can write broken migrations), so the schema.rb is actually a generated map of the actual database setup.

The schema is everything that the database currently contains has regardless of what your migrations say. Plus the schema is cached so you can keep track of it independently and use it for quicker setups of databases in development and test environments.

I don't think there's any migration related changes in 5.1, so if it works with 5.0 it should work with 5.1 no problem.

Hmm, my main question is why do you want to hide the ID from the form?

I'd recommend friendly_id. You don't have to override to_param with it and you can simply define the attributes you want as candidates for the ID in case there's some conflicts:

class Restaurant < ActiveRecord::Base
  extend FriendlyId
  friendly_id :slug_candidates, use: :slugged

  # Try building a slug based on the following fields in
  # increasing order of specificity.
  def slug_candidates
    [
      :name,
      [:name, :city],
      [:name, :street, :city],
      [:name, :street_number, :street, :city]
    ]
  end
end

I've used friendly_id for years and it hasn't let me down once. It's what I'm using on GoRails as well for the forum urls too.

Hey Anand,

Generally people store the JWTs client side in LocalStorage. It's like a local database stored in the browser so you can just stash it there and retrieve it later. It functions similar to cookies but you have to manually save it yourself rather than the browser taking care of cookie storage automatically for ya.

You'd be best off making a controller for it. Something like

resources :documents do
  resources :document_attachments
end

Then you can have that sub-controller for those DocumentAttachment records and can scope them to the document. And from there you can add the destroy action to lookup the Document, the DocumentAttachment, and then destroy it.

As you might have noticed, deleting files has pretty much nothing to do with Refile itself. Refile installs callbacks so that when you delete the database record, it will automatically delete the file along with it. So really you are doing just normal model deletes and Refile is just coming along for the ride.

I wasn't planning to dive more into it, but I could be persuaded.

As far as multiple models, there's nothing special other than including the acts_as_messageable on them I think. See: https://github.com/mailboxe...

For different conversation types, you can probably add a column to the mailboxer_conversations table for the conversation_type and then you'd just have to create the Conversation record with that extra attribute. You may either need to create conversations directly through Mailboxer::Conversation model or you might do a send_message and then update the Mailboxer::Conversation record with the conversation_type after it has been created. I'm not sure which the best solution would be there but you can experiment with both and see what's cleanest / easiest. All in all that shouldn't be too bad.

I think you have a typo. It's user_signed_in? not user_signed_in. That should do the trick!

if user_signed_in?
  layout 'admin_lte_2'
else 
  layout 'some_other_layout'
end