Optimum Location for Google Urchin Tags

Ruby Apps Radiant CMS
1

I need to insert the Google Urchin Tags into my radiant-based site for
Google Tracking & Adsense Management. Did some searching through the
radiant-mail-archives and there was only mention of this (sepetember
2006),
to which Sean suggested that perhaps a snippet might be the best way to
do
this.

Has anyone else used the Google Urchin Tags on their Radiant-based site
and
which method worked for them?

Regards, Ben.

2

Yes, I used a snippet myself, and I placed it at the very end of my
file, right above the – I don’t know it this is right, but it
works for me. I hate relying on other sites to serve some kind of
content to me, but when I do, I prefer it to be as far down my page as I
can, so that if some reason their service is lagging, it won’t hold up
the loading of the remainder of the page.

Just my $0.02 :slight_smile:

3

Hi Andrew,

Thanks for your tip, I’ll give the footer idea (John-Daniel) a go,

Regards, Ben.

P.S. With rounding down of money, wouldn’t $0.02 actually be $0.00? haha

4

Also one can cache the urchin.js file locally, which I’ve found
speeds up page loads significantly. You’ll also need to add a cronjob
to re-fetch it every night.

See: <Speed Up Google Analytics with urchin.js
with-a-local-urchinjs.html>

-jamie

5

Jamie,

Excellent article, will enable that today,

cheers, Ben.

6

Andrew K. wrote:

I’ve just finished porting my website to 0.6.0rc2 after running with
0.5.2 live and 0.6.0 on a test-and-build server. However, after got it
ported and did the db:migrate, I fell into an evil issue: For some
bizarre reason, db:migrate this time somehow decided it wanted to
re-sort all of the news articles I already had in place. Now, my article
order is totally random (About 90 of them) and I can’t figure out why on
Earth it did it this time, when I didn’t have this issue the last two
times I migrated the database to 0.6.0rc2 to make sure my migration went
smoothly. Anyone have any ideas?

I suspect something went wrong in migration
010_merge_behaviors_and_pages.rb where a method in the Page model is
called to update the published_at field during #save, though it
shouldn’t have changed anything. If you have access to the database
via a command line interface you can try to execute the following
update (make a backup first):

UPDATE pages SET published_at = created_at WHERE published_at IS NOT
NULL;

Maybe that helps.

Cheers,
Oliver

7

Hello all!

I’ve just finished porting my website to 0.6.0rc2 after running with
0.5.2 live and 0.6.0 on a test-and-build server. However, after got it
ported and did the db:migrate, I fell into an evil issue: For some
bizarre reason, db:migrate this time somehow decided it wanted to
re-sort all of the news articles I already had in place. Now, my article
order is totally random (About 90 of them) and I can’t figure out why on
Earth it did it this time, when I didn’t have this issue the last two
times I migrated the database to 0.6.0rc2 to make sure my migration went
smoothly. Anyone have any ideas?

I tried for temporary-basis tried to use by=“date” but that doesn’t
work. Anyone have any ideas what to do?

Thanks!
Andy

8

Hello Oliver!

No luck with that. I looked through the database, and the IDs look like
they’re right, as well as the created_at/published_at combo; I ran the
SQL just to try, to no avail. Where I do see an issue is in the
updated_at field (And looks like it might be the culprit) – It seems
that the migrate or the SQL server seemed to put datestamps that are
odd. Here’s a list of a few in direct sequential order in the news
section to show you what I mean:

id/created_at/updated_at

15/2007-01-29 15:39:26/2007-04-18 02:09:09
16/2007-01-30 13:49:28/2007-04-18 02:09:09
17/2007-01-31 13:55:49/2007-04-18 02:09:07
18 (Deleted)
19/2007-02-02 13:49:39/2007-04-18 02:09:09
20/2007-02-03 16:07:37/2007-04-18 02:09:08

Would it make more sense then to try

UPDATE pages SET updated_at = created_at WHERE updated_at IS NOT NULL;

Thanks for your time Oliver!
Andy

9

I upgraded Radiant from 5.2 to 6 and I noticed that I wasn’t able to
save modified pages, snippets or layouts.
Investigating a little I found that the rake db:migrate created new
columns in the db without filling them with default values.
In particular I saw that the lock_version is needed. I updated tables
inserting numeric values in that column and everything went ok.

–
Francesco L.
Ymir s.r.l.
Viale Verona 190/11
38100 Trento

10

Andrew K. wrote:

I tried for temporary-basis tried to use by=“date” but that doesn’t
work. Anyone have any ideas what to do?

Actually hold on with that UPDATE. Try replacing by=“date” with
by=“published_at” first.

Cheers,
Oliver