Technically, its a Radiant issue but it shows up in Extensions that
still use ERB (or at least if your ERB templates have a
or tag). That's one of the reasons I went to Haml so quickly. If you want to know more, read my ticket here: http://dev.radiantcms.org/ticket/642 Anyway, by moving Styles 'n Scripts templates to Haml, the issue was bypassed. Go get 0.3.1 (or keep your Radiant at 0.6.6 to stay pre Haml). -Chris
Has anyone else noticed their styles being kicked over to the right
every time they save. This is crappin’ my style of stylin’. A few
saves and man it’s off the page.
For anyone (now or in the future) following this thread, I’ve identified
the issue nurullah mentioned here. It is indeed a bug with the SnS
extension and will be resolved in the upcoming 0.5 release.
For those interested, it’s caused by the interplay between the way SnS
extension stores its settings, and the way Radiant rake tasks are
performed.
SnS creates its default settings and then overwrites those with any
custom settings during initialize.
Well, it turns out that extensions are initialized during any Rake task
– including ‘rake db:bootstrap’ So, if you’re including SnS in a
brand new installation of Radiant (not already bootstrapped), when you
try to create the database, the SnS extension gets initialized and tries
to store some settings in the not-yet-created config table. Doh!
Those adding SnS to an existing Radiant install will never see this
issue.
-Chris
Just installed .3.1 Nice job. Thanks
What was the fix for SnS?
I saw the same problem with RBAC Base on a clean install (which I must
not have tried when we created it) and haven’t had time to look into it.
-Jim
I’m not opposed to your solution in anyway. I think it’d be helpful. I
just think that the “right” solution for my extension would be to:
* have my extension's default settings installed via the initial
migrate task
* offer a rake task to allow administrators (server admins) to
change the css/js settings on the fly. This need only be run once
manually (after bootstrap) and not at every init. I'd probably
throw in a "restore_defaults" task too.
I designed the StylesNScripts::Config bit with the future UI designs of
Radiant in mind – for the day when we’ll have a settings/configuration
admin panel where extensions can add into the Radiant UI (instead of
sticking settings in some tab or hard coded and loaded at init).
My problem is that I broke this rule and made the settings load during
init “just for now” and shot myself in the foot. If I do what I’ve
outlined above, it’ll be trivial to hook into Radiant’s shiny new
settings UI when it arrives
-Chris
I just outlined the fix in a reply to Sean’s post. It’s a little more
elaborate (though I think more elegant) than I’d post here.
If you’re trying to get it to “just work for now” you can simply comment
out the following line from the styles_n_scripts_extension.rb file:
include CustomSettings
Run your “rake db:bootstrap” to create the database, then un-comment
that line back in.
-Chris
Chris,
We might be able to make a rake task that loads the environment with no
extensions installed. In fact, it should be as easy as something like
this:
task :minimal_environment do
Radiant::Initializer.run do |config|
config.extensions = []
end
end
Then we could make db:bootstrap and anything else that needs to prevent
extensions from loading depend on that instead of the default
:environment task.
Sean
I’m having a prob installing the rbac_base extension. I’ve searched the
list and found that the devs of this and another extension for radiant
seem to have the same problem.
Following the docs:
rake db:migrate:extensions
rake aborted!
SQLite3::SQLException: no such table: roles: SELECT * FROM roles
I look in …rbac_base/db/migrate and find the appropriate migrations to
create the needed tables. Aren’t these the migrations that are trying
to be run by db:migrate:extensions? When I browse the list archives I
find extension devs talking amongst themselves 2 months ago about this
problem. Since I’m new to ruby, rails, radiant and extensions this is
way over my head. Does anyone have a suggested solution? (other than
read the code for all the above) 
–
Whatever you can do, or dream you can, begin it! Boldness has genius,
magic, and power in it. ~Goethe
Faith makes things possible, not easy. ~Author Unknown
Burt Adsit
Sean C. wrote:
end
Then we could make db:bootstrap and anything else that needs to
prevent extensions from loading depend on that instead of the default
:environment task.Sean
I tried the idea above (added it to my extension – not Radiant) and set
up my extension’s tasks like:
task :migrate => :minimal_environment do
…
I got an error that the constant StylesNScripts wasn’t defined (at least
that’s what I remembered).
I probably just did something wrong here but I wanted to post the result
as an FYI.
-Chris
Burt Adsit wrote:
to create the needed tables. Aren’t these the migrations that are
trying to be run by db:migrate:extensions? When I browse the list
archives I find extension devs talking amongst themselves 2 months ago
about this problem. Since I’m new to ruby, rails, radiant and
extensions this is way over my head. Does anyone have a suggested
solution? (other than read the code for all the above)
Hi Burt,
I may be way off here, but two questions for you:
Cheers
Mohit.
On Aug 23, 2008, at 1:31 AM, Mohit S. wrote:
look in …rbac_base/db/migrate and find the appropriate migrations
- Did you bootstrap the database for Radiant?
- Any chance that your environment is different? I mean did you
bootstrap the production database and are now doing Rake without
specifying the environment, and therefore ending up with development
being migrated?Cheers
Mohit.
Burt,
I don’t know how, but I never saw your original message, so I’m glad I
caught Mohit’s response.
I don’t recall the exact problem, but I know that Radiant will try to
load extensions if it hasn’t been bootstrapped. So Mohit’s first
question is a good one. Have you bootstrapped already?
If not, move the extension up into vendor (and out of the extensions
directory), rake db:bootstrap, then move it back and rake
db:migrate:extensions.
We’ll be adding some other features to rbac_base in the future, so
please send any suggestions that you have.
RBAC was built to allow extension developers to check user roles for
extensions. It does not alter roles for the normal functions of
Radiant (pages, layouts, snippets).
It may do that in the future. I’m personally on the fence about
whether or not Radiant should go down the road with a complicated role
structure in the core.
Jim G.
Thanks guys, I’ll try your suggestions. I’ve been sidetracked the past
few days installing linux/vista dual boot on my laptop. I’m finding that
alot of developmental probs originate in the windows environment. Gotta
do it. I’ll be running on *nix anyway. My problems couldn’t possibly
originate in my own ignorance. (sigh).
–
Whatever you can do, or dream you can, begin it! Boldness has genius,
magic, and power in it. ~Goethe
Faith makes things possible, not easy. ~Author Unknown
Burt Adsit
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