RefineryCMS image thumbnails not showing up - ruby-on-rails

I've got a RefineryCMS 3 application and in the backend the thumbnails for uploaded images are not showing up.
If I run the app in production mode on my development machine then the thumbnails show up. On the production machine the rails app is ran through passenger & apache and it fails.
I have copied my development copy to the production server for a test and ran the refinery project in development mode and I still get the same issue
rails s -b 192.168.200.215
Here is the standard output when I try and load the images area in refinery admin;
Started GET "/refinery/images" for 192.168.200.4 at 2016-03-01 15:32:25 +1100
Processing by Refinery::Admin::ImagesController#index as HTML
Parameters: {"locale"=>:en}
Refinery::Authentication::Devise::User Load (0.2ms) SELECT "refinery_authentication_devise_users".* FROM "refinery_authentication_devise_users" WHERE "refinery_authentication_devise_users"."id" = ? ORDER BY "refinery_authentication_devise_users"."id" ASC LIMIT 1 [["id", 1]]
Refinery::Authentication::Devise::Role Load (0.1ms) SELECT "refinery_authentication_devise_roles".* FROM "refinery_authentication_devise_roles" INNER JOIN "refinery_authentication_devise_roles_users" ON "refinery_authentication_devise_roles"."id" = "refinery_authentication_devise_roles_users"."role_id" WHERE "refinery_authentication_devise_roles_users"."user_id" = ? [["user_id", 1]]
Rendered /var/lib/gems/2.1.0/gems/refinerycms-acts-as-indexed-2.0.1/app/views/refinery/acts_as_indexed/admin/_search_header.html.erb (0.2ms)
Rendered /var/lib/gems/2.1.0/gems/refinerycms-core-3.0.1/app/views/refinery/admin/_search_header.html.erb (4.4ms)
(0.2ms) SELECT COUNT(*) FROM "refinery_images"
CACHE (0.0ms) SELECT COUNT(*) FROM "refinery_images"
Refinery::Image Load (0.3ms) SELECT "refinery_images".* FROM "refinery_images" ORDER BY updated_at DESC LIMIT 20 OFFSET 0
Refinery::Image::Translation Load (0.3ms) SELECT "refinery_image_translations".* FROM "refinery_image_translations" WHERE "refinery_image_translations"."refinery_image_id" IN (2)
Rendered /var/lib/gems/2.1.0/gems/refinerycms-images-3.0.1/app/views/refinery/admin/images/_grid_view.html.erb (10.3ms)
Rendered /var/lib/gems/2.1.0/gems/refinerycms-images-3.0.1/app/views/refinery/admin/images/_images.html.erb (14.5ms)
Rendered /var/lib/gems/2.1.0/gems/refinerycms-images-3.0.1/app/views/refinery/admin/images/_records.html.erb (33.7ms)
Rendered /var/lib/gems/2.1.0/gems/refinerycms-acts-as-indexed-2.0.1/app/views/refinery/acts_as_indexed/admin/_search.html.erb (2.2ms)
Rendered /var/lib/gems/2.1.0/gems/refinerycms-core-3.0.1/app/views/refinery/admin/_search.html.erb (4.8ms)
Rendered /var/lib/gems/2.1.0/gems/refinerycms-images-3.0.1/app/views/refinery/admin/images/_actions.html.erb (17.0ms)
Rendered /var/lib/gems/2.1.0/gems/refinerycms-images-3.0.1/app/views/refinery/admin/images/index.html.erb within layouts/refinery/admin (61.1ms)
Rendered /var/lib/gems/2.1.0/gems/refinerycms-core-3.0.1/app/views/refinery/_html_tag.html.erb (0.2ms)
Rendered /var/lib/gems/2.1.0/gems/refinerycms-core-3.0.1/app/views/refinery/admin/_javascripts.html.erb (159.9ms)
Rendered /var/lib/gems/2.1.0/gems/refinerycms-core-3.0.1/app/views/refinery/admin/_head.html.erb (232.9ms)
Rendered /var/lib/gems/2.1.0/gems/refinerycms-core-3.0.1/app/views/refinery/_site_bar.html.erb (3.4ms)
Rendered /var/lib/gems/2.1.0/gems/refinerycms-core-3.0.1/app/views/refinery/admin/_menu_item.html.erb (28.4ms)
Rendered /var/lib/gems/2.1.0/gems/refinerycms-core-3.0.1/app/views/refinery/admin/_menu.html.erb (31.9ms)
Rendered /var/lib/gems/2.1.0/gems/refinerycms-core-3.0.1/app/views/refinery/_no_script.html.erb (0.3ms)
Rendered /var/lib/gems/2.1.0/gems/refinerycms-core-3.0.1/app/views/refinery/_message.html.erb (0.1ms)
Completed 200 OK in 375ms (Views: 362.0ms | ActiveRecord: 1.1ms)
Started GET "/system/images/W1siZiIsIjIwMTYvMDMvMDEvN3lmN3ZpNDRtZV9hYWEuanBnIl0sWyJwIiwidGh1bWIiLCIxMzV4MTM1I2MiXV0/aaa.jpg?sha=7a0325c4ef12ef3d" for 192.168.200.4 at 2016-03-01 15:32:27 +1100
When it tries to get the /system/images/.... it fails in the web browser console. If I try and access that directly with the following
http://192.168.200.215:3000/system/images/W1siZiIsIjIwMTYvMDMvMDEvN3lmN3ZpNDRtZV9hYWEuanBnIl0sWyJwIiwidGh1bWIiLCIxMzV4MTM1I2MiXV0/aaa.jpg
I get the following error in the browser
Internal Server Error

The production server didn't have imagemagick installed.
sudo apt-get install imagemagick
This fixed it.

Related

Update Rails to Hotwire Gives a 304

I've updated a Rails '6.0.3' app to use hotwire-rails rather than turbolinks and am getting a 304 for the response with no update to the view within the turbo_frame_tag
I created a new Rails app from scratch and implemented hotwire successfully so I'm guessing the issue is with residual Javascript in my existing app.
Server request
The server request matches that of the new app so it doesn't appear to be the issue, note the 200 status code.
Started GET "/models/1/edit" for ::1 at 2021-01-18 13:33:22 +1100
Processing by ModelsController#edit as TURBO_STREAM
Parameters: {"id"=>"1"}
User Load (0.2ms) SELECT "users".* FROM "users" WHERE "users"."id" = $1 ORDER BY "users"."id" ASC LIMIT $2 [["id", 2], ["LIMIT", 1]]
Model Load (0.1ms) SELECT "models".* FROM "models" WHERE "models"."id" = $1 LIMIT $2 [["id", 1], ["LIMIT", 1]]
↳ app/controllers/models_controller.rb:15:in `edit'
Rendering models/edit.haml
Rendered models/edit.haml (Duration: 1.1ms | Allocations: 1500)
Completed 200 OK in 4ms (Views: 1.3ms | ActiveRecord: 0.3ms | Allocations: 4244)
Browser
The browser response seems to be identical except for the status code being 304 rather than 200 and obviously no view change rendered.
Steps to recreate
Existing Rails '6.0.3' app
Update Gemfile to remove tubolinks and webpacker
trash app/javascript
trash node_modules/**
rails hotwire:install
Extra info
When I ran rails hotwire:install I get a File unchanged! The supplied flag value not found! app/assets/config/manifest.js message - I've checked the file and it's identical to the one generated in the new app.

Rails. First request slow, times out (40sec), the next ones are faster (1.5 sec). No custom caching, how can that be?

I moved an app from the bamboo stack to cedar and the server is behaving wierdly, it times out on the first request, taking 40sec according to the logs, while the next, same request, takes 1.5 sec. You would think the dyno slept, but I've got 2-3 dynos (using hirefire), and 3 workers.
rails 3.2
ruby 1.9.3
heroku cedar
heroku postgres crane
MongoDB, MongoHQ large
mongo_mapper 0.11.1
thin
no caching
It's an app with low user interaction, as it's mostly a huge background worker tool. The clients using it are few, but important, I obviously can't have the app timing out every morning or after lunch. You'd hate it too.
➜ my_app git:(master) ✗ heroku logs -t -p web --remote production
first request after some inactivity 40880ms
Started GET "/my_model" for xx.160.183.xxx at 2013-10-31 15:19:34 +0000
Processing by MyModelsController#index as HTML
User Load (6.8ms) SELECT "users".* FROM "users" WHERE "users"."id" = 110237164 LIMIT 1
MyModel Load (12.0ms) SELECT "my_model".* FROM "my_model" ORDER BY name ASC
Rendered my_model/_my_model_statuses.html.erb (3515.6ms)
Rendered my_model/_my_model_statuses.html.erb (3514.8ms)
Rendered my_model/_my_model_statuses.html.erb (3210.6ms)
Rendered my_model/_my_model_statuses.html.erb (3968.4ms)
Rendered my_model/_my_model_statuses.html.erb (2652.0ms)
Rendered my_model/_my_model_statuses.html.erb (2253.5ms)
Rendered my_model/_my_model_statuses.html.erb (1339.7ms)
Rendered my_model/_my_model_statuses.html.erb (1333.0ms)
Rendered my_model/_my_model_statuses.html.erb (2901.9ms)
Rendered my_model/_my_model_statuses.html.erb (636.3ms)
Rendered my_model/_my_model_statuses.html.erb (1598.6ms)
Rendered my_model/_my_model_statuses.html.erb (10.1ms)
Rendered my_model/_my_model_statuses.html.erb (909.3ms)
Rendered my_model/_my_model_statuses.html.erb (911.5ms)
Rendered my_model/_my_model_statuses.html.erb (1435.4ms)
Rendered my_model/_my_model_statuses.html.erb (1043.9ms)
Rendered my_model/_my_model_statuses.html.erb (1712.3ms)
Rendered my_model/_my_model_statuses.html.erb (793.8ms)
Rendered my_model/_my_model_statuses.html.erb (290.2ms)
Rendered my_model/_my_model_statuses.html.erb (1142.0ms)
Rendered my_model/_my_model_statuses.html.erb (342.6ms)
Rendered my_model/_my_model_statuses.html.erb (376.0ms)
Rendered my_model/_my_model_statuses.html.erb (2161.8ms)
Rendered my_model/_my_model_statuses.html.erb (1194.9ms)
Rendered my_model/_my_model_statuses.html.erb (1293.4ms)
Rendered my_model/_my_model_overview.html.erb (40695.0ms)
Rendered my_model/index.html.erb within layouts/application (40721.5ms)
Rendered shared/_menu.html.erb (1.0ms)
Rendered shared/_usermenu.html.erb (2.3ms)
Rendered shared/_header.html.erb (27.1ms)
Rendered shared/_messages.html.erb (0.1ms)
Rendered feedbacks/_new.html.erb (15.8ms)
Completed 200 OK in 40880ms (Views: 40856.2ms | ActiveRecord: 18.8ms)
It's a table, where each row is a partial, extracted so that I could see what took time.
Here it is after the timeout. 1398ms
Started GET "/my_models" for xxx.160.183.xxx at 2013-10-31 15:21:18 +0000
Processing by MyModelsController#index as HTML
User Load (2.4ms) SELECT "users".* FROM "users" WHERE "users"."id" = 110237164 LIMIT 1
MyModel Load (3.2ms) SELECT "my_models".* FROM "my_models" ORDER BY name ASC
Rendered my_models/_my_model_statuses.html.erb (87.7ms)
Rendered my_models/_my_model_statuses.html.erb (25.5ms)
Rendered my_models/_my_model_statuses.html.erb (35.7ms)
Rendered my_models/_my_model_statuses.html.erb (107.8ms)
Rendered my_models/_my_model_statuses.html.erb (163.9ms)
Rendered my_models/_my_model_statuses.html.erb (26.2ms)
Rendered my_models/_my_model_statuses.html.erb (26.3ms)
Rendered my_models/_my_model_statuses.html.erb (19.3ms)
Rendered my_models/_my_model_statuses.html.erb (121.4ms)
Rendered my_models/_my_model_statuses.html.erb (62.6ms)
Rendered my_models/_my_model_statuses.html.erb (94.9ms)
Rendered my_models/_my_model_statuses.html.erb (8.2ms)
Rendered my_models/_my_model_statuses.html.erb (19.1ms)
Rendered my_models/_my_model_statuses.html.erb (15.8ms)
Rendered my_models/_my_model_statuses.html.erb (59.9ms)
Rendered my_models/_my_model_statuses.html.erb (20.6ms)
Rendered my_models/_my_model_statuses.html.erb (78.8ms)
Rendered my_models/_my_model_statuses.html.erb (25.3ms)
Rendered my_models/_my_model_statuses.html.erb (13.3ms)
Rendered my_models/_my_model_statuses.html.erb (130.1ms)
Rendered my_models/_my_model_statuses.html.erb (9.7ms)
Rendered my_models/_my_model_statuses.html.erb (11.1ms)
Rendered my_models/_my_model_statuses.html.erb (92.0ms)
Rendered my_models/_my_model_statuses.html.erb (51.6ms)
Rendered my_models/_my_model_statuses.html.erb (23.1ms)
Rendered my_models/_my_models_overview.html.erb (1385.7ms)
Rendered my_models/index.html.erb within layouts/application (1386.3ms)
Rendered shared/_menu.html.erb (0.3ms)
Rendered shared/_usermenu.html.erb (0.6ms)
Rendered shared/_header.html.erb (1.5ms)
Rendered shared/_messages.html.erb (0.0ms)
Rendered feedbacks/_new.html.erb (1.5ms)
Completed 200 OK in 1398ms (Views: 1388.8ms | ActiveRecord: 5.5ms)
I'm not using any explicit cache, just plain Rails ActiveRecord to populate the table. Locally it's not like this at all. Heroku support recommends concurrency and caching, which is for a high-traffic app. This is a low-traffic app, a tool. They haven't commented on the bamboo vs cedar topic so I'm reaching out here in case anybody learns things I'm not aware of.
In both cases DB < 20 ms, so this is all CPU stuff, rendering templates.
It's how heroku handles resources. It's called dyno-idling and they released this about it last year: https://devcenter.heroku.com/articles/dynos#dyno-idling.
The heorku way to fix it is to pay for an extra dyno, then it will run all the time. But you can also use ping services to ping your site. Some will do it every hour, some every fifteen minutes and some once a minute. That will keep your dyno active and your thin server always "awake"
Yeah... I'll share instead of deleting the question. Hopefully my mistakes will help somebody get to the bottom of this faster.
The problem was with a mongodb query. Not sleeping dynos or services. Simply my own code.
It as Very confusing as MongoHQ has a "Slow queries" page that reported "no slow queries". I'd like to applaud Matt McCay for the excellent support and respectful approach, despite this being a (yet another?) "user error". He showed me the mongodb logging that showed this:
Tue Nov 5 22:59:46.722 [conn2335303] query myapp-production.day_reports query: { $query: { my_model_id: 2147259060, some_unindexed_field: { $gt: 0 } }, $orderby: { some_index_timestamp: -1 } } ntoreturn:1 ntoskip:0 nscanned:775 scanAndOrder:1 keyUpdates:0 locks(micros) r:7474265 nreturned:0 reslen:20 7474ms
Tue Nov 5 22:59:49.439 [conn2335303] query myapp-production.day_reports query: { $query: { my_model_id: 2147259071, some_unindexed_field: { $gt: 0 } }, $orderby: { some_index_timestamp: -1 } } ntoreturn:1 ntoskip:0 nscanned:502 scanAndOrder:1 keyUpdates:0 locks(micros) r:2570470 nreturned:0 reslen:20 2570ms
Show just two of many (30) in the same query. Note the 7474ms and 2570ms
I wonder why these wouldn't be listed as "slow queries" in MongoHQ... Let this be a warning to not let yourself be fooled or blinded by that.
Solution: In my case, I solved this by denormalizing, I saved the calculated value on my model on each write. I could have used indexes too, it would have been really fast, but in this case the models I read are in PostgreSQL and with the denormalization I wouldn't need to connect to MongoDB at all - on this particular request.
Why was it so much faster on the following queries?
The answer is found here: http://docs.mongodb.org/manual/faq/fundamentals/#does-mongodb-handle-caching
MongoDB saves/caches the last fetched data, in RAM.
How should I have troubleshooted this, ideally?
Isolate and eliminate. I should have plugged in and out both heroku postgresql and mongohq to rule them out. The "slow first time, fast after" made me fixate on server issues, I should know better.
Study the logs more thoroughly.

Any way to keep each request separate in the Rails log?

I'd like to have the logs from each request be grouped together and easy to tell apart from another request's logs, eg
**********************
Started GET "/" for 67.205.67.76 at 2013-09-15 00:05:15 -0700
Processing by RootController#index as HTML
Rendered root/_index.html.erb within layouts/application (7.0ms)
Rendered layouts/_fonts_hack.html.erb (0.0ms)
Rendered layouts/_ie_version_vars.html.erb (0.0ms)
Rendered topbars/_logged_out_topbar.html.erb (2.0ms)
Rendered layouts/_old_browser_warnings.html.erb (0.0ms)
Completed 200 OK in 27ms (Views: 26.0ms | ActiveRecord: 0.0ms)
**********************
Started GET "/" for 67.205.67.76 at 2013-09-15 00:05:15 -0700
Processing by RootController#index as HTML
Rendered root/_index.html.erb within layouts/application (7.0ms)
Rendered layouts/_fonts_hack.html.erb (0.0ms)
Rendered layouts/_ie_version_vars.html.erb (0.0ms)
Rendered topbars/_logged_out_topbar.html.erb (2.0ms)
Rendered layouts/_old_browser_warnings.html.erb (0.0ms)
Completed 200 OK in 27ms (Views: 26.0ms | ActiveRecord: 0.0ms)
***********************
Is something like this possible? sometimes in my logs currently its kind of hard to visually see where one request begins and another ends, and sometimes logs from different requests get interspersed.
A better option would be to use the request uuid
config.log_tags = [:uuid]
Doesnt seem like it from what I can tell, but next best thing: add Pid and Thread object_id tags to each log, then search for and highlight a particular tag once you get to the start of a request, and then all the highlighted lines will be the ones in your request.
config.log_tags = [ lambda {|r| "#{Process.pid}##{Thread.current.object_id}" } ]

slow post request RoR

I've a problem with a slow post request in a RoR app.
the project is a distribuited system wher the client send a lot of photos and the server save those in DB.
I use MySql server 5.1, both client and the server are in the same local network and they are programmer in RoR....
the client send 10 photo in a single request. the 10 photos are send in an array structure in yaml format.
the request is:
res = Net::HTTP.post_form(uri, :mac => 'String', :value => 'Yaml_array_images_data', :num => 10)
and the log says:
`Started POST "/events/save_photo" for 192.168.0.113 at 2012-03-30 09:45:10 +0200
Processing by EventsController#save_photo as */*
Parameters: {"data_type"=>"image", "value"=>"--- \n- !binary |\n /9j/2wCEAAoH
BwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYI...", "created_at"=>"--- \n- 2012-03-30 09:26:29 +02:00 \n-....", "mac"=>"00606E91E5D2"}
(0.3ms) SET PROFILING=1
Device Load (1.2ms) SELECT SQL_NO_CACHE `devices`.* FROM `devices`
WHERE `devices`.`mac` = '00606E91E51E' LIMIT 1
CACHE (0.0ms) SELECT `devices`.* FROM `devices` WHERE `devices`.
`mac` = '00606E91E51E' LIMIT 1
(0.3ms) BEGIN
SQL (2.9ms) INSERT INTO `multimedia` (`created_at`, `data`, `eve
nt_id`, `updated_at`) VALUES ('2012-03-30 07:45:00', x'f22b19237b63f1c8c40da49ae
5eb68969dd3cf28193ba6a3704fe2f286494439eea4f9071bb6ef9de530ccaaab235a402e2d94aad
2f4f1b90df022c23078f543bc6ca1c6fe8b17af45eae865bb....)
(0.3ms) SET PROFILING=1
Device Load (1.2ms) SELECT SQL_NO_CACHE `devices`.* FROM `devices`
WHERE `devices`.`mac` = '00606E91E51E' LIMIT 1
CACHE (0.0ms) SELECT `devices`.* FROM `devices` WHERE `devices`.
`mac` = '00606E91E51E' LIMIT 1
(0.3ms) BEGIN
SQL (2.9ms) INSERT INTO `multimedia` (`created_at`, `data`, `eve
nt_id`, `updated_at`) VALUES ('2012-03-30 07:45:00', x'f22b19237b63f1c8c40da49ae
5eb68969dd3cf28193ba6a3704fe2f286494439eea4f9071bb6ef9de530ccaaab235a402e2d94aad
2f4f1b90df022c23078f543bc6ca1c6fe8b17af45eae865bb...)
(44.0ms) COMMIT
(0.3ms) BEGIN
SQL (0.8ms) INSERT INTO `events` (`created_at`, `data_type`, `devic
e_id`, `element_id`, `multimedia_id`, `name`, `status`, `updated_at`, `value`) V
ALUES ('2012-03-30 07:45:00', 'image', 19, 413397, 1066303, 'photo', NULL, '2012
-03-30 07:45:11', '--- 0\n...\n')
(38.2ms) COMMIT
(0.3ms) BEGIN
SQL (2.9ms) INSERT INTO `multimedia` (`created_at`, `data`, `eve
nt_id`, `updated_at`) VALUES ('2012-03-30 07:45:01', x'f22b19237b63f1c8c40da49ae
5eb68969dd3cf28193ba6a3704fe2f28...)
....
for 10 times insert a record in multimedia and one in events table
...
(33.0ms) COMMIT
(0.3ms) BEGIN
(0.4ms) SET PROFILING=1
(1.3ms) SELECT SQL_NO_CACHE 1 FROM `devices` WHERE (`devices`.`mac
` = BINARY '00606E91E51E' AND `devices`.`id` != 19) LIMIT 1
(0.7ms) UPDATE `devices` SET `elem_photo_id` = 413408, `updated
_at` = '2012-03-30 07:45:12' WHERE `devices`.`id` = 19
(34.5ms) COMMIT
Rendered events/save_photo.html.erb (0.2ms)
Completed 200 OK in 1957ms (Views: 10.2ms | ActiveRecord: 1466.6ms)`
My first problem is the difference by total time and the sum between views time and activerecord time.
After that this times are in the log of the server, so those are the execution time of the request. If I take the time, in the client, from send request to receive respond, it's 3,6 seconds! Why? I don't think that in local network are needed 2 second to transfer 200k!
there's a lot of things happening between client sending request and server sending response
to name a few:
client resolves dns(usually it's cached)
client initiates http connection
client actually posts the data
whatever server you have there accepts post request and enqueues it to be processed by your rails stack
request goes through all the rack middlewares you have before actually hitting your controller
your request is processed by controller and response is generated
response is then transferred to client and browser parses and renders it
what you see in your server logs is probably only point 6, everything else depends on your app setup and properties of your response(html with lots of css, javascripts, images, etc)
regarding your problem with time differences in this line:
Completed 200 OK in 1957ms (Views: 10.2ms | ActiveRecord: 1466.6ms)
detailed time consumption(in parenthesis) is not entirely detailed. it is missing GC time(which probably was invoked if you send files as yaml-formatted parameters), it is also missing time spent in your before filters and action itself.

ActionView errors when pushing to Heroku

I'm building my first webapp, following the Michael Hartl Rails Tutorial. After finishing Chapter 10, I find that my application works locally but does not work when I push it to Heroku. The development log output reads:
Started GET "/" for 98.154.183.51 at Thu Jan 06 01:07:15 -0800 2011
Processing by PagesController#home as HTML
Rendered layouts/_header.html.erb (28.3ms)
Rendered pages/home.html.erb within layouts/application (30.9ms)
Completed in 35ms
User Load (29.6ms) SELECT "users".* FROM "users" WHERE ("users"."id" = 101) LIMIT 1
CACHE (0.0ms) SELECT "users".* FROM "users" WHERE ("users"."id" = 101) LIMIT 1
Rendered layouts/_header.html.erb (149.3ms)
CACHE (0.0ms) SELECT "users".* FROM "users" WHERE ("users"."id" = 101) LIMIT 1
Rendered layouts/_sidebar.html.erb (8.1ms)
Rendered layouts/_footer.html.erb (0.6ms)
Rendered sessions/new.html.erb within layouts/application (342.4ms)
Completed 200 OK in 421ms (Views: 390.1ms | ActiveRecord: 29.9ms)
Whereas the heroku production log reads:
Started GET "/" for 98.154.183.51 at Thu Jan 06 01:07:15 -0800 2011
Processing by PagesController#home as HTML
Rendered layouts/_header.html.erb (28.3ms)
Rendered pages/home.html.erb within layouts/application (30.9ms)
Completed in 35ms
ActionView::Template::Error (PGError: ERROR: invalid input syntax for integer: "nil"
: SELECT "users".* FROM "users" WHERE ("users"."id" = 'nil') LIMIT 1):
I'm not sure why the Heroku-deployed app looks for a user_id of "nil", whereas my local app looks for one of "101." This is my first app, so I'm not sure where to even begin the troubleshooting. I've tried pushing my local db to the Heroku one via heroku rake db:push, but I still get the same errors. Any advice? Thanks in advance for your help.
Make sure you
Migrated your database on Heroku with heroku rake db:migrate
Have a valid user in your database (you could e.g. create one with the Rails console on Heroku)
It seems your code is trying to load a User instance when you have none in your database. If your app works once you have some users in your database, fix your code to act appropriately if no users are present.
You might want to run you rake db:seed also if you have setup some initial values.

Resources