0

For summary, I have a blog_posts controller. The blog_posts controller functions mostly as normal CRUD. However, in the model, I record the state of blog_posts. So a user can post an entry, but it won't be in an Active state, which means no one can view it. Once they change the state to Active, it can be viewed and therefore it is suggested that the blog_post be left static and that the user not update it, BUT, we still allow updating, with warnings.

So, my task is to create a warning firewall page. When the user clicks edit for an Active blog_post, the warning page should appear, then they have to click continue or back.

My code looks like this:

def edit
  @blog = Blog.find(params[:blog_id])
  @blog_post = @blog.blog_posts.find(params[:id])
  if @blog_post.state == "Active" && @blog_post.editing_after_active.nil?
    redirect_to warning_path(@blog, @blog_post)
  end
end

def warning
  @blog = Blog.find(params[:blog_id])
  @blog_post = @blog.blog_posts.find(params[:id])
  if params[:no]
    @blog_post.update_attributes(editing_after_active: nil)
    redirect_to blog_blog_posts_path(@blog)
  elsif params[:yes]
    @blog_post.update_attributes(editing_after_active: "yes")
    redirect_to edit_blog_blog_post_path(@blog, @blog_post)
  end
end

This is how I believe it to work.

  1. A user navigates to the blog_post edit page for an Active post.
  2. The edit controller sees that the post is active, and that the user has not accepted the warning, and redirects to the warning page. (Is Active and editing_after_active both evaluate to true)
  3. On the warning page, there are two options (yes / no).
  4. User clicks yes for continue. The editing_after_active attribute should be set to "yes", which means they've accepted the warning.
  5. They are redirected to edit.
  6. The criteria is evaluated again, but this time, it evaluates to false.
  7. The edit page is rendered.

What am I missing here? Stack Level Too Deep is supposed to be for infinite loops. Is this loop infinite?

UPDATE:

class BlogPost < ActiveRecord::Base
  include BlogModule
  belongs_to :blog
  has_one :visit, :as => :visitable

  has_many :assets, :as => :assetable, :dependent => :destroy

  has_many :bookmarks, :dependent => :destroy
  has_many :bookmark_users, :through => :bookmarks, :dependent => :destroy

  has_many :taggings, :as => :taggable, :dependent => :destroy
  has_many :tags, :through => :taggings

  # more has_many


  attr_accessible :tag_ids, :asset_ids # more attr_accessible
  attr_accessor :editing_after_active


  def editing_after_active
    editing_after_active
  end

end

UPDATE:

Connecting to database specified by database.yml


Started POST "/blogs/resort-casino-chicago/blog_posts/39/warning" for 127.0.0.1 at 2014-02-27 14:41:57 -0500
Processing by blogpostsController#warning as HTML
Parameters: {"utf8"=>"✓", "authenticity_token"=>"6UaDU1Sn3yiKlGl6OJCUapmU4KCSilLL8Lgo+jsyJdI=", "yes"=>"Yes, I am authorized to continue.", "blog_id"=>"resort-casino-chicago", "blog_post_id"=>"39"}
 [1m [36mblog Load (0.8ms) [0m   [1mSELECT `blogs`.* FROM `blogs` WHERE `blogs`.`slug` = 'resort-casino-chicago' LIMIT 1 [0m
 [1m [35mblogpost Load (0.2ms) [0m  SELECT `blog_posts`.* FROM `blog_posts` WHERE `blog_posts`.`blog_id` = 1680 AND `blog_posts`.`id` = 39 LIMIT 1
 [1m [36m (0.2ms) [0m   [1mBEGIN [0m
 [1m [35m (0.1ms) [0m  COMMIT
Redirected to http://localhost:3000/blogs/resort-casino-chicago/blog_posts/39/edit
Completed 302 Found in 647ms (ActiveRecord: 8.4ms)


Started GET "/blogs/resort-casino-chicago/blog_posts/39/edit" for 127.0.0.1 at 2014-02-27 14:41:58 -0500
Processing by blogpostsController#edit as HTML
 Parameters: {"has_many"=>:posts, "blog_id"=>"resort-casino-chicago", "id"=>"39"}
 [1m [36mblog Load (0.9ms) [0m   [1mSELECT `blogs`.* FROM `blogs` WHERE `blogs`.`slug` = 'resort-casino-chicago' LIMIT 1 [0m
 [1m [35mblogpost Load (0.3ms) [0m  SELECT `blog_posts`.* FROM `blog_posts` WHERE `blog_posts`.`blog_id` = 1680 AND `blog_posts`.`id` = 39 LIMIT 1
Completed 500 Internal Server Error in 5ms

SystemStackError - stack level too deep:
  actionpack (3.2.11) lib/action_diblogtch/middleware/reloader.rb:70:in `'



Started POST "/__better_errors/70165434709380/variables" for 127.0.0.1 at 2014-02-27 14:41:58 -0500

UPDATE:

Ok, on the warning page, I tried to render the current value of the <%= @blog_post.editing_after_active %> and I got stack level too deep just from trying to render the value. So, the error has to do with setting the virtual attribute most likely.

I manually set the value of editing_after_active like this: def editing_after_active "yes" end

With this the warning form submits just fine. So, need to figure out why the original setting is recursive.

miler350
  • 1,411
  • 11
  • 15
  • Do you by chance have any callbacks (after_save or the like) on the BlogPost model? Also, can you substitute `update_attributes` with `update_attributes!` (with the exclamation mark) to possibly rule out a validation issue)? Posting model code may help as well... – PinnyM Feb 27 '14 at 19:13
  • No callbacks. The `update_attributes!` still gives the stack level too deep. – miler350 Feb 27 '14 at 19:19
  • Any validations then? Observers? Please post any relevant model code. Also check if there are any `before_action` callbacks on your controller actions that might be related. – PinnyM Feb 27 '14 at 19:21
  • Please include the stack trace and specify the point in the process outlined above at which the error occurs – bridiver Feb 27 '14 at 19:28
  • It doesn't give a stack trace for 'stack level too deep', it's really just a one line error. – miler350 Feb 27 '14 at 19:31
  • I still thought it gave part of the call stack, are you sure there's nothing in the log file? In any case I still don't know which one of steps 1-7 causes the error – bridiver Feb 27 '14 at 19:37
  • Can you check in the rails console, if that object (search if via ID) has editing_after_active set to "yes"? probably it is not saving the value, I suggest you use boolean values for that field. – Jorge Sampayo Feb 27 '14 at 19:41
  • added the development log output – miler350 Feb 27 '14 at 19:46
  • @JorgeSampayo - what do you mean exactly? Don't use a button? – miler350 Feb 27 '14 at 19:49
  • You may be right, new info added to bottom of post. – miler350 Feb 27 '14 at 19:52
  • For the record, the recursion was solved because the attr_accessor was set in correctly. Now, the attr_accessor does not persist. I'm not sure why. I did logger.debug on both pages. The warning page sends "true" but when the attribute is evaluated in the edit model, it is nil. The attribute always reverts to nil. – miler350 Feb 28 '14 at 06:26

0 Answers0