Chris Oliver

I'm using ActiveAdmin for most sites since it existed beforehand, but now I'm starting to use Administrate in production. Only real concerns with this over production use is that it hasn't existed for all that long to work out the basic bugs. Since it's pretty much scaffolds, you can pretty easily debug anything that would go wrong. The main downside right now is going to be a potentially quickly changing API that may be more than you would want to deal with maintenance wise.

You can setup Refile to cache some file metadata like the filename to your model. https://github.com/refile/r...

That should take care of showing the filename and then anytime the URL is clicked, then that's when Refile will download the file. Just displaying the link won't cause it to download the file just to render the filename in the link.

Nope, that should still work out of the box. Server side will just continue to set cookies, but will only match users available for the current tenant.

That's because the sinatra app (which Refile is referring to) gets mounted to your Rails app at /attachments. Rails basically routes the URL over to the Sinatra app, effectively so that the files never hit your Rails code. It just gets diverted before Rails would start processing it. And then files are served up from the same url because that's where the Sinatra app is.

That's actually how it's supposed to work actually because it provides you the ability to generate different image sizes on the fly. The downside to this is it requires you to setup a CDN so that it doesn't have to generate the image every single request. You can check out the readme for some more information on that.

Thanks for the heads up! I'll take a look and see what's up!

That's great to hear!

Heroku really only recommends the two lines for url and pool. The rest of that is all handled by Heroku. The DB_POOL may not be set, which will default it to 5 which is fine. You'll be able to easily change that as you scale up your Heroku servers.

I'd probably toss everything in db/seeds.rb. Check out the ffaker gem for creating fake names and things.

If you need to create Devise users, you can just do this (but you'll have to give them passwords)

# You can optionally generate a password if you don't want to hardcode the password
# generated_password = Devise.friendly_token.first(8)

User.create(email: "test@example.com", password: "password", password_confirmation: "password")

And for paperclip images, you can use the ruby File library to open the file and assign it.

img = File.open(File.join(Rails.root, 'image.png'))
User.first.update(avatar: img)

You can use Rails.root there as a helper to get the Rails directory, and then you can join in any folders and filenames you need to get the full path in Ruby. Then you open it as a File object and assign that to your paperclip attribute. That should do the trick!

What is the contents of your app/models/admin.rb file? It sounds like the Admin class isn't defined in there for some reason.

Great question. If you want to use the existing Admin model from devise, all you need to do is add before_action :authenticate_user! to your admin controllers to force the admin user to be logged in. That should be it!

Wow, that's awesome, I'm really glad it was helpful! :)

You definitely don't need a frontend framework for this, so no worries there. :)

You're looking at some functionality that's sort of like infinite scroll on an index page, but slightly different because you're scrolling through the next and previous items individual. It's kinda like you're viewing the show action and then scrolling into the next show action.

The best solution here is probably something custom. Similar to how Ryan Bates in his revised Railscasts episode builds infinite scroll from scratch, but you'll need to add a "next" and "previous" method to the model in order to grab the next record for the show action instead of the next page of results that would be on the index.

Really I think with some minor tweaks, you could take the code from his episode to pull this off. You'd basically update the JS response to do the pushstate and append to the page, and set a link to the next episode that you can use for looking up the next result (instead of using will_paginate there).

I'd definitely like to do a screencast on this, because it's something you see popping up quite often.

You'll actually want to just make sure it matches the column name I think. You can print out the row hash to the console to see exactly what you'll need for that.

Yes that works! You should use your version, not the merge for this.

You can actually just add that into your query. For example, if your published column was a boolean: Post.search('*',where:{published:true})

Ah, the good ol' pebkac. ;)

It's interesting that even with the firewall, they seem to still be getting through. Maybe it's not working? I'm not well brushed up on firewall rules as I should be, but does UFW basically do the same thing as setting iptables rules?

Also you may want to make sure your log files are being rotated with logrotate so they never become unwieldy in size. Doesn't really solve your problem of constant attack, but does prevent your files from getting huge.

That's a great idea. This is definitely something that I've been wanting to cover for a while, so I'll make it happen!

Hey JM,

I also added some code to remove that bell after you mark the messages as read. Once that AJAX call completes, the JS success callback just removes that div from the navigation. And that number is just the typical bootstrap CSS for the badge. You can inspect the HTML on the page to see what that looks like!