Help deploying 0.2 of my extension...getting weird behavior

I want to validate that I am deploying my 0.2 version of my extension
correctly. I need to rule out that it is a radiant issue.

I have a radiant 6.0 rc1 (application mode) installed and running on
my hosting site (RailsPlayground). I just recently updated my
extension and wanted to deploy that to production. I use a manual
process right now (yes, I need to learn capistrano) so I just FTPed my
0.2 version over the 0.1 files.

I then ran
rake production db:migrate:extensions

My db schema changes show up in the database, so that seemed to work
just fine.

I go to my site and I now see that I have my two new tabs on the admin
screen (version 0.1 of my extension just had one). So I go to the tab
that is in both version and I see the 0.1 version of it. None of my
changes are there. Then I go to the new tab that is only in version
0.2 and it throws an error.

Application error (Apache)

Change this error message for exceptions thrown outside of an action
(like in Dispatcher setups or
broken Ruby code) in public/500.html

I have double checked that the files are out there and the correct
version, but am stumped as to what is wrong.

I made sure to kill all the FastCGI processes (suggested by
RailsPlayground), but that doesn’t help. And the real kicker is that
once and only once I saw the new changes displayed.

Does radiant do something with the extensions that needs to be cleared
out? Is my hosting provider doing something that I am not aware of?

It is probably something obvious, but I just cannot see it. Any help
would be appreciated.


My first suggestion is to switch your app into development mode and
see what the error your getting is. My hunch is a file permission
issue, but it’s hard to say without a real error message.

Good Luck,
BJ Clark

BJ…Thank you

Your reminder to up the log level to debug forced me to remember
something odd about my installation.

I develop my radiant extension on a mac os x 4.9 ruby 1.8.5 RoR 1.2.1
running on a mongrel 1.0.1 , but I have to add two things when I
deploy. First, I have to add Admin:: to each of my extension
controllers and I also have to put my extension views in the
app/views/admin. This defeats the purpose of have the extensions…I
still have to mix the views from radiant and my extension.

My hosting environment…well the cheaper package, only uses fastcgi,
but I don’t know if that causes this problem.

Does anyone know why I would have to add Admin:: to my extension
controllers and change the location of my view files? As you can see
this is rather annoying and prone to error. I just cannot drop my
extension to the vendor/extension folder and have things work.

BJ…thanks again.


I hate to sound like a broken record, but just because your controllers
appear in the “admin/” URL path does not mean they have to be in the
Admin module. For example, in the LDAP extension:

define_routes do |map|
map.connect ‘admin/ldap/:action/:id’, :controller => ‘ldap’


Simple as that. IMHO, it’s best not to mess with module namespaces
unless you absolutely have to.


On Mar 22, 2007, at 12:20 AM, jsmorris wrote:

2007-03-20 00:18:17) [GET]
Session ID: fbe9e7f1f92a5776b70cfcc3a04ad1d1
Parameters: {“action”=>“index”, “controller”=>"/admin/lectures"}

NameError (uninitialized constant Admin::LecturesController):

It’s been a late night, but isn’t this happening because it is
resolving the attribute “controller” to “/admin/lectures”, which is
due to your routes configuration? Therefore, were you to either fix
that, or create an admin directory in your extension’s app/
controllers directory and place lectures.rb there, wouldn’t things
work within the extension?

adam williams

I totally agree, but the reason I moved my views and added the Admin::
namespace to my extension controller was because radiant didn’t find
them in the appropriate spot in my extensions folder. It threw an
error. Thus it was looking for them in the wrong place. So I moved
them to where it was looking for them just to get my extension to
work. This is the error I get (when I don’t add the Admin namespace
to my extension’s controller):

Processing ApplicationController#index (for at
2007-03-20 00:18:17) [GET]
Session ID: fbe9e7f1f92a5776b70cfcc3a04ad1d1
Parameters: {“action”=>“index”, “controller”=>"/admin/lectures"}

NameError (uninitialized constant Admin::LecturesController):
load_missing_constant' /vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:453:inconst_missing’
constantize' /vendor/rails/activerecord/lib/../../activesupport/lib/active_support/core_ext/string/inflections.rb:148:inconstantize’
recognize' /vendor/rails/railties/lib/dispatcher.rb:40:indispatch’
/vendor/rails/railties/lib/fcgi_handler.rb:168:in process_request' /vendor/rails/railties/lib/fcgi_handler.rb:143:inprocess_each_request!’
with_signal_handler' /vendor/rails/railties/lib/fcgi_handler.rb:142:inprocess_each_request!’
each_cgi' /usr/local/lib/ruby/gems/1.8/gems/fcgi-0.8.7/lib/fcgi.rb:609:ineach’
each_cgi' /vendor/rails/railties/lib/fcgi_handler.rb:141:inprocess_each_request!’
/vendor/rails/railties/lib/fcgi_handler.rb:55:in process!' /vendor/rails/railties/lib/fcgi_handler.rb:25:inprocess!’

Now, after adding the Admin namespace to my extension controller and
not coping the views to radiant/app/views/admin directory, I get this

Processing LecturesController#index (for at 2007-03-21
00:37:46) [GET]
Session ID: fbe9e7f1f92a5776b70cfcc3a04ad1d1
Parameters: {“action”=>“index”, “controller”=>"/admin/lectures"}
e[4;36;1mSQL (0.048391)e[0m e[0;1mSELECT count(*) AS count_all
FROM lectures e[0m
e[4;35;1mLecture Load (0.000248)e[0m e[0mSELECT * FROM lectures
ORDER BY date_and_time DESC LIMIT 0, 10e[0m
Rendering layoutfalseactionlist within layouts/application

ActionController::MissingTemplate (Missing template
assert_existence_of_template_file' /vendor/rails/actionpack/lib/action_controller/base.rb:804:inrender_file’
render_with_no_layout' /vendor/rails/actionpack/lib/action_controller/base.rb:863:inrender_without_layout’
render_action' /vendor/rails/actionpack/lib/action_controller/base.rb:748:inrender_with_no_layout’
silence' /vendor/rails/actionpack/lib/action_controller/base.rb:747:inrender_with_no_layout’
render_without_benchmark' /vendor/rails/actionpack/lib/action_controller/benchmarking.rb:50:inrender’
/usr/local/lib/ruby/1.8/benchmark.rb:293:in measure' /vendor/rails/actionpack/lib/action_controller/benchmarking.rb:50:inrender’
index' /vendor/rails/actionpack/lib/action_controller/base.rb:1095:insend’
perform_action_without_filters' /vendor/rails/actionpack/lib/action_controller/filters.rb:632:incall_filter’
call_filter' /vendor/rails/actionpack/lib/action_controller/filters.rb:638:incall_filter’
call' /vendor/rails/actionpack/lib/action_controller/filters.rb:637:incall_filter’
call_filter' /vendor/rails/actionpack/lib/action_controller/filters.rb:438:incall’
call_filter' /vendor/rails/actionpack/lib/action_controller/filters.rb:638:incall_filter’
call' /vendor/rails/actionpack/lib/action_controller/filters.rb:637:incall_filter’
perform_action_without_benchmark' /vendor/rails/actionpack/lib/action_controller/benchmarking.rb:66:inperform_action_without_rescue’
/usr/local/lib/ruby/1.8/benchmark.rb:293:in measure' /vendor/rails/actionpack/lib/action_controller/benchmarking.rb:66:inperform_action_without_rescue’
perform_action' /vendor/rails/actionpack/lib/action_controller/base.rb:430:insend’
process_without_filters' /vendor/rails/actionpack/lib/action_controller/filters.rb:624:inprocess_without_session_management_support’
process' /vendor/rails/actionpack/lib/action_controller/base.rb:330:inprocess’
/vendor/rails/railties/lib/dispatcher.rb:41:in dispatch' /vendor/rails/railties/lib/fcgi_handler.rb:168:inprocess_request’
process_each_request!' /vendor/rails/railties/lib/fcgi_handler.rb:109:inwith_signal_handler’
process_each_request!' /usr/local/lib/ruby/gems/1.8/gems/fcgi-0.8.7/lib/fcgi.rb:612:ineach_cgi’
each' /usr/local/lib/ruby/gems/1.8/gems/fcgi-0.8.7/lib/fcgi.rb:609:ineach_cgi’
process_each_request!' /vendor/rails/railties/lib/fcgi_handler.rb:55:inprocess!’
/vendor/rails/railties/lib/fcgi_handler.rb:25:in `process!’

I don’t have to modify anything locally, so my local environment works
without have to do these extra steps. Thus my suspicion is that due
to the different setups (mongrel vs FastCGI) between my dev
environment (my computer) and my production (hosting) environment
causes radiant to behave differently.

I am a still learning RoR, so I am looking for some advice on how to
troubleshoot this problem. Is the code that tells radiant where to
look dependent on FastCGI and mongrel?

My define_routes look like this in my_extension.rb file

define_routes do |map|
map.connect ‘/admin/education/:action’, :controller =>
map.connect ‘/admin/grandrounds/:action’, :controller =>

I very much would like my extension to act like the LDAP extension and
not have to mess with manual moving of my views and adding the
namespace, but I just don’t know what to fix and more specially what
the fix is that would make my radiant work in production and still
continue to work in development.


Adam…I owe you one! Thank you!

Your observation was correct, because of the way I defined my route in
my extension caused it to act the way it did.

My old routes where defined like

define_routes do |map|
map.connect ‘/admin/education/:action’, :controller =>
map.connect ‘/admin/grandrounds/:action’, :controller =>

Now, they look like this

define_routes do |map|
map.connect ‘/admin/education/:action’, :controller => ‘lectures’
map.connect ‘/admin/grandrounds/:action’, :controller => ‘grandrounds’

I am not sure why I thought they needed to be like that, but I am
still learning.

Thanks again,