Random 500 error

Hi,

I’m working from two month on a radiant based government site that has
worked fine until two days ago.
Now I get a random 500 internal server error when I try to edit/view
pages in the admin interface and the error is transparent to the
server logs.

At this point I’m very depressed because I can’t find the problem
with the high probability to lost my work that now is on a testing
server.

This is my server configuration:

windows 2003 server
apache 1.3
ruby 1.8.6
rails 12.3
mongrel 1.0.1
mongrel_service 0.3.2
radiant jargon branch at revision 507
reorder, page_attachments, fckeditor and search extension.

Thanks,
Mariano

A few questions that may help:

 When you say "server logs", do you refer to both Apache and Rails

(production.log…)?

 What about the DB logs (MySQL, SQLServer...)?

 Does the 500 error come from Rails or from Apache?

 Can you connect to Radiant with script/console?

 Can you run Radiant with script/server without problems?

 /AITOR

After a deepened analysis of rails production.log I think that the
error is generated by the tinymcefilter extension that I’ve replaced
recently with fckeditor.
At this point how I can purge any reference to the TinyMceFilter
extension?

A snippet of latest production.log file events :

Processing PageController#index (for 10.160.5.143 at 2007-10-01
13:43:53) [GET]
Session ID: 559ec14228a9c8d4e62a1f4cfd4614b0
Parameters: {“action”=>“index”, “controller”=>“admin/page”}
Rendering within layouts/application
Rendering admin/page/index
Completed in 0.56200 (1 reqs/sec) | Rendering: 0.36000 (64%) | DB:
0.20200 (35%) | 200 OK [http://10.160.16.48/admin/pages]

Processing PageController#edit (for 10.160.5.143 at 2007-10-01 13:43:55)
[GET]
Session ID: 559ec14228a9c8d4e62a1f4cfd4614b0
Parameters: {“action”=>“edit”, “id”=>“9”, “controller”=>“admin/page”}
Rendering within layouts/application
Rendering admin/page/edit

ActionView::TemplateError
(F:/web/portalstat/config/…/vendor/radiant/vendor/rails/activerecord/lib/…/…/activesupport/lib/active_support/dependencies.rb:266:in
`load_missing_constant’: uninitialized constant TinyMceFilter) on line
#247 of vendor/extensions/fckeditor/app/views/admin/page/edit.rhtml:
244:
245:


246:

<%= default_filter_name %>
Reference


247:
<%=
filter_reference(default_filter_name) %>

248:

<%= link_to_function ‘Close’,
“Element.hide(‘filter-reference-popup’)”, :class => ‘close-link’
%>


249:

250: <% end -%>

It could be that some pages are still using TinyMceFilter, so if
you remove it the will fail.

Try to just keep both installed until you are sure that you don’t
“use” the old filter.

/AITOR

On 10/1/07, Aitor Garay-Romero [email protected] wrote:

It could be that some pages are still using TinyMceFilter, so if
you remove it the will fail.

Try to just keep both installed until you are sure that you don’t
“use” the old filter.

Thanks Aitor, I’ve cleaned the filter_id column fields on the
page_parts table from the tinymce records and now all work fine.
My consideration about the tinymce filter is that is very toxic, it
can compromise your site because don’t have a rollback task,
page_attachments don’t work with it and the site of author is down.

With proper SCM techniques you avoid such problems. I even use sqlite3
in development so i can version control the DB easily…

/AITOR

Has anyone used SQLite3 for production deployment?

It seems that being able to move around the SQLite3 database file is
a pretty big advantage, since you can download the production
database and work locally on it. Any insight as to whether this would
present any problems with a production site?

On Oct 3, 2007, at 10:51 , Ryan H. wrote:

Has anyone used SQLite3 for production deployment?

It seems that being able to move around the SQLite3 database file is
a pretty big advantage, since you can download the production
database and work locally on it. Any insight as to whether this would
present any problems with a production site?

I tried it on one site and had to switch back to postgres - rake db
tasks were failing with errors, and I cannot reproduce those errors
on any other database platform I have access to.

I used to love sqlite3 for development, but ALTER statements don’t
seem to work very well :frowning:

– Mitch

I’m using sqlite3 without problems. The only problem should be
performance, MySQL, Postgre… are supposedly faster.

Just be careful with the typical rails/sqlite3 gotcha:

http://wiki.radiantcms.org/FAQ

/AITOR