New Project doesn't load Home Page and can't add pages.

[dfockler]

When I first install the project and go to localhost:3000, the server redirects me to the standard 404 page. I'm able to navigate to localhost:3000/refinery and access the admin pages. When I go to add a new page I get this error.

 SQLite3::ConstraintException: refinery_page_translations.refinery_page_id may not be NULL: INSERT INTO "refinery_page_translations" ("created_at", "custom_slug", "locale", "menu_title", "refinery_page_id", "slug", "title", "updated_at") VALUES (?, ?, ?, ?, ?, ?, ?, ?)

There was also another person on the IRC that was having the same issue. I'm running on OSX 10.9 if that may be an issue also. I can provide more info if needed. Thanks.

[TM818]

I am experiencing the exact same issue on CentOS 6 x86-64, using MySQL. rake db:seed fails on install due to page_id being NULL, and as such, the home page has no content by default. If you navigate to /refinery on the newly-created site, you can create the admin user, but no new articles can be generated due to the same error (refinery_page_id may not be NULL). Rails version is 3.2.15, refinery gem versions are as follows:

refinerycms (2.1.0)
refinerycms-acts-as-indexed (1.0.0)
refinerycms-authentication (2.1.0)
refinerycms-core (2.1.0)
refinerycms-dashboard (2.1.0)
refinerycms-i18n (2.1.0)
refinerycms-images (2.1.0)
refinerycms-pages (2.1.0)
refinerycms-resources (2.1.0)

[ugisozols]

Try this:

• add gem "globalize3", "0.3.0" to your Gemfile
• do bundle install
• run rake db:seed

[dfockler]

I tried running with both globalize3 v0.3.0 and v0.3.1. Both times when I ran the rake db:seed it threw the same ConstraintException error as before.

[TM818]

I, too, am still experiencing this issue. I now have globalize3 0.3.0 in use, and rake db:seed still produces the page_id cannot be NULL error:

rake aborted!
Mysql2::Error: Column 'refinery_page_id' cannot be null: 
INSERT INTO `refinery_page_translations` (`created_at`, `custom_slug`, `locale`, `menu_title`, `refinery_page_id`, `slug`, `title`, `updated_at`) 
VALUES ('2013-10-25 18:56:00', NULL, 'en', NULL, NULL, NULL, NULL, '2013-10-25 18:56:00')

[ugisozols]

If it's possible, could you try dropping the db and running rake db:migrate db:seed? Does that produce the same error?

[TM818]

After dropping the databases via the MySQL command line, then running rake db:migrate db:seed as requested, I am presented with the following "database unknown" error:

rake db:migrate db:seed
rake aborted!
Unknown database 'tfcnew_development'

Also, I should note that the "page_id cannot be null" issue we're now experiencing is relatively new, as I deployed two refinerycms projects within the past week successfully.

[dfockler]

I got the same error after deleting the sqlite db and running rake db:migrate db:seed. The migrations seem to run properly. Looks like it's something in the Pages engine.

[TM818]

Idling in the #refinerycms IRC channel, it appears a lot of users are now having this issue.

[parndt]

It's not to do with globalize is it? cc @shioyama

[shioyama]

It does look like a globalize issue, but downgrading to globalize3, '0.3.0' doesn't solve it? That's odd...

[shioyama]

Here are all the changes between 0.3.0 and 0.3.1: globalize/globalize@v0.3.0...3-0-stable

[shioyama]

@parndt I suspect it's this commit: globalize/globalize@bc2402b. It added a :null => false constraint as discussed in #237.

[shioyama]

It is strange that translations are being added without a model id... but this may have been happening before and nobody noticed.

[shioyama]

I've confirmed that once you drop the :null => false constraint in the globalize migration, rake db:seed works (or at least does not fail). All globalize tests still pass on the 3.0.0 branch with that change, so we can make the change and release a patch as globalize v3.0.1.

@parndt I don't know refinerycms at all so I think you should confirm this is in fact what's going wrong, although it looks pretty clear-cut to me. It seems strange that refinery is seeding the db with translations that do not have a parent model id, though.

[parndt]

Thanks a lot, Chris!

[olhor]

Same problem happens after creating an extension to refinery and trying to test it by deploying dummy app with task 'refinery:testing:dummy_app'.

[shioyama]

I've created a branch with the fix in the 3-0-stable branch of globalize (see above). If all tests pass we can release this as globalize 3.0.1. Although I'd still like to know why refinery is creating translations that don't reference the parent model.

[parndt]

@shioyama thanks, that helps... I think Refinery is faulty.. the master branch of Refinery (3.0.0 development) doesn't have this bug because it doesn't have, in Refinery::Page,

before_save { |m| m.translation.save }
before_create :ensure_locale!

# ..

# Make sures that a translation exists for this page.
# The translation is set to the default frontend locale.
def ensure_locale!
  if self.translations.empty?
    self.translations.build(:locale => Refinery::I18n.default_frontend_locale)
  end
end

This was probably a workaround for when Globalize was not as good.

On the 2-1-stable version of Refinery, this also has to do with the seo_meta integration. I remove the seo_meta stuff from 2-1-stable in addition to the lines commented out above then all of the tests pass again and pages can be created successfully.

So, something's going on with ActiveRecord v3, Refinery 2.1.x and code that works fine in ActiveRecord v4, Refinery 3.0.0.dev

[parndt]

@shioyama having said this, I can't figure out why this is happening and as technically this is a regression in globalize we should probably release version 3.0.1 so that Refinery is fixed and other libraries don't have the same problem. Do you agree?

We could close this issue by making Refinery 2.1.x depend on globalize ~> 3.0.1 which would be a positive thing anyway as it currently depends on globalize3 ~> 0.3.0 and so won't get any globalize patch releases.

[shioyama]

@parndt sure as long as we know the source of the problem, I'm okay with it. And it would definitely be good to update the dependency to globalize ~> 3.0.1. Also, there are some commits to fix globalize/globalize#288 that we need to release anyway that would get included. (We should probably start a changelog, btw.)

[scottolsen]

Is there a work around for this until a new version of refinery is release?

[parndt]

Currently I'm not sure that we've even fixed the issue. Can you try any of the solutions proposed here to let us know if anything helps:
globalize/globalize@f2fd6e7#commitcomment-4447247

[scottolsen]

Created new refinery project with:
refinerycms foo

Then added this to gemfile

gem 'globalize', :github => 'globalize/globalize', :branch => 'fix_refinery_db_seed'
gem 'refinerycms', :github => 'refinery/refinerycms', :branch => '2-1-globalize'

bundled, dropped/created/migrated db and was able to run rake db:seed

However now when I go to the pages index in refinery I get

Showing ...refinery/admin/pages/_page.html.erb where line #10 raised:
undefined method `title' for nil:NilClass

[parndt]

Yeah, that's (undefined method 'title' for nil:NilClass) what the failing tests are showing too, preventing me from merging it to 2-1-stable (as well as the Bundler dependency issues). It's a strange one and it's making me sad.

[ChristopheBelpaire]

Patched gem of @scottolsen worked for me ;)
But I had to drop my database

[laspluviosillas]

The symptom

I cannot say exactly what happens, but as the null restraint error obviously points out, translations are being created with a refinery_page_id of nil. Globalize is most definitely creating the relevant translation records when a Refinery::Page object is saved, but those translation records are not associated to the Refinery::Page object itself, they're just floating around in the ether with a null foreign key.

# pages count and translations count starts at 0
p = Refinery::Page.new
p.title = "test"
p.save

Refinery::Page.count
# => 1
Refinery::Page::Translation.count
# => 1

# refinery_page id is nil! why?
Refinery::Page::Translation.first
# => #<Refinery::Page::Translation id: 27, refinery_page_id: nil, locale: "en", created_at: "2013-10-31 02:01:55", updated_at: "2013-10-31 02:01:56", title: "test", custom_slug: nil, menu_title: nil, slug: "test">

Code problem

Now a bit more towards the code.. Globalize saves translations right here.

When a translation is initialized through record.translations.find_or_initialize_by_locale(locale_str) the foreign key refinery_page_id on that translation record is set. The issue? By the time save_translations! is hit there's a translation object associated in memory only to the record being saved.

Parked on line 51 of adapter.rb with a breakpoint:

record.translations
# => [#<Refinery::Page::Translation id: 25, refinery_page_id: nil, locale: "en", created_at: "2013-10-31 01:44:55", updated_at: "2013-10-31 01:44:55", title: nil, custom_slug: nil, menu_title: nil, slug: nil>]

# ==================================
# Translation association is built but FK (refinery_page_id) is nil. 
# possibly a missing :inverse_of?
# ==================================
record.translations.size
# => 1
record.translations.count
# => 0

existing_translations_by_locale[locale_str]
# => #<Refinery::Page::Translation id: 26, refinery_page_id: nil, locale: "en", created_at: "2013-10-31 01:50:10", updated_at: "2013-10-31 01:50:10", title: nil, custom_slug: nil, menu_title: nil, slug: nil>

# =============================================================
# IF we were to ignore the existing translation record and simply 
# initialize from scratch,  refinery_page_id would be properly populated:
# =============================================================

record.translations.find_or_initialize_by_locale(locale_str)
# => #<Refinery::Page::Translation id: nil, refinery_page_id: 22, locale: "en", created_at: nil, updated_at: nil, title: nil, custom_slug: nil, menu_title: nil, slug: nil>

Attributes are updated on the already initialized translation that doesn't have an association ID, so when everything saves, we end up with a translation that doesn't belong anywhere. This is why the null constraint fails and why removing it ultimately does nothing to resolve the issue. Since these translations are being saved without a foreign key, any translations saved will not be accessible by a Page, ultimately leading to page.title returning nil

[laspluviosillas]

UPDATE:
@parndt removing the code you mentioned seems to work perfectly.

before_save { |m| m.translation.save } Causes the translation object I'm talking about to be saved before it's ready. Remove that line, and then ensure_locale initializes another translation object that doesn't have refinery_page_id set and is invalid.

If you remove both the before_save and before_create callbacks you mentioned, the translations are created in globalize without an issue and everything seems to proceed normally ... I think, but I'm new to this refinery stuff :-).

[shioyama]

It's testing the issue I mentioned above, about creating/updating a new translation in two steps rather than just one. But if the current code is breaking refinery, then I think it's a priority to fix that.

I'm exploring using inverse_of as a way to get around the issue, but it doesn't appear to fix the problem.

[shioyama]

@parndt I think I've finally got a fix for this which gets tests to pass in both globalize and refinery. Will update the branch later today. It will require a small change to refinery 2.1, which I'll post as a PR.

[shioyama]

Ok PR #2462 should finally fix this problem -- all tests pass locally -- but for some bizarre reason one solitary test is failing on Travis.

This is the failing test:

1) Pages with translations add a page with title only for secondary locale uses id instead of slug in admin

Failure/Error: page.find_link('Edit this page')[:href].should include(ru_page_id.to_s)

expected "/refinery/pages/%D0%BD%D0%BE%D0%B2%D0%BE%D1%81%D1%82%D0%B8/edit?switch_locale=ru" to include "38"

# ./pages/spec/features/refinery/admin/pages_spec.rb:527:in `block (5 levels) in <module:Admin>'
# ./pages/spec/features/refinery/admin/pages_spec.rb:526:in `block (4 levels) in <module:Admin>'

If anybody would like to get this problem fixed, now is the time to step in.

Clone the branch I created, switch to the branch with git co issue_2450_globalize, run bundle install and run the tests with:

rake refinery:testing:dummy_app
rake

Then please report what you find, and if you get the failure then it would greatly help if you could try to figure out what is going on.

[LieonSP]

Hi everybody, thanks for your work you saved my night... The following sequence worked nicely for me too (I give details for newbies like me):

In the Gemfile insert: gem "globalize3", "0.3.0"
$ bundle
$ bundle update globalize3
$ rake db:drop
$ rake db:create
$ rake db:migrate
$ db:seed

[laspluviosillas]

@shioyama
Apologies for abandoning mid-development. Crunch time at work kept me busy last week. I'll see if I can look into that test this week but no promises. :-)

[shioyama]

@laspluviosillas thanks any help would be much appreciated. I can't really put any more time into this, and fixing a failure that only appears in Travis is a pain... if anybody has any suggestions I'm all ears. Maybe just rerunning the build would work.

This seems like an urgent issue though, so maybe the refinery maintainers could just ignore that one failure for now and merge the PR? That should close this issue.

[jmercedes]

ChristopheBelpair worked for me. Using PG.

[cwise]

I ran into StackLevelTooDeep hell when I tried this (can't load the environment) with an existing project and cherry-picked the commits into a fork of 2-1-stable. They seem to be related to il8n. I was at commit 9b973c5 previously. The few commits between that and these commits are innocuous.

[cwise]

gems/ruby-1.9.3-p448/gems/activesupport-3.2.13/lib/active_support/dependencies.rb:240: stack level too deep (SystemStackError)

It seems like I've isolated this to a conflict with refinerycms-blog. When I get rid of references to it in the project, I can load the environment.

[shioyama]

I added d543eb1 to get bundle to work, 2-1-stable will not work otherwise, see the latest build on TravisCI: https://travis-ci.org/refinery/refinerycms

I'm not really familiar with the roots of this dep conflict and it really doesn't have anything to do with the issue here, so I just did whatever seemed to work to get it to build correctly.

[Haegin]

When is this going to be fixed? Using gem 'globalize', '3.0.0' gets the app booting but the seed data doesn't include the necessary foreign keys for the page translations table so listing pages in the admin just 500s.

[parndt]

@Haegin what if you use gem 'globalize', '0.3.0'

I've no idea when we'll have a consistent solution for this.

[shioyama]

@parndt I really think you should just accept #2462 despite that one failing test, which anyway isn't critical. It will fix the problem.

[parndt]

@shioyama I've merged it.

[shioyama]

@parndt thanks!

Everyone following this, please try the latest version of refinery from the 2-1-stable branch (without locking globalize to 0.3.0) and see if it works. I'll try to follow up on any other issues that are globalize-related.

[Haegin]

@parndt @shioyama Thanks guys, it's nice to see Refinery working as it should. The test failure in Travis seems really strange. I've just run the tests on the 2-1-stable branch locally and they're passing fine. Hopefully it's a Travis CI problem and won't cause problems for anyone using RefineryCMS in the wild.

[parndt]

@shioyama I'm still seeing this and so is @captproton

source 'https://rubygems.org'

gem 'rails', '3.2.15'

# Bundle edge Rails instead:
# gem 'rails', :git => 'git://github.com/rails/rails.git'

group :development, :test do
  gem 'sqlite3'
end


# Gems used only for assets and not required
# in production environments by default.
group :assets do
  gem 'sass-rails',   '~> 3.2.3'
  gem 'coffee-rails', '~> 3.2.1'

  # See https://github.com/sstephenson/execjs#readme for more supported runtimes
  # gem 'therubyracer', :platforms => :ruby

  gem 'uglifier', '>= 1.0.3'
end

gem 'jquery-rails'

# Refinery CMS
gem 'refinerycms', '~> 2.1.0', github: 'refinery/refinerycms', branch: '2-1-stable'
gem 'globalize', github: 'globalize/globalize', branch: '3-0-stable'

# Optionally, specify additional Refinery CMS Extensions here:
gem 'refinerycms-acts-as-indexed', '~> 1.0.0'
#  gem 'refinerycms-blog', '~> 2.1.0'
#  gem 'refinerycms-inquiries', '~> 2.1.0'
#  gem 'refinerycms-search', '~> 2.1.0'
#  gem 'refinerycms-page-images', '~> 2.1.0'

So, fairly standard.

[parndt]

OK SO the reason for this is because it was keeping the bad schema information from when I wasn't using edgey versions.

Solution:

bundle exec rake db:{drop,create,migrate,seed}

Problem solved.

@shioyama we should release new gems?

[shioyama]

@parndt I think you should release refinery, the latest version of globalize (3.0.1) should work fine without any update.

btw I think globalize/globalize#306 might explain the weird random failing refinery spec, since it was related to a slug. Once I fix that issue I think that one failure should disappear, although can't be 100% sure.

[bsodmike]

Hi all, just to double-check is there a solution to this without having to drop & reseed the db?
Edit: I'm seeing @shioyama fix merged into 2.1.1, would this just work without needing any change to the db schema/contents?