Rails broke typo

Ruby Apps Typo
1

My web host upgraded rails, and now I get this error in production.log:

ActionView::TemplateError (xml_url failed to generate from
{:action=>“feed”, :ty
pe=>“article”, :format=>“rss”, :controller=>“xml”, :id=>“2051”},
expected: {:act
ion=>“feed”, :type=>“sitemap”, :format=>“googlesitemap”,
:controller=>“xml”}, di
ff: {:type=>“sitemap”, :format=>“googlesitemap”, :id=>“2051”}) on line
#33 of th
emes/scribbish/views/articles/_article.rhtml:
30: <%= trackbacks_link(article) << ‘,’ if article.allow_pings? %>
31: <%= comments_link(article) << ‘,’ if article.allow_comments?
%>
32: permalink,
33: rss,
34: atom
35:
36:

[followed by an ENORMOUS backtrace]

and a bunch of errors on startup:

It looks like you’ve upgraded to the new version of Rails…and broken
my web site:

/home/meta/typo/public/…/config/boot.rb:38:Warning: require_gem is
obsolete. Use gem instead.
/home/meta/typo/public/…/config/boot.rb:38:Warning: require_gem is
obsolete. Use gem instead.
DEPRECATION WARNING: The :dependent => true option is deprecated and
will be removed from Rails 2.0. Please use :dependent => :destroy
instead. See http://www.rubyonrails.org/deprecation for details. See
http://www.rubyonrails.org/deprecation for details. (called from
has_many at
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.1/lib/active_record/associations.rb:550)
DEPRECATION WARNING: The :dependent => true option is deprecated and
will be removed from Rails 2.0. Please use :dependent => :destroy
instead. See http://www.rubyonrails.org/deprecation for details. See
http://www.rubyonrails.org/deprecation for details. (called from
has_many at
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.1/lib/active_record/associations.rb:550)
DEPRECATION WARNING: The :dependent => true option is deprecated and
will be removed from Rails 2.0. Please use :dependent => :destroy
instead. See http://www.rubyonrails.org/deprecation for details. See
http://www.rubyonrails.org/deprecation for details. (called from
has_many at
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.1/lib/active_record/associations.rb:550)
DEPRECATION WARNING: The :dependent => true option is deprecated and
will be removed from Rails 2.0. Please use :dependent => :destroy
instead. See http://www.rubyonrails.org/deprecation for details. See
http://www.rubyonrails.org/deprecation for details. (called from
has_many at
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.1/lib/active_record/associations.rb:550)
DEPRECATION WARNING: The :dependent => true option is deprecated and
will be removed from Rails 2.0. Please use :dependent => :destroy
instead. See http://www.rubyonrails.org/deprecation for details. See
http://www.rubyonrails.org/deprecation for details. (called from
has_many at
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.1/lib/active_record/associations.rb:550)
DEPRECATION WARNING: The :dependent => true option is deprecated and
will be removed from Rails 2.0. Please use :dependent => :destroy
instead. See http://www.rubyonrails.org/deprecation for details. See
http://www.rubyonrails.org/deprecation for details. (called from
has_many at
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.1/lib/active_record/associations.rb:550)

Any suggestions?

mathew

2

OK, much as I didn’t want to do it, I upgraded to edge typo (rev 1361).

Took a backup of my data.

First time through got a heartwarming message from rake migrate:

== SeparateEntriesAndFeedback: migrating

rake aborted!
This is a more or less untested migration that might lose data.
Backup before commenting out line 10 of
db/migrate/058_separate_entries_and_feedback.rb

I went ahead and commented out line 10, and everything appears to have
migrated OK.

Then, since someone has gone ahead and converted scribbish to that
HAML crap and I need to be able to add yadis entries to my HTML
element, I deleted the scribbish subdirectory downloaded from SVN and
replaced it with the old one from typo 4.

I repeat my previous comment: either HAML goes, or I do.

mathew

3

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I’ve already told Kevin about this once on IRC, I’ll repeat my point
of view here.

Using HAML on the default theme is stupid, because people want to
modify a but their theme and they will just digg into HTML, nothing
else.

IMHO, HAML is really good for a web application where end users are
not supposed to modify templates. It should fit well on the admin as
long as you can’t override admin views in themes.

I hope the core team will do a step back and revert default themes as
RHTML while offering the HAML option.

Le 3 févr. 07 à 16:42, mathew a écrit :

This is a more or less untested migration that might lose data.

I repeat my previous comment: either HAML goes, or I do.

mathew

Typo-list mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/typo-list

Frédéric de Villamil
“C’est pourquoi je veux t’aimer / à jamais te louer / toujours
t’appartenir / et sans cesses te servir”
[email protected] tel: +33 (0)6 62 19 1337
http://fredericdevillamil.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFFxLKWCvkKk5nKviARAk2nAJ4jmWkm47KawfDhKJVhTwH98twdSgCg2rvi
nXrjFNzmBIS9DwSHMaJvNno=
=HMOL
-----END PGP SIGNATURE-----

4

On 2/3/07, Frederic de Villamil [email protected] wrote:

Using HAML on the default theme is stupid, because people want to
modify a but their theme and they will just digg into HTML, nothing
else.

Yes. Absolutely. Nobody is going to learn a whole new markup language
just so they can (as in my example) add 4 lines of metadata to the

element of their web site.

Similarly, people who design all those slick layouts aren’t going to
learn a whole new markup language so they can convert their slick
layouts to work on typo.

mathew

5

mathew [email protected] writes:

Then, since someone has gone ahead and converted scribbish to that
HAML crap and I need to be able to add yadis entries to my HTML
element, I deleted the scribbish subdirectory downloaded from SVN and
replaced it with the old one from typo 4.

I repeat my previous comment: either HAML goes, or I do.

Boy, you know how to make friends and influence developers don’t you?

For the record, as long as it’s impossible to render rhtml partials
from a HAMLized view, then I’m very much inclined to roll back the
experiment of HAMLizing our various themes in favour of simply
supporting people who want to write HAML partials for things like
sidebars.

As a heads up, I’m also thinking about rejigging the sidebar/plugin
architecture and basing it on an event (possibly mixed with DOM
callbacks) driven system.

So a comment gatekeeper plugin would register itself as interested in
post filtering .comment-box to add a “type the results of multiplying
three by 10 here” type challenge and as a before handler
for Article::Controller#comment to check for the presence of the
correct captcha

Textfilters would work in similar fashion, with ‘post’ filters
registering to manipulate either the whole chunk of formatted text, or
simply specific DOM/XPath entities. Ideally they’d receive a DOM
object rather than simple text, but that’s dependent on an
appropriately lightweight parser being available.

The idea here is that most plugins would be operating in
controller/helper space, which means they’d have access to routing and
other helper type tools, and that means we could remove a bunch of
routing type stuff that’s currently in the models because the
textfilters need them, and that would be good. I really dislike
duplicating whole chunks of stuff that Rails could/should be doing for
us.

NB, this is currently very sketchy and should not be, in any way,
taken to be a promise or anything more than a back of an envelope
design sketch. Filters, sidebars and other plugins have been bugging
me for a while, there has to be a Better Way, but I’m not entirely
sure what that is yet.

6

On 2/6/07, Piers C. [email protected] wrote:

mathew [email protected] writes:

I repeat my previous comment: either HAML goes, or I do.

Boy, you know how to make friends and influence developers don’t you?

Yeah, well, I studied at the Austin Z. Charm School on ruby-core.
:slight_smile:

For the record, as long as it’s impossible to render rhtml partials
from a HAMLized view, then I’m very much inclined to roll back the
experiment of HAMLizing our various themes in favour of simply
supporting people who want to write HAML partials for things like
sidebars.

Oh, I have no objection to people writing HAML if they want to. In
fact, if people want to develop themes in M4, they can do that too. I
just need to be able to customize my web site by editing something
HTML-like. If I can’t, I’ll find some software where I can. It was the
HAMLization of the default template that shocked me.

So a comment gatekeeper plugin would register itself as interested in
post filtering .comment-box to add a “type the results of multiplying
three by 10 here” type challenge and as a before handler
for Article::Controller#comment to check for the presence of the
correct captcha

And hopefully it’d do a better job than the PHP captchas I keep
running into that fail to recognize the correct answer to their own
challenge because they assumed they had permission to store cookies in
my browser.

mathew

7

mathew [email protected] writes:

So a comment gatekeeper plugin would register itself as interested in
post filtering .comment-box to add a “type the results of multiplying
three by 10 here” type challenge and as a before handler
for Article::Controller#comment to check for the presence of the
correct captcha

And hopefully it’d do a better job than the PHP captchas I keep
running into that fail to recognize the correct answer to their own
challenge because they assumed they had permission to store cookies in
my browser.

Frankly, I don’t care whether they do or not. It’ll be a cold day in
hell before I put any captcha system in the core.