Re: [Radiant] rbac install prob
Burt Adsit wrote: 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) ;) Hi Burt, I may be way off here, but two questions for you: 1. Did you bootstrap the database for Radiant? 2. 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. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Thanks for SnS Extension
Chris Parrish wrote: I've been off list for about two weeks now and I just wanted to say how heartwarming it is to come back to something like this. As any developer, I'm glad to know my work is being used and is helpful to someone. But you don't necessarily expect any public recognition. I've always appreciated how generous, knowledgable, and super professional this community is -- this just takes the cake. Oh, and guys, I've obviously been busy here lately but let me know if there's anything I can do to help with the documentation, too. Chris, Like attracts like :) You churn out great code - the documentation and gratitude is the least that should follow! Cheers, Mohit. 8/23/2008 | 1:28 PM. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Thanks for SnS Extension
I've been off list for about two weeks now and I just wanted to say how heartwarming it is to come back to something like this. As any developer, I'm glad to know my work is being used and is helpful to someone. But you don't necessarily expect any public recognition. I've always appreciated how generous, knowledgable, and super professional this community is -- this just takes the cake. Oh, and guys, I've obviously been busy here lately but let me know if there's anything I can do to help with the documentation, too. -Chris Jamey Cribbs wrote: Deal. It's the least I can do for such a great CMS and a great extension. I will try to get to this today. Jamey On Mon, Aug 18, 2008 at 11:05 AM, Mohit Sindhwani <[EMAIL PROTECTED]> wrote: Jamey Cribbs wrote: Just wanted to publicly thank Chris Parrish for the Styles 'n Scripts extension. I have been wanting to try this extension for a while, so, over the weekend, I upgraded one of my radiant apps to 0.6.9 and installed the extension. Very nice! It's great to be able to make a minor change to the site's css and not have to do a deploy. Thanks, Chris! Jamey Cribbs Jamey, can I lean on you for some support towards the Summer Reboot documentation [1]? There's a part there for SnS under Chapter 1 of the documentation. I'll make you a deal - if you'll do the basic text, I'll do the proofreading, test out that it works, and ensure that the instructions work and add screenshots, if needed. If you're busy, just ignore this message. Cheers Mohit. [1] http://wiki.radiantcms.org/Summer_Reboot ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Pages with auto-tabs for layout content parts
Read this http://wiki.radiantcms.org/Customizations_II And try this http://github.com/Squeegy/radiant-settings/tree/master or http://github.com/santry/radiant-default-page-parts-extension/tree/master On Aug 22, 2008, at 3:53 PM, Jordan Isip wrote: Hi all, When you create a custom layout, is it possible to have it's "content parts" automatically be added as tabs when you create/ modify a page that uses the custom layout? For example, if you create a layout that includes a content part such as: Is it possible to automatically create a tab on the create/modify page form (if the custom layout is selected). So the end result would look like this: http://img.skitch.com/20080822-eubnpcyis48r5214rqi13yf9sw.png Does Radiant support this (or maybe an extension)? Thanks in advance for your help! Jordan ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] Pages with auto-tabs for layout content parts
Hi all, When you create a custom layout, is it possible to have it's "content parts" automatically be added as tabs when you create/modify a page that uses the custom layout? For example, if you create a layout that includes a content part such as: Is it possible to automatically create a tab on the create/modify page form (if the custom layout is selected). So the end result would look like this: http://img.skitch.com/20080822-eubnpcyis48r5214rqi13yf9sw.png Does Radiant support this (or maybe an extension)? Thanks in advance for your help! Jordan ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] How to install rails plugin to radiant
On Mon, Aug 18, 2008 at 2:54 AM, Mohit Sindhwani <[EMAIL PROTECTED]> wrote: > Hamish Rickerby wrote: >> >> I personally am looking for a way to package plugins as part of an >> extension, rather than having to pull them out separately, so that the >> extension is completely self contained. Anyone know how to do that? >> >> ::: hamish rickerby ::: >> http://glimmerdesign.com >> > > Hamish, > > I think you can install it into the vendor directory of your extension. My > test install here has a directory as such > vendor\extensions\reorder\vendor\plugins\acts_as_list > > which suggests that acts_as_list is installed as a plugin in the vendor > directory of the reorder extension under vendor of my project. You can? Sweet, was wondering about that. What happens if two extensions are using two different versions of the same plugin? ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Does database_form extension work with Rails 2?
Yup, there's two other very recent threads about this issue. Use this plugin instead: http://github.com/joelw/database_form/commits/master And someone should update the radiant site to point at that plugin instead, zapnap's is broken on recent radiant/rails. Joe On Thu, Aug 21, 2008 at 1:20 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On Thu, 2008-08-21 at 11:20 -0400, Josh Schairbaum wrote: >> Don't feel bad... there's a reason why that would come to the front of >> my mind. :) > > Have you ever had to deal with the "wrong number of arguments (1 for 2)" > error? I finally got the form built and pages all set up, tried out the > form and BANG, I have that stupid error. It's why gave up on the > extension the last time I tried to use it. > > If you have ever seen this and know how to fix it, please let me know. > > > > Thanks, > > Nate > > ___ > Radiant mailing list > Post: Radiant@radiantcms.org > Search: http://radiantcms.org/mailing-list/search/ > Site: http://lists.radiantcms.org/mailman/listinfo/radiant > ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Does database_form extension work -- Solved!
Doh, I answered you with this. :) zapnap should merge that fix into his plugin, or the radiant extension page should link to the working plugin. Joe On Thu, Aug 21, 2008 at 8:26 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Just so that it's on the record for the next time that somebody has a > similar problem. I found the answer to the "wrong number of arguments (1 > for 2)" happening on the database_form extension. The redirect needs to > have the status code "302" added to it. > > This: > ... > if save_form and redirect_to > response.redirect(redirect_to) > else > super(request, response) > end > ... > > Becomes this: > ... > if save_form and redirect_to > response.redirect(redirect_to, "302") > else > super(request, response) > end > ... > > In tracking down this problem I found that Joel Williams had forked the > database_form extension and he had solved the problem I was running > into. As his fork includes some other added functionality, I have > switched to it instead of the original extension from Zapnap (Nick > Plante). > > Back to your regularly scheduled program... > > > ~Nate > > ___ > Radiant mailing list > Post: Radiant@radiantcms.org > Search: http://radiantcms.org/mailing-list/search/ > Site: http://lists.radiantcms.org/mailman/listinfo/radiant > ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Does database_form extension problems?
Ah, here's the one I'm using:
http://github.com/joelw/database_form/commits/master
On Fri, Aug 22, 2008 at 12:06 PM, Joe Van Dyk <[EMAIL PROTECTED]> wrote:
> I found a database_form extension plugin somewhere that seems to be
> working, but hell if I remember where it came from.
>
> This is my process function:
>
> def process(request, response)
>@request, @response = request, response
>@form_name, @form_error = nil, nil
>if request.post?
> @form_data = request.parameters[:content].to_hash
>
> # Remove certain fields from hash
> form_data.delete("Submit")
> form_data.delete("Ignore")
> form_data.delete_if { |key, value| key.match(/_verify$/) }
>
> @form_name = request.parameters[:form_name]
> redirect_to = request.parameters[:redirect_to]
>
> if save_form and redirect_to
>response.redirect(redirect_to, "302")
> else
>super(request, response)
> end
>else
> super(request, response)
>end
> end
>
>
> Seems to work fine.
>
> On Thu, Aug 21, 2008 at 2:29 PM, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
>> It looks like the problem with the database_form extension is with the
>> redirect. I don't know exactly how to fix it or even how to fully
>> explain why it's not working. But, I did find what looks like a fix on
>> the radiantcms-dev google group.
>>
>> This is where things are going wrong in the extension (lines 22-26) of
>> the extension:
>>
>> if save_form and redirect_to
>> response.redirect(redirect_to)
>> else
>> super(request, response)
>> end
>>
>>
>> This is the fix that Charlie Robbins suggested
>> (link:
>> http://groups.google.com/group/radiantcms-dev/browse_thread/thread/783c07a89beafcf5):
>>
>> #Trim the leading / off the slug
>> redirect_to = redirect_to.gsub(/^\//, '')
>> @response.body = redirect_to
>> @response.body = Page.find(:first, :conditions => ["slug = ?",
>> redirect_to]).render
>>
>>
>> Now cannot really make heads or tails of this. Can anybody explain what
>> is happening here? The author of the extension wrote in the ReadMe that
>> the extension worked with Radiant 0.6.4. Could there be something in
>> Radiant that changed to break this extension or was it not properly
>> written to begin with? Not trying to step on any toes, but it seems like
>> this extension would be more sought after and it would be nice to see it
>> working properly.
>>
>> When I substitute the "fixed" code from Charlie, I get this error:
>> You have a nil object when you didn't expect it!
>> The error occurred while evaluating nil.render
>>
>> Any insight would be appreciated.
>>
>>
>> Thanks,
>>
>> Nate
>>
>> ___
>> Radiant mailing list
>> Post: Radiant@radiantcms.org
>> Search: http://radiantcms.org/mailing-list/search/
>> Site: http://lists.radiantcms.org/mailman/listinfo/radiant
>>
>
___
Radiant mailing list
Post: Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Does database_form extension problems?
I found a database_form extension plugin somewhere that seems to be
working, but hell if I remember where it came from.
This is my process function:
def process(request, response)
@request, @response = request, response
@form_name, @form_error = nil, nil
if request.post?
@form_data = request.parameters[:content].to_hash
# Remove certain fields from hash
form_data.delete("Submit")
form_data.delete("Ignore")
form_data.delete_if { |key, value| key.match(/_verify$/) }
@form_name = request.parameters[:form_name]
redirect_to = request.parameters[:redirect_to]
if save_form and redirect_to
response.redirect(redirect_to, "302")
else
super(request, response)
end
else
super(request, response)
end
end
Seems to work fine.
On Thu, Aug 21, 2008 at 2:29 PM, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> It looks like the problem with the database_form extension is with the
> redirect. I don't know exactly how to fix it or even how to fully
> explain why it's not working. But, I did find what looks like a fix on
> the radiantcms-dev google group.
>
> This is where things are going wrong in the extension (lines 22-26) of
> the extension:
>
> if save_form and redirect_to
> response.redirect(redirect_to)
> else
> super(request, response)
> end
>
>
> This is the fix that Charlie Robbins suggested
> (link:
> http://groups.google.com/group/radiantcms-dev/browse_thread/thread/783c07a89beafcf5):
>
> #Trim the leading / off the slug
> redirect_to = redirect_to.gsub(/^\//, '')
> @response.body = redirect_to
> @response.body = Page.find(:first, :conditions => ["slug = ?",
> redirect_to]).render
>
>
> Now cannot really make heads or tails of this. Can anybody explain what
> is happening here? The author of the extension wrote in the ReadMe that
> the extension worked with Radiant 0.6.4. Could there be something in
> Radiant that changed to break this extension or was it not properly
> written to begin with? Not trying to step on any toes, but it seems like
> this extension would be more sought after and it would be nice to see it
> working properly.
>
> When I substitute the "fixed" code from Charlie, I get this error:
> You have a nil object when you didn't expect it!
> The error occurred while evaluating nil.render
>
> Any insight would be appreciated.
>
>
> Thanks,
>
> Nate
>
> ___
> Radiant mailing list
> Post: Radiant@radiantcms.org
> Search: http://radiantcms.org/mailing-list/search/
> Site: http://lists.radiantcms.org/mailman/listinfo/radiant
>
___
Radiant mailing list
Post: Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] rbac install prob
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 ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] New metatags for keywords, description feature
Jim, Where I work, I designed our system such that we have an in-memory representation of all the nodes in our site which was (somewhat) independent of the index.jsp that defines the node. We hang a lot of metadata off these nodes, a lot of which is inferred. This lets us do things like have a multilingual site (simply create index.jsp and index_fr.jsp or index_xu.jsp) and so on. One of the most useful idea we included (at least in so far as this thread is concerned) is the idea of node parameters. These parameters are name/value pairs associated with a node and can be used for absolutely anything you want (the list of parameter names is arbitrary). The useful bit is that when you define the parameter, you can say if its inherited no not. This is sort of the opposite of how this sort of thing is done in radiant where its the usage of something (a page part or a meta) that specifies if its inherited, I specify that at definition. This has a big advantage: sparse population. This lets me set a default on some node (say the root) and have it inherited. I can then change it for some descendant (so far no difference). However, if I want that change to ONLY affect that one page and not its parents, setting the value to being "local" (not inherited) means that the original value will be used for the children of the page that overrides the value. Since we use these value for more than merely creating HTML Meta tags, this becomes very useful. i would suggest that in addition to tests to see if meta is set (or not) that you include tests for the value. This will allow for some very interesting behaviour. On 22-Aug-08, at 9:56 AM, Jim Gay wrote: I'm resurrecting this thread so that I can express my personal hatred of the meta tags. I propose that they be removed, or handled in a different way (and yes I volunteer myself to write the code for it). I'll be doing some thinking about and how to better handle the many options for HTML, but if anyone is interested, I created this extension http://github.com/saturnflyer/radiant-seo_help-extension/tree/master which provides an "inherit" attribute on r:meta and adds r:if_meta and r:unless_meta -Jim On May 19, 2008, at 4:13 PM, Chris Parrish wrote: I can't speak for the core team but I wrote my own extension to do the same thing for clarity and simplicity in the UI. Page parts are for the page content (body) and the the other fields are for meta-data (kind of like HTML's vs. ). It could be done without (for Radiant or HTML) but is nice for organization and comprehension. But you are right -- it's all just data. In fact, Radiant could move the slug, breadcrumb -- any field really -- into a page part and it would still be workable. my $.02 (though probably overpriced). -Chris On May 19, 2008, at 4:02 PM, Jim Gay wrote: Given the debate about how to implement an "inherit" functionality for something that already exists with r:content, I'd say this is bloat. I think there is a benefit in the user interface though, to have a text field rather than a text area to manage a small amount of content so I could be persuaded to leave it in for that reason. But I think that another option there might be to simply create a new way to add page parts in text fields near the title area (I don't recall what shards calls it). Add a part as a big text area in the tabs or add it as a text field. They could be functionally the same, but depending on the scenario they encourage (or discourage) a user in entering a certain amount of text. I use page parts on the home page, for example, to allow users to alter things like the footer text on their site. Adding "Copyright 2008 Super Happy Funtime Inc." in a big text area isn't ideal (because of the size of the text vs the size of the area given) but it does the job. And it easily is inherited on every page. I recall seeing the request for r:meta on Trac a long time ago and just figured it wouldn't be added. I think, however, that something like a "truncate" attribute makes sense even for both cases... You can have users fill out a description part, or just use the first 50 characters (for example) of the body and use that in your meta tags. This would of course cause problems with HTML being entered so that would take a little more thinking. Having said all of that, I don't think its a major detriment that it exists, but I don't think it is necessary and probably shouldn't exist in the future. Should I feel out of place in this conversation since my last name isn't Cribbs? ;-) -Jim On May 19, 2008, at 3:34 PM, Sean Cribbs wrote: Jamey, That's great. In response to Jim, it was a common enough use case for people who do SEO for their sites and such a low overhead to implement, it seemed like a reasonable thing to add. I'd appreciate debates on this matter, however, as I'm open to culling
Re: [Radiant] New metatags for keywords, description feature
I'm resurrecting this thread so that I can express my personal hatred of the meta tags. I propose that they be removed, or handled in a different way (and yes I volunteer myself to write the code for it). I'll be doing some thinking about and how to better handle the many options for HTML, but if anyone is interested, I created this extension http://github.com/saturnflyer/radiant-seo_help-extension/tree/master which provides an "inherit" attribute on r:meta and adds r:if_meta and r:unless_meta -Jim On May 19, 2008, at 4:13 PM, Chris Parrish wrote: I can't speak for the core team but I wrote my own extension to do the same thing for clarity and simplicity in the UI. Page parts are for the page content (body) and the the other fields are for meta- data (kind of like HTML's vs. ). It could be done without (for Radiant or HTML) but is nice for organization and comprehension. But you are right -- it's all just data. In fact, Radiant could move the slug, breadcrumb -- any field really -- into a page part and it would still be workable. my $.02 (though probably overpriced). -Chris On May 19, 2008, at 4:02 PM, Jim Gay wrote: Given the debate about how to implement an "inherit" functionality for something that already exists with r:content, I'd say this is bloat. I think there is a benefit in the user interface though, to have a text field rather than a text area to manage a small amount of content so I could be persuaded to leave it in for that reason. But I think that another option there might be to simply create a new way to add page parts in text fields near the title area (I don't recall what shards calls it). Add a part as a big text area in the tabs or add it as a text field. They could be functionally the same, but depending on the scenario they encourage (or discourage) a user in entering a certain amount of text. I use page parts on the home page, for example, to allow users to alter things like the footer text on their site. Adding "Copyright 2008 Super Happy Funtime Inc." in a big text area isn't ideal (because of the size of the text vs the size of the area given) but it does the job. And it easily is inherited on every page. I recall seeing the request for r:meta on Trac a long time ago and just figured it wouldn't be added. I think, however, that something like a "truncate" attribute makes sense even for both cases... You can have users fill out a description part, or just use the first 50 characters (for example) of the body and use that in your meta tags. This would of course cause problems with HTML being entered so that would take a little more thinking. Having said all of that, I don't think its a major detriment that it exists, but I don't think it is necessary and probably shouldn't exist in the future. Should I feel out of place in this conversation since my last name isn't Cribbs? ;-) -Jim On May 19, 2008, at 3:34 PM, Sean Cribbs wrote: Jamey, That's great. In response to Jim, it was a common enough use case for people who do SEO for their sites and such a low overhead to implement, it seemed like a reasonable thing to add. I'd appreciate debates on this matter, however, as I'm open to culling superfluous code from the core. Sean Jamey Cribbs wrote: I just implemented what Jim suggested in my project and it works great. I created a meta_keywords and a meta_description page part in the pages that I want the tags. The nice thing is that you can use the inherit="true" parameter. On Mon, May 19, 2008 at 11:52 AM, Jim Gay <[EMAIL PROTECTED]> wrote: I'm curious about why r:meta was implemented. Couldn't you get the same result by using page parts and dropping them in the appropriate place in your layout? I haven't used r:meta yet, so perhaps I'm unaware of some particular benefit -Jim On May 19, 2008, at 11:47 AM, Sean Cribbs wrote: Personally, I'd like to see inheritance of meta info be optional and not the default. Sean Chris Parrish wrote: I just wanted to mention that I just noticed this change and am glad to see it implemented in core as well. It eliminates the need for my page_meta extension. I too, like the inheritance idea (an optional attribute of the tag) but I would also like to see a feature I had implemented in my extension. I the 'tag' attribute (mine was 'as_tag'), I had allowed true | false | unless_blank for the reverse case that Jamey is mentioning. I have sites where I *don't* want keywords to inherit. They need to be explicitly defined or else the page gets none. So, by using the 'unless_blank' option, I was able to prevent the page from kicking out an empty set of tags. I'd be happy to write up a patch for this if others think that this would be helpful. -Chris Jamey Cribbs wrote: First of all, thanks very much to the dev team for all of the latest release activity. It is greatly appreciated!
