Hi Ryan;
I did not see any Javascript errors in the browser, and I’ve confirmed same behaviour on Firefox 44 on Windows, Safari on iPad, and Firefox on Android tablet. What seems to be happening, is that the Javascript libraries are not being loaded in production mode, but the are being loaded in development mode. I start the “rails” server on the CentOS Linux box, with a two-line script:
export SSL=true
rails server -b 0.0.0.0 -p 3000 -e production
I’ve looked at a lot of material on this issue, and confirmed I had all the obvious suggestions already defaulted. Eg. In Weblog/app/assets/javascripts file application.js, the lines “//= require jquery” and “//= require jquery_ujs” are present. And the file application.html.erb, in Weblog/app/views/layouts has the line:
<%= javascript_include_tag ‘application’, ‘data-turbolinks-track’ => true %>, and so on. (Ie. I’ve been thru all the Stack Overflow reports of this specific issue…)
My original assumption - that the Ruby-on-Rails “Getting Started…” Guide was obsolete - is wrong. The “link_to” verb does work, but I have not been able to nail down exactly why the javascript libraries are not being loaded. If I run in development with “rails server -b 0.0.0.0 -p 3000 -e development”, then the “link_to” in the example works (it presents the dialog box, when “Destroy” is selected from the blog article list, and then successfully deletes the article).
In directory …/Weblog/config/environments there are three “.rb” files (Ruby source), development.rb, production.rb and test.rb.
As a kludge workaround, I have taken a copy of the production.rb and the development.rb files, and simply renamed the production.rb
file to “development.rb”. This then results in the “Weblog” tutorial app running correctly, as documented. (The dialog box is presented to the user, when the “Destroy” option is clicked, and this behaviour is correct and consistent across all browsers tested - Firefox 44 on Windows, Safari on iPad, and Firefox on Android (5.0.2 Lollipop).
The differences between the two files in /Weblog/config/environments is as follows (I have hand-keyed this, just by looking at the screen on the Linux box, so there might be typos, and I have not typed the comments or commented out code)
development.rb (original file - which I just copied to production.rb, to get the app working…)
Rails.application.configure do
config.cache_classes = false
config.eager_load = false
config.consider_all_requests_local = true
config.action_controller.perform_caching = false
config.action_mailer.raise_delivery_errors = false
config.active_support.deprecation = :log
config.active_record.migration_error = :page_load
config.assets.debug = true
config.assets.digest = true
config.assets.raise_runtime_errors = true
config.action_view.raise_on_missing_translations = true
end
production.rb (original file - which makes the “link_to” verb NOT WORK correctly, probably because jquery/jquery_ujs are not loaded…)
Rails.application.configure do
config.cache_classes = true
config.eager_load = true
config.consider_all_requests_local = false
config.action_controller.perform_caching = true
config.serve_static_files = ENV[‘RAILS_SERVE_STATIC_FILES’].present?
config.assets.js_compressor = :uglifier
config.assets.compile = false
config.assets.digest = true
config.force_SSL = true
config.log_level = debug
config.i18n.fallbacks = true
config.active_support.deprecation = :notify
config.log_formatter = ::Logger::Formatter.new
config.active_record.dump_schema_after_migration = false
end
I have not go thru line by line, making changes to the production.rb file, since probably someone will just recognize the issue (I hope.)…
Perhaps the “uglifier” is mangling the javascript it sends, and so the browser is just flushing it?
Any suggestions appreciated.
I will track this down myself, if I have to, and post the results of my reseach here, and to Stack Overflow as well.
Thanx for any info.
Oh, one note on another work-around: The “link_to” verb (in the example) can be replaced with a “button_to” verb, which will create a button on the displayed webpage, instead of a highlited link. This will work (without javascript libraries), but it WILL NOT present a dialog box. It will just destroy the article, with no confirmation prompt (not good, obviously). This is a popular workaround to this problem, as indicated by the postings to Stack Overflow. Since most browsers support javascript, the “link_to” is obviously the preferred method for any delete/destroy action.