NoMethodError: undefined method `auth_token=' for #<User:0x0055cd7bbc1828>

(Tim) #1

Today I switched from version: tests-passed to version: stable in my app.yml file and am getting an error during ./launcher rebuild app. I’m not sure what to do with this error since it seems to be coming from the seed-fu gem. Anyone have any ideas?

Error info:

I, [2017-04-19T18:45:35.045507 #13]  INFO -- : > cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate'
rake aborted!
NoMethodError: undefined method `auth_token=' for #<User:0x0055cd7bbc1828>
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/seed-fu-2.3.5/lib/seed-fu/runner.rb:46:in `eval'
/var/www/discourse/app/models/user.rb:422:in `password='
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/activerecord- `public_send'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/activerecord- `_assign_attribute'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/activerecord- `block in assign_attributes'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/activerecord- `each'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/activerecord- `assign_attributes'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/seed-fu-2.3.5/lib/seed-fu/seeder.rb:72:in `seed_record'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/seed-fu-2.3.5/lib/seed-fu/seeder.rb:36:in `block (2 levels) in seed'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/seed-fu-2.3.5/lib/seed-fu/seeder.rb:36:in `map'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/seed-fu-2.3.5/lib/seed-fu/seeder.rb:36:in `block in seed'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/activerecord- `transaction'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/activerecord- `transaction'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/seed-fu-2.3.5/lib/seed-fu/seeder.rb:35:in `seed'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/seed-fu-2.3.5/lib/seed-fu/active_record_extension.rb:32:in `seed'
(eval):9:in `block (2 levels) in run_file'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/seed-fu-2.3.5/lib/seed-fu/runner.rb:46:in `eval'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/seed-fu-2.3.5/lib/seed-fu/runner.rb:46:in `block (2 levels) in run_file'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/seed-fu-2.3.5/lib/seed-fu/runner.rb:58:in `block in open'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/seed-fu-2.3.5/lib/seed-fu/runner.rb:57:in `open'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/seed-fu-2.3.5/lib/seed-fu/runner.rb:57:in `open'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/seed-fu-2.3.5/lib/seed-fu/runner.rb:36:in `block in run_file'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/activerecord- `block in transaction'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/activerecord- `within_new_transaction'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/activerecord- `transaction'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/activerecord- `transaction'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/seed-fu-2.3.5/lib/seed-fu/runner.rb:35:in `run_file'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/seed-fu-2.3.5/lib/seed-fu/runner.rb:26:in `block in run'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/seed-fu-2.3.5/lib/seed-fu/runner.rb:25:in `each'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/seed-fu-2.3.5/lib/seed-fu/runner.rb:25:in `run'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/seed-fu-2.3.5/lib/seed-fu.rb:29:in `seed'
/var/www/discourse/lib/tasks/db.rake:8:in `block in <top (required)>'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/rake-11.2.2/exe/rake:27:in `<top (required)>'
/usr/local/bin/bundle:22:in `load'
/usr/local/bin/bundle:22:in `<main>'
Tasks: TOP => db:migrate
(See full trace by running task with --trace)

<<<truncated for brevity>>>

Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 3343 exit 1>
Location of failure: /pups/lib/pups/exec_command.rb:108:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"bundle_exec", "cmd"=>["su discourse -c 'bundle install --deployment --verbose --without test --without development'", "su discourse -c 'bundle exec rake db:migrate'", "su discourse -c 'bundle exec rake assets:precompile'"]}
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one

(David Taylor) #2

Moving from tests-passed to stable isn’t supported mid-release cycle. Your best bet is probably to wait for 1.8 stable to be released and switch to stable then.

(Tim) #3

Darn. Thanks for the info. Discourse won’t rebuild because of the new “native theme support”. It broke a plugin. I was hoping to be able to get discourse back in working order while I figured out how to update the plugin.

Do you have any idea when 1.8 stable might be released? I’m not aware of any published roadmaps for discourse.

(cpradio) #4

It is usually every 3-4 months, see #releases

1.8 started in January.

Best thing to do is to remove your plugin from the app.yml and rebuild it.

(cpradio) #5

Oh and I’m sure if you post a link to the plugin in question a few of us may be willing to take a quick look to see how you can fix it. I’m a bit curious as to why the native theme support broke your plugin and so my curiosity alone wants me to take a quick look :slight_smile:

(David Taylor) #6

As a short term solution, if you really really need to keep the plugin and don’t care about any updates (INCLUDING SECURITY UPDATES), you can install a specific version of discourse according to these instructions:

v1.8.0.beta10 might work for you - I think that’s before the theme changes

(cpradio) #7

I think he will run into the same problem as trying to revert to stable. You have schema changes already applied to the database that the older code reference will not understand.

Just my own hunch though on the matter.

(Tim) #8

The plugin is a custom plugin that’s only for use on our site (the code is not public). We were overriding SiteCustomizaton.custom_head_tag(name) to inject our own header into the site’s template. However, with the removal of site_customization.rb, the plugin no longer works.

I have to fix this one way or another, so I’m definitely open to suggestions on how to use a custom header for the site. The purpose of this is to use the same site navigation on the forum pages as is in use across the rest of our site.

(cpradio) #9

Not sure if this is applicable, but at Sitepoint, we just override the header.hbs

Granted, I’m not sure you need a plugin to do that… this may be helpful too

(Tim) #10

Thanks for the info! That was very helpful. I was able to remove that override from the plugin and put the header in the header customization.

However, I think I figured out why it was done like that in the first place. Our build process was generating that header file and then redeploying the forum (we stand up new AWS EC2 instances every build). That ensured that the header was always up to date. Configuring it manually via the UI means that someone has to go update it every build.

Is there any way to programatically update the content for the header customization configuration?

(Rafael dos Santos Silva) #11

That’s a good question.

If the theme is on a remote git repo, triggering the theme update via a API request is doable. The new work by @sam in that front is just what you need.

(Sam Saffron) #12

Note, I plan (at some point) to add a daily schedule to check if any themes are out of date, and alert you in the admin section that they are out of date…

But first, let’s get some more themes going please :slight_smile:

(Jay Pfaffman) #13

You can replace tests-passed with the last working commit and stick with it until you get stuff worked out.