Hi,
I’ve managed to set two radiant sites using apache 1.3 and fcgi. Now I
can
access them site at DOMAIN FOR SALE and
DOMAIN FOR SALE
However, I can’t navigate the sites because all the links are generated
using the default path /
So if I click the News section for example, the site refers me to
DOMAIN FOR SALE instead of
DOMAIN FOR SALE.
Where do I set the default url path for each of my radiant sites?
Jose.
The easiest way is to set your DNS to point to your radiant sub dir.
Else
you could fiddle with the routes.rb file to fit your needs.
Thanks for the reply.
Do you know where exactly do I have to make the changes?
Perhaps # Site URLs ?
Jose.
Ok, let me exaplin this as easily as I can.
Radiant generates an html page with the following div
What I want to do is to force, in <a href=>, “/myapp/”
So I would get /myapp/recursos/
and eveything will work fine : )
Any ideas?
I think what you describe should be fairly easy to solve with
routes.rbhacks. Else your COULD create an url filter in the front
controller to add
“/myApp/” in front of all incoming URLS. Sorry I can’t be more specific
at
the moment…I’m at work and am supposed to be debugging some 2K lines
of
.Net code 
Jose,
I’d fiddle with the lines below (which correspond to lines > 56 in
routes.rb
):
# Everything else site.connect '*url', :action=> ‘show_page’
end
Ruben,
Thanks for your help.
I’ve changed routes.rb and nothing happens : ( Perhaps I’m not sure of
what I’m doing.
I’ve also found this ticket http://dev.rubyonrails.org/ticket/5420
It says to add “ActionController::AbstractRequest.relative_url_root =
‘/subdir’” to both routes.rb and environment.rb
Has anybody used this method?
Jose.
I’ve been playing with the Mental branch this weekend to test-out the
work being done on the new Radiant Extensions concept. I thought I
just put down a quick narrative of my experience with it to give
those who’ve not had a chance to check it out recently a preview of
what’s to come. There is some work still to do here, but as far as I
can see a lot of work has been done in the last few weeks.
Everything is working pretty well… I can generate and extension
“script/generate extension calendar” and modify the necessary lines
in the extension activate method to make it show-up as an admin tab.
Then I was able to dump a bunch of pre-existing models and migrations
from the Calendar application I want to integrate with ease.
Understanding that this is very much a work in progress, I did want
to make one note of interest:
When I created the Calendar extension and then ran my migrations I
found out quickly that it doesn’t work well to have a model named the
same as the Extension (I had a Calendar model as well). I renamed my
Calendar model, reversed the migrations by hand and everything
migrated up fine the second time around.
Then in my calendar controller I dumped a scaffold :event_calendar
and voila! I had a nifty interface for adding and removing calendars
right within Radiant admin.
I know I for one see the maturation of these extensions as an
important turning-point for Radiant as a project.
IMHO this robust and Rails friendly way of extending Radiant is key
to allowing it to remain spartan. Though I might still prefer the CMS
to be the plugin a la Comatose, this level (and method) of
extensibility will mean the best of both worlds for most of those who
just have CMS needs + a little something else.
So, John, with crystal ball in hand, what do you see as a likely
timeframe for an official release which includes both Extensions and
Page Types?
Jose,
That Rails ticket is exactly what I was talking about. I tried and it
worked
very well. The only problem I see if the URL requests collide with some
controller/setting of Radiant…if you have a development environment
tried
there first before deploying.
I just want to second this, the extensions are very well thought out
and pretty easy to use even in their very raw state. I have a very
simple assets management system (based on acts_as_attachment) that
took maybe a few hours to set up. Most of that was making sure that
the views integrated nicely into Radiant.
I found another small gotcha with the migrations. If you have more
than one extension, you do have to make sure that the migrations are
properly numbered. 2 “No. !” doesn’t work. And the rake task provides
no feedback, I have gotten used to the new Rake task telling me what
it is doing. Not a biggie, but it would be nice.
All in all, this is a really great addition to Radiant and vastly
increases its value, at least to me. I can’t wait until an official
release.
One sort of funny note: I tried to add tagging to Radiant while I was
at it. I used the acts_as_taggable plugin (not the Gem) from DHH and
only had to add one line to the Page model and one line in the
control, plus a very small change in the views. It worked great.
Except that it totally broke the Radius tagging system and the front
end rendered nothing.
Just for fun and because I had just watched the original Battlestar
Galactica with it’s robotic “Daggits”, I renamed the plugin to
“acts_as_daggable”, changed all the instances of “tag” to “dag” and
the thing works. Really well, actually. So adding tagging to Radiant
should be very easy, but we do have to watch our namespaces.
Keith B.
[email protected]
Ruben,
I also found this
http://www.hostingrails.com/forums/rails_coding_thread/37
I think this is what I need. It says that
ActionController::AbstractRequest.relative_url_root “Essentially tells
Rails to tack on an extra ‘/subdir’ to every URL it writes.”
I’ve already used ActionController::AbstractRequest.relative_url_root =
“/subdir” at the bottom of environment.rb and nothing happens.
I’m really confused. Shouldn’t hosting different rails applications on
different subfolders be a common task?
jose.
Loren J. wrote:
I know I for one see the maturation of these extensions as an
important turning-point for Radiant as a project.IMHO this robust and Rails friendly way of extending Radiant is key
to allowing it to remain spartan. Though I might still prefer the CMS
to be the plugin a la Comatose, this level (and method) of
extensibility will mean the best of both worlds for most of those who
just have CMS needs + a little something else.
I agree.
So, John, with crystal ball in hand, what do you see as a likely
timeframe for an official release which includes both Extensions and
Page Types?
That depends. Off hand I think there is at least another two weeks of
work needed on it. Maybe four.
I’m not going to have a lot of time to work on it between now and the
end of the year (got to work to pay the bills), but there’s a chance
that things may pull together in time for a Christmas release. More
realistically we are probably talking about mid- to late January.
There are at least two major things that need to be worked out:
Activation and deactivation of extensions within the admin UI
The scripts to manage the upgrade from 0.5.2
The first is probably something I am going to need to work out on my
own. The second is something that I would love help with.
Also, the more people that can jump on board and start using the code in
the mental branch the better. This is a major upgrade and your comments
and feedback are vital.
–
John L.
http://wiseheartdesign.com
Jose,
It is a common task. The disconnect happens between Radiant and the
generated page. Radiant will know to add the URL prefix, but any manual
links won’t be automatically updated/parsed on the way out.
If you are using Apache, make sure to put this line in your .htaccess:
RewriteBase /subdir
Cheers,
Sean
Keith B. wrote:
I just want to second this, the extensions are very well thought out and
pretty easy to use even in their very raw state. I have a very simple
assets management system (based on acts_as_attachment) that took maybe a
few hours to set up. Most of that was making sure that the views
integrated nicely into Radiant.
Would you be willing to share that with the rest of us? I’d like to have
an assets extension in the repository when the next release becomes
available.
I found another small gotcha with the migrations. If you have more than
one extension, you do have to make sure that the migrations are properly
numbered.
More than one extension? Please elaborate.
2 “No. !” doesn’t work.
???
And the rake task provides no
feedback, I have gotten used to the new Rake task telling me what it is
doing. Not a biggie, but it would be nice.All in all, this is a really great addition to Radiant and vastly
increases its value, at least to me. I can’t wait until an official
release.One sort of funny note: I tried to add tagging to Radiant while I was at
it.
I’d love to see the implementation for this as well.
I used the acts_as_taggable plugin (not the Gem) from DHH and only
had to add one line to the Page model and one line in the control, plus
a very small change in the views. It worked great. Except that it
totally broke the Radius tagging system and the front end rendered nothing.
That’s probably because Radiant now has a “Taggable” module for Radius
tags. Perhaps we should move it into the Radiant namespace
(Radiant::Taggable).
–
John L.
http://wiseheartdesign.com
Keith,
I just want to second this, the extensions are very well thought
out and pretty easy to use even in their very raw state. I have a
very simple assets management system (based on acts_as_attachment)
that took maybe a few hours to set up. Most of that was making sure
that the views integrated nicely into Radiant.
Are you using this mental branch install in “production” i.e. as a
live site?
Loren J.
[email protected]
Sean,
Thanks for your reply. Does that rule go into my app’s public folder? Or
in the main public_html folder?
I’ve already done that in my app public folder and nothing.
: /
The only page that renders is the main page. So at least my apache-fcgi
configuration is working. And if I manually type in the url’s they work
fine. The problem is that my site is generating links from the “root”
folder, instead from it’s own subdirectory.
jose.
have
an assets extension in the repository when the next release becomes
available.
Sure, it is very simple, but a good start. I have tried to integrate
the “look and feel” of Radiant as much as possible. Let me clean it
up a bit and I will provide an svn link. Like the acts_as_taggable
plugin, I don’t have any radius tags for it yet, only the backend. I
will be getting to those next.
???
I had two separate plugins, one for the tagging and one for the
assets. I ran the tagging migration first. then I tried to run the
assets. I believe it didn’t run the assets until i changed the
migration number from 001 to 002… though now that I think about it,
I am not so sure. The lack of feedback on the rake task might have
confused me. (I am easily confused, especially hacking in the middle
of the night)
a very small change in the views. It worked great. Except that it
totally broke the Radius tagging system and the front end rendered
nothing.That’s probably because Radiant now has a “Taggable” module for Radius
tags. Perhaps we should move it into the Radiant namespace
(Radiant::Taggable).
If you moved the Taggable module into it’s own namespace, i think we
could have basic tagging very easily. I had the admin side part
programmed literally in a matter of minutes. The changes need are
very small, if you use the plugin. Of course, this doesn’t include
the work for the Radius tags, but that shouldn’t be too hard. Even
without using the plugin, it wouldn’t be that hard. The plugin
provides a lot of functionality, but does has some quirks. It doesn’t
accept comma separated lists for instance, which makes multiword tags
hard. There are a lot of changes floating around on the wiki though.
No, not yet. I hope to use it for something soon. I got the database
moved over today from 0.5.2, without too many problems (that I have
found). I haven’t gotten my custom tags going yet, but as soon as
those get going I am going to deploy it to a test server. Should it
survive that, then I will use it on a small site I have.
Keith B.
[email protected]
Tel: +49-7731-7983830
Hi,
I found this by John L. on the ruby archive
http://www.ruby-forum.com/topic/82446
He wrote:
“I wouldn’t recommend running Radiant in a sub-directory. It isn’t
designed with this in mind.If you’d like to just have Radiant serve
files
from a specific directory, the simplest thing would be to change the
rewrite rules inthe .htaccess file (or equivalent for your Web server).
What exactly are you trying to do? and why?”
What I’m trying to do is to set two different websites like this:
mydomain.org/app1
mydomain.org/app2
mydomain.org is an institution comprised of two departments. Each
department wants to have their own database and their cms to administer
their websites.
I’ll explain what I’ve done so far:
In my httpd.conf I’ve included
AddHandler fcgid-script .fcgi IPCCommTimeout 40 IPCConnectTimeout 10 DefaultInitEnv RAILS_ENV production SocketPath /tmp/fcgidsockAnd,
I’ve made a ln -s from home/myapp/public/ to /var/www/html/myapp
That way when I go to DOMAIN FOR SALE I get the main page of my
website.
From there on, all the autogenerated links (ex. sitemap snippet) direct me
to DOMAIN FOR SALE instead of to DOMAIN FOR SALE
The thing is that I’ve tried a bunch of different combinations and
nothing
seems to make a difference.
I’ve created a virtual host for myapp
I’ve included in my environment.rb
ActionController::AbstractRequest.relative_url_root = “/myapp”
In .htaccess I’ve uncommented RewriteBase /myapp
And I’ve followed the following articles in configuration
combinations
I can’t even remember
http://www.hostingrails.com/forums/wiki_thread/6
http://wiki.rubyonrails.org/rails/pages/HowtoDeployMoreThanOneRailsAppOnOneMachine
http://blog.duncandavidson.com/2005/12/real_lessons_fo.html
Is this a Radiant problem then? I got the idea of multiple Radiant’s in
sbdirectories form Dave T.’ Agile Web D. with Rails.
Jose.
On 14/11/2006, at 8:13 AM, [email protected] wrote:
rewrite rules inthe .htaccess file (or equivalent for your Web
server).
What exactly are you trying to do? and why?"What I’m trying to do is to set two different websites like this:
For a really simple (but not the best) solution, you could make a
root-page for each app with the same slug as the subdirectory. eg.
for app1:
app1/
±- home/
±- about/
±- contact/
etc… One problem that you might have is if you use <r:find>, then
it would start to get a little bit messy. But after thinking for a
bit, it might make more sense for the people that manage the site
arent really technical… keep us posted on what you come up with 
bodhi
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs