Re: [Radiant] Radiant tag errors
On Sat, Oct 25, 2008 at 9:59 PM, Joe Van Dyk <[EMAIL PROTECTED]> wrote: > On Sat, Oct 18, 2008 at 6:41 PM, Jim Gay <[EMAIL PROTECTED]> wrote: >> >> On Oct 18, 2008, at 3:17 PM, Joe Van Dyk wrote: >> >>> On Fri, Oct 17, 2008 at 7:09 PM, Jim Gay <[EMAIL PROTECTED]> wrote: On Oct 17, 2008, at 10:04 PM, Joe Van Dyk wrote: > This is in production mode. I'm using the radiant exception notifier > plugin, which lets you put up your own 500 page. > > I'm using Radiant to build a website that lets some non-technical > people update it. I'm trying to make it as easy as possible. It > doesn't seem right, if one person makes an error on a snippet that's > being used by every page, to not show the rest of the page's content > (and replace the snippet or tag with the error message). That would > let them easily figure out where the error occurred and would give > them clues to how to fix it. > > Joe From my past experience and this recent test, that is what *should* be happening. What does the 500 error say? >>> >>> Whatever the content on the 500 error page is. >> >> Ok. What does your log file report? > > It shows the exception backtrace. > >>> You're saying that when you mess up a tag, the tag content is replaced >>> with the error message and the rest of the page looks as it would if >>> the tag rendered successfully? >> >> Yes, that is how it is supposed to behave in production mode. If it is not >> doing that, then something is wrong (but that part is obvious). >> I haven't used exception notifier for Radiant, but I don't expect that it >> would alter things to behave like this. Does it? >> Or have you made any changes to your environment file >> (environments/production.rb)? > > This is in staging, actually. I copied the environment file from the > production one. Ah, found what I was looking for in page_context. Perhaps that should be an option settable from the environment file? ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Radiant tag errors
On Sat, Oct 18, 2008 at 6:41 PM, Jim Gay <[EMAIL PROTECTED]> wrote: > > On Oct 18, 2008, at 3:17 PM, Joe Van Dyk wrote: > >> On Fri, Oct 17, 2008 at 7:09 PM, Jim Gay <[EMAIL PROTECTED]> wrote: >>> >>> On Oct 17, 2008, at 10:04 PM, Joe Van Dyk wrote: >>> This is in production mode. I'm using the radiant exception notifier plugin, which lets you put up your own 500 page. I'm using Radiant to build a website that lets some non-technical people update it. I'm trying to make it as easy as possible. It doesn't seem right, if one person makes an error on a snippet that's being used by every page, to not show the rest of the page's content (and replace the snippet or tag with the error message). That would let them easily figure out where the error occurred and would give them clues to how to fix it. Joe >>> >>> From my past experience and this recent test, that is what *should* be >>> happening. >>> What does the 500 error say? >> >> Whatever the content on the 500 error page is. > > Ok. What does your log file report? It shows the exception backtrace. >> You're saying that when you mess up a tag, the tag content is replaced >> with the error message and the rest of the page looks as it would if >> the tag rendered successfully? > > Yes, that is how it is supposed to behave in production mode. If it is not > doing that, then something is wrong (but that part is obvious). > I haven't used exception notifier for Radiant, but I don't expect that it > would alter things to behave like this. Does it? > Or have you made any changes to your environment file > (environments/production.rb)? This is in staging, actually. I copied the environment file from the production one. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] radiant-tags-extension with PostgreSQL?
Jay Levitt wrote: I added Edmund Haselwanter's bug fix to my copy of the "tags" extension (thanks for that fix!), and now I'm trying to display a tag_cloud. But I get this error instead of a cloud: PGError: ERROR: column "meta_tags.id" must appear in the GROUP BY clause or be used in an aggregate function : SELECT meta_tags.*, count(*) as popularity FROM meta_tags JOIN taggings ON taggings.meta_tag_id = meta_tags.id GROUP BY taggings.meta_tag_id ORDER BY popularity DESC LIMIT 5 aaand, the answer is: 1. My wild guess at SQL was right; the :group should be - :group => "taggings.meta_tag_id", + :group => "meta_tags.id, meta_tags.name", 2. The "1 page is tagged with tag1" was because I hadn't read the help docs, and so I hadn't included tags.css in my page. 3. But that CSS is buggy anyway (at least on Firefox 3 Mac); it seems a better way to hide the unstyled list is: - .tag_cloud span { position: absolute; left: -999px; width: 990px; } + .tag_cloud span { position: absolute; left: 0px; top: -500px; width: 1px; height: 1px; overflow: hidden; } 4. I have NO idea what I'm doing with git yet, but (thanks to Edmund's link to the tutorials), I think I just created a fork, which includes everyone else's changes to date, at: http://github.com/jaylevitt/radiant-tags-extension.git 5. I also think I sent a pull request to everyone else. Hope that's the right thing to do. 6. If all the power goes out somewhere, let me know. It could possibly be my fault, but I'm pretty sure I canceled that in time. Jay ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] [ANN] Vhost extension
Extension announcement: I updated an extension I wrote many months ago to work with Radiant 0.6.9. It does just what you think: host multiple separate websites on one Radiant instance. Similar to multi_site, but everything--pages, snippets, and layouts--is separate and you can specify which users have access to what sites. You have to go to the site's domain and log in to edit the site. It's great for hosting multiple clients on a small cluster. You can find it here: http://github.com/jgarber/radiant-vhost-extension/tree/master I intend to update it with regular expression matching like multi_site has, but for now it's just the host name or * for a catch-all site. Best of luck in the sprint! Jason -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] Conditions in r:children
Today is the Radiant sprint day. I made a proposal for an enhancement to the standard Radius tags: http://pastie.org/300372 I've implemented this now in my own fork of Radiant. Check it out here: http://github.com/nelstrom/radiant/tree/master I'd be interested to hear of any thoughts on this. Cheers, Drew ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] [ANN] Conditional Tags Extension
Sorry. I didn't want to come across so preachy. I agree with you. It bugs me too. If, however, I ask myself whether it would bother a non-techy -- someone who not only doesn't know xml but who's never even heard of it -- then I'd bet nearly all would prefer something like: to But the technical part of me still struggles with it anyway. -Chris Manuel Meurer wrote: Ok, you're right. For me, would not feel right, though. Manuel On Sat, Oct 25, 2008 at 8:35 PM, Chris Parrish <[EMAIL PROTECTED]> wrote: Manuel Meurer wrote: I think that there is a place for these tags and I'd love it if there was an easy way to use this to create both if_ and unless_ tags. Something like: conditional_tags "my_tag" do |tag| #return a boolean false end which would then create if_my_tag and unless_my_tag tags. For the if_ tag, the contents of the tag is executed when block returns true, and the reverse happens for the unless_ tag. This is interesting. I'll have to think about this. Essentially what you're going for here is the removal of the attributes (something I agree with). I bet my extension would be more comfortable if only you could write: This would not be valid XML. Attributes must have a value. http://www.w3.org/TR/xml/#attdecls Manuel ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant Radius isn't really xml -- it just eerily *looks* like xml. For example, Radius will allow all kinds of characters in the tag that XML doesn't permit. And that's fine. We aren't really marking up the document structurally we're just borrowing a familiar notation for a templating language. I see no reason we couldn't create, say, a php-radius tag extension that parsed: as a snippet tag. Or maybe ERB's <%%> I really wasn't proposing changing radius there (though I am intrigued by the above). Instead I was looking at how the pattern of xml can make radius tags less comprehensible. Round peg, square hole in some cases. Another example would be creating if, else if, else structures. I don't see how you could use an xml-like notation to pull that off. Lucky for us, if-then is plenty sufficient for 99.99% of all the needs for Radiant users. -Chris ___ 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] [ANN] Conditional Tags Extension
Ok, you're right. For me, would not feel right, though. Manuel On Sat, Oct 25, 2008 at 8:35 PM, Chris Parrish <[EMAIL PROTECTED]> wrote: > Manuel Meurer wrote: I think that there is a place for these tags and I'd love it if there was an easy way to use this to create both if_ and unless_ tags. Something like: conditional_tags "my_tag" do |tag| #return a boolean false end which would then create if_my_tag and unless_my_tag tags. For the if_ tag, the contents of the tag is executed when block returns true, and the reverse happens for the unless_ tag. >>> >>> This is interesting. I'll have to think about this. Essentially what >>> you're going for here is the removal of the attributes (something I agree >>> with). I bet my extension would be more comfortable if only you could >>> write: >>> >>> >>> >> >> This would not be valid XML. >> Attributes must have a value. >> http://www.w3.org/TR/xml/#attdecls >> >> Manuel >> ___ >> Radiant mailing list >> Post: Radiant@radiantcms.org >> Search: http://radiantcms.org/mailing-list/search/ >> Site: http://lists.radiantcms.org/mailman/listinfo/radiant >> > > Radius isn't really xml -- it just eerily *looks* like xml. For example, > Radius will allow all kinds of characters in the tag that XML doesn't > permit. > > And that's fine. We aren't really marking up the document structurally > we're just borrowing a familiar notation for a templating language. > > I see no reason we couldn't create, say, a php-radius tag extension that > parsed: as a snippet tag. Or maybe ERB's > <%%> > > > I really wasn't proposing changing radius there (though I am intrigued by > the above). Instead I was looking at how the pattern of xml can make radius > tags less comprehensible. Round peg, square hole in some cases. > > Another example would be creating if, else if, else structures. I don't see > how you could use an xml-like notation to pull that off. Lucky for us, > if-then is plenty sufficient for 99.99% of all the needs for Radiant users. > > -Chris > ___ > 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] [ANN] Conditional Tags Extension
Manuel Meurer wrote: I think that there is a place for these tags and I'd love it if there was an easy way to use this to create both if_ and unless_ tags. Something like: conditional_tags "my_tag" do |tag| #return a boolean false end which would then create if_my_tag and unless_my_tag tags. For the if_ tag, the contents of the tag is executed when block returns true, and the reverse happens for the unless_ tag. This is interesting. I'll have to think about this. Essentially what you're going for here is the removal of the attributes (something I agree with). I bet my extension would be more comfortable if only you could write: This would not be valid XML. Attributes must have a value. http://www.w3.org/TR/xml/#attdecls Manuel ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant Radius isn't really xml -- it just eerily *looks* like xml. For example, Radius will allow all kinds of characters in the tag that XML doesn't permit. And that's fine. We aren't really marking up the document structurally we're just borrowing a familiar notation for a templating language. I see no reason we couldn't create, say, a php-radius tag extension that parsed: as a snippet tag. Or maybe ERB's <%%> I really wasn't proposing changing radius there (though I am intrigued by the above). Instead I was looking at how the pattern of xml can make radius tags less comprehensible. Round peg, square hole in some cases. Another example would be creating if, else if, else structures. I don't see how you could use an xml-like notation to pull that off. Lucky for us, if-then is plenty sufficient for 99.99% of all the needs for Radiant users. -Chris ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] [ANN] Conditional Tags Extension
>> I think that there is a place for these tags and I'd love it if there was >> an easy way to use this to create both if_ and unless_ tags. Something like: >> >> conditional_tags "my_tag" do |tag| >> #return a boolean >> false >> end >> >> which would then create if_my_tag and unless_my_tag tags. For the if_ tag, >> the contents of the tag is executed when block returns true, and the reverse >> happens for the unless_ tag. > > This is interesting. I'll have to think about this. Essentially what > you're going for here is the removal of the attributes (something I agree > with). I bet my extension would be more comfortable if only you could > write: > > This would not be valid XML. Attributes must have a value. http://www.w3.org/TR/xml/#attdecls Manuel ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] if_dev dev.host functionality with multi_site extension
Let me know what you're looking for here. My new Conditional Tags extension already offers a "mode" element that lets you ask if "mode = 'dev'" but it should be quite easy to add a new evaluator (perhaps I could offer one for the multi_site extension). I'm not clear exactly what you want evaluated, however. -Chris Bill Barnard wrote: Thanks Michael, On Thu, Oct 23, 2008 at 03:26:50PM +0200, Michael Kessler wrote: Bill, If you don't specify a dev host in the settings, any domain starting with 'dev' will be seen as a dev host. This would be true if multi_site were not installed. I found that multi_site sets dev.host to "preview". In my environment.rb therefore I set: Radiant::Config["dev.host"] = "dev" Now I see the Draft mode pages on dev.base_domain and not on base_domain. However the tag will not expand on dev.base_domain. The logic for the if_dev tag (in app/models/standard_tags.rb) looks the same as that for the dev? method (in app/controllers/site_controller.rb). I assume dev? is used to determine whether a Draft page is rendered but I'm not sure. Thanks, Bill ___ 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] Abstract and Resource controllers
Hi folks, I recently updated the Creating Radiant Extensions tutorial[1], by removing the references to Scaffolding (dead since Rails 2). Instead of using scaffolding, I suggested making the LinksController inherit from the AbstractModelController: class Admin::LinksController < Admin::AbstractModelController model_class Link end I'm watching the Radiant sprint weekend from afar, and noticed that there is now an Admin::ResourceController[2]. Is this going to replace the AbstractModelController? I'm happy to update the tutorial to reflect this. Presumably the routes will be updated to follow the rails convention for RESTful routes. I'll wait until the work from the sprint weekend has been consolidated into a release before I update the tutorial. Cheers, Drew [1]: http://wiki.radiantcms.org/Creating_Radiant_Extensions [2]: http://github.com/radiant/radiant/tree/8a8b7d6812323738033e1f33b536195c24f6cab1/app/controllers/admin/resource_controller.rb ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Weekly wacky suggestion
Jay, I think its a good idea to make things unambiguous but taggs just feels wrong. Why not reuse "taglib" from J2EE? They're basically the same thing as our tags Sent from my iPhone On 25-Oct-08, at 5:56 AM, Jay Levitt <[EMAIL PROTECTED]> wrote: The term "tags" is, of necessity, overloaded in Radiant; we have Radius tags, and we have radiant-tagging-extension "tagging as in '2.0' and tagclouds" tags. That makes it difficult to search for questions, blog posts, etc. on either type of tag. But "tags" is the right word; it's what everyone else uses, and making up a new term would be both futile and confusing. Why not refer to the radiant-tagging-extension tags as "taggs"? The meaning is still clear, but it uniquifies the tagcloud meaning (modulo the occasional misspelling). Jay PS - Yeah, I'm procrastinating; what's it to you? PPS - I'm not sure if this suggestion would imply that the radiant- tagging-extension should be renamed to radiant-taggging extension... ___ 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] radiant-tags-extension with PostgreSQL?
I added Edmund Haselwanter's bug fix to my copy of the "tags" extension (thanks for that fix!), and now I'm trying to display a tag_cloud. But I get this error instead of a cloud: PGError: ERROR: column "meta_tags.id" must appear in the GROUP BY clause or be used in an aggregate function : SELECT meta_tags.*, count(*) as popularity FROM meta_tags JOIN taggings ON taggings.meta_tag_id = meta_tags.id GROUP BY taggings.meta_tag_id ORDER BY popularity DESC LIMIT 5 If I try changing the ":group" clause in meta_tags.rb as follows: - :group => "taggings.meta_tag_id", + :group => "meta_tags.id, meta_tags.name", then I get: "1 page is tagged with tag1 1 page is tagged with tag2" which is a little more verbose than I think a tag cloud oughta be :) I'm not good enough with SQL to know what the right query is; can anyone lend a hand? Jay Levitt ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] Weekly wacky suggestion
The term "tags" is, of necessity, overloaded in Radiant; we have Radius tags, and we have radiant-tagging-extension "tagging as in '2.0' and tagclouds" tags. That makes it difficult to search for questions, blog posts, etc. on either type of tag. But "tags" is the right word; it's what everyone else uses, and making up a new term would be both futile and confusing. Why not refer to the radiant-tagging-extension tags as "taggs"? The meaning is still clear, but it uniquifies the tagcloud meaning (modulo the occasional misspelling). Jay PS - Yeah, I'm procrastinating; what's it to you? PPS - I'm not sure if this suggestion would imply that the radiant-tagging-extension should be renamed to radiant-taggging extension... ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant