Hello, I tried to install Radiant, it seems to be almost installed,
but the links are broken (and the style sheet is unaccessible). Here’s
the content of my /home/charles/www/radiant/public/.htaccess:
General Apache options
AddHandler fastcgi-script .fcgi
#AddHandler cgi-script .cgi
Options +FollowSymLinks +ExecCGI
If you don’t want Rails to look in certain directories,
use the following rewrite rules so that Apache won’t rewrite certain
requests
Example:
RewriteCond %{REQUEST_URI} ^/notrails.*
RewriteRule .* - [L]
Redirect all requests not available on the filesystem to Rails
By default the cgi dispatcher is used which is very slow
For better performance replace the dispatcher with the fastcgi one
Example:
RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]
RewriteEngine On
If your Rails application is accessed via an Alias directive,
then you MUST also set the RewriteBase in this htaccess file.
Example:
Alias /myrailsapp /path/to/myrailsapp/public
RewriteBase /myrailsapp
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]
In case Rails experiences terminal errors
Instead of displaying this message you can supply a file here which
will be rendered instead
Example:
ErrorDocument 500 /500.html
ErrorDocument 500 “
Application error
Rails application failed
to start properly”
And here’s the public page: http://www.auriance.com/radiant/public/
I don’t know exactly what to comment/uncomment in .htaccess. Could you
help me please?
Thanks,
Could some one help me please?
–
Charles A. Landemaine.
For better performance replace the dispatcher with the fastcgi one
Example:
RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]
RewriteEngine On
Locate this block. The RewriteRule here isn’t supposed to be active.
Comment
it out like the lines before:
RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]
Leave the RewriteEngine line as-is.
FYI. http://www.seancribbs.com/ is down
I’m attempting to use Sean’s page_attachments extension but I’ve
installed it, migrated for it, and don’t see anything different in my
admin interface.
What am I missing? I looked for info at Sean’s site, but its down,
and the README from the extension is empty.
Thanks for any help.
(running locally on OS X / Locomotive / MySQL / Radiant 0.6.1)
-Jim
Geez. You’d think that all the money we pay for these extensions
would help… oh, wait. 
Thanks Sean. I appreciate the work.
You came to right place, Jim. I’ve been having issues with TxD,
actually - they bot my mongrel process regularly. The SVN should still
work, though.
Anyway, I have not finished updating the extension for 0.6.x (nor ldap,
aggregation, mailer, search, oy! the list goes on). The primary problem
is that it changes the page-edit interface directly by overriding the
template, but it should use another method. I apologize for my slowness
on this, but I have a couple other projects going full-steam at the
moment. I might have a chance to update it while flying out of town on
Thursday. In the meantime, I would graciously accept patches!
Sean
On 5/9/07, Sean C. [email protected] wrote:
Updated!
Sweet!
- Now uses attachment_fu instead of acts_as_attachment.
Interesting. I couldn’t make attachment_fu work with Radiant (there were
issues with resolving its internal dependencies).
- Uses svn:externals to get the latest attachment_fu. Not sure if
this will work with an export method (svn gurus please comment?) of
installation.
Why not? It’s the same to Rails. It makes a difference depending on how
you
deploy.
Awesome! I’m looking forward to trying this out.
On 5/9/07, Sean C. [email protected] wrote:
- Uses svn:externals to get the latest attachment_fu. Not sure if
this will work with an export method (svn gurus please comment?) of
installation.
I just tested exporting it… it does indeed grab attachment_fu
correctly.
Thanks for all your hard work, Sean.
Matt
On 5/9/07, Sean C. [email protected] wrote:
Are you saying the extension doesn’t work for you? I haven’t tried it
in instance mode yet.
No, the plugin didn’t work for me out of the box. I wanted to use
has_attachment on some models in my extension.
Dependencies code was unable to resolve some modules inside AttachmentFu
so
I needed to require stuff manually. I talked with Rick O. and found
out
the code is perfectly fine, but for some reason doesn’t work in a
Radiant
project.
It was a couple days ago with the latest trunk checkout (then).
Just FYI,
Initially I tried dumping the whole plugin into the lib directory of the
extension, then requiring attachment_fu/init. That didn’t work. Next I
tried taking the contents of init.rb and putting it in the activate
method of the extension, which worked previously. Still didn’t work. I
also tried adding the lib directory of the attachment_fu plugin to the
$LOAD_PATH (ugly hack, I know). Still didn’t work. In the end I had to
revert to the method I took when I was using acts_as_attachment, and
this can be used in general for any extensions that include plugins in
their lib directory.
- Take the entire contents of the init.rb file and put it somewhere in
the activate method of your extension.
- Export or use svn:externals to dump the contents of the plugin’s lib
directory. If there are files in the root of the plugin’s lib
directory, you won’t be able to use svn:externals. I had to do this
with ‘geometry.rb’ from attachment_fu.
- Et voila!
While there didn’t seem to be any fundamental name-collision between
Radiant and attachment_fu, be careful that plugins you include in an
extension don’t clash with the ones from other extensions. In the
future we’ll have a way to specify extension dependencies, which should
hopefully abate some issues.
Sean
Are you saying the extension doesn’t work for you? I haven’t tried it
in instance mode yet.
Sean
When installing the extension on my TxD account, I found ImageScience
was not configured properly, or one doesn’t have access to compilers
to handle RubyInline or something like that. If someone else has
gotten this to work, let me know. Otherwise, you can add this option
to the “has_attachment” call in app/models/page_attachment.rb:
:processor => :Rmagick
Good luck!
Sean
On May 9, 2007, at 2:37 PM, Sean C. wrote:
- REQUIRES Radiant edge r432 or greater (critical enabling change).
To get that, run
rake radiant:freeze:edge
Sean
Sean,
since this requires r431, are we to assume that there will be no
page_attachments plugin for 0.6.1?
Steven S. wrote:
Why doesn’t page attachments show up in snippets?
Because it attaches to a Page?
Cheers,
Mohit.
4/17/2009 | 2:45 AM.
You mean because the name is page attachments? I think it’d be
convenient to locate attachments in snippets too. Snippets need
images just as much at pages. If a snippet had images maybe pages
wouldn’t need quite as many. I guess, next your going to tell me
layouts don’t need attachments either. Sure would be convenient.
Steven
It’s a critical blocker, unless you want to go in and edit the
template yourself. So no. I assume we’ll see 0.6.2 pretty soon.
Sean
“inherited from parent pages”
Yeah that makes perfect sense and I’m glad I understand it now.
That’s useful information. Anyone using textile editor? It’s pretty
cool but I was thinking the add image could use a little souping up.
It’d be nice if when you selected attachments it’d show all the
attachments that it inherits. Does that sound useful to anyone else?
I keep going back and forth in which is better attachments or
paperclipped they both are very useable and surprisingly different.
Steven
Steven,
Attachments can be inherited from parent pages. So if you attach an
image to your Home page, then it will be available to all pages,
layouts and snippets.
Page attachments is a bit fussy: when you ask for a file that doesn’t
belong to the current page (or its ancestors) it raises an exception.
It could be dangerous if you were to call <r:attachment
name=“image.jpg”/> in a snippet or layout. If that snippet/layout was
called from a page which didn’t have “image.jpg” attached, and nor did
any of its ancestors, then an exception would be raised, and the page
would not render. However, if you attached a “image.jpg” file to the
home page, then it would be available to every page in the site, and
the problem above would be avoided.
Of course, you could attach an “image.jpg” file to any section. Then
that section, and all its ancestors would use that file instead of the
one attached to the home page.
Does that make sense? The inheritance mechanism means that you can
treat page attachments in a similar fashion to page parts. When you
look at it that way, it should no longer seem necessary to be able to
attach files to snippets and layouts.
Cheers,
Drew
HI Steven
Steven S. wrote:
You mean because the name is page attachments? I think it’d be
convenient to locate attachments in snippets too. Snippets need
images just as much at pages. If a snippet had images maybe pages
wouldn’t need quite as many. I guess, next your going to tell me
layouts don’t need attachments either. Sure would be convenient.
I’m sorry if my answer came across as rude/ mean (cut me some slack - it
was sent at 2:45AM) - I didn’t mean just the name. I meant to imply
that it attaches to pages and is designed for that, while snippets often
are included in multiple pages and may have different contexts. (I have
some times used a single known page as the base referred from snippets).
But definitely the explanation that followed my email was better!
Cheers,
Mohit.
4/17/2009 | 1:03 PM.