[Radiant] Request for Help...
Hello all. As many of you have read, I am getting ready to release an extension for managing stylesheets and javascript files apart from pages. I am finding that it would be helpful to know the average and maximum numbers of documents it may have to handle. So, I have some quick questions for those of you using Radiant for a production site: 1. How many css files are used by your site (not for the radiant admin, but the actual public site)? If you have more than one Radiant site the maximum number is what I need (though a ballpark average might be nice too). 2. Same question - but this time for your javascripts. 3. Bonus question: Same question - but this time how many Radiant layouts (ignore any that are just for css or js serving). Please email me directly -- I'm not sure that your answers would help others on the mailing list so let's not clog everybody's inbox :-) . Thank you all so much for your help, -Chris ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Best practices for managing CSS, JavaScript, images?
Sean, you're too fast... Well Timothy, you're in luck. At John's request, I have put together an extension to manage CSS JS files as assets separate from normal pages. I've got a little rearranging that he's asked for before I release it into the wild. Look for an announcement here soon - probably by this weekend. In the meantime, Sean's explanation saved me some time explaining it here and works well enough for how (though we've all felt it a little hack-ish -- hence the new solution). As to other assets, Sean has a very well used PageAttachments extension, Andrea Franz has a Gallery extension and Keith Bingman also has an Assets extension (though he'll be the first to tell you it's not production ready right now). Links and info on these third party extensions can be found here: http://wiki.radiantcms.org/Thirdparty_Extensions -Chris Timothy Jones wrote: Greetings, I'm just ramping up on Radiant. Apologies if I've missed this in a FAQ somewhere, but I'm looking for some recommendations on managing these types of assets on a Radiant-based site. I found a mailing list thread from 2006, but it didn't seem to have a conclusion. With non-Radiant sites I have Apache serve up these static files, bypassing Rails entirely. What are the recommended best practices with Radiant? I'd like to manage them through the web interface, so that other folks don't have to deal with Subversion, deployment, etc. Do folks generally just embed the CSS and JavaScript in a layout and serve it dynamically? And caching? What about images (icons, backgrounds, etc.)? I'd like a way to upload and delete them from a browser, again to avoid Subversion and deployment hassles. It looks like the Gallery extension might work for this. Any other recommendations? Thanks! Tim Jones Barbary Codes and Data ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] Adding Options to my Extension
What's the preferred way to add options to an extension. I want to let the developer configure things like path locations so that their choices are loaded at startup (and then used by my extension). -Chris ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] meta tags for 0.6.4
Jasper Kooij wrote: Thanks Chris, ok specific questions about the page_meta extension: I've got it down to install on site5 hosting, I've got the extension installed using svn after the rake production db:migrate:extensions I get: rake production db:migrate:extensions /usr/bin/rake:17:Warning: require_gem is obsolete. Use gem instead. (in /home/jasperko/wisconsindells) rake aborted! uninitialized constant ApplicationController what am i doing wrong? Hmm. Are you using any other extensions (your command migrates *all* extensions)? Other than that, In my local development environment, I have a working Radiant 0.6.4 with the page_meta extension. The only reference to require_gem that I can find is in config/boot.rb on line 28. Can any of your core guys offer any insight here? -Chris ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] meta tags for 0.6.4
Well, it's clear that the error is being triggered by my extension. And Sean Cribbs was nice enough to point out that I need: require_dependency 'application' in my extension initialization for the fancy stuff I'm adding to core components. So I've updated my extension and uploaded this new version to my repository here: https://secure.svnrepository.com/s_swanki/open/radiant/extensions/page_meta/tags/v0.1.6/ Try that and tell me if that works (feel free to just email me off-list if we need to do more digging). -Chris Jasper Kooij wrote: I only have the 0.6.4 install of radiant this extension page_meta: Here is the trace: -jailshell-3.00$ rake production db:migrate:extensions --trace /usr/bin/rake:17:Warning: require_gem is obsolete. Use gem instead. (in /home/jasperko/wisconsindells) ** Invoke production (first_time) ** Execute production ** Invoke environment (first_time) ** Execute environment rake aborted! uninitialized constant ApplicationController /home/jasperko/wisconsindells/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:266:in `load_missing_constant' /home/jasperko/wisconsindells/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:452:in `const_missing' /home/jasperko/wisconsindells/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:464:in `const_missing' /home/jasperko/wisconsindells/app/controllers/admin/abstract_model_controller.rb:1 /usr/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' /home/jasperko/wisconsindells/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:495:in `require' /home/jasperko/wisconsindells/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:342:in `new_constants_in' /home/jasperko/wisconsindells/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:495:in `require' /home/jasperko/wisconsindells/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:104:in `require_or_load' /home/jasperko/wisconsindells/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:248:in `load_missing_constant' /home/jasperko/wisconsindells/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:452:in `const_missing' /home/jasperko/wisconsindells/app/controllers/admin/page_controller.rb:1 /usr/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' /home/jasperko/wisconsindells/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:495:in `require' /home/jasperko/wisconsindells/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:342:in `new_constants_in' /home/jasperko/wisconsindells/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:495:in `require' /home/jasperko/wisconsindells/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:104:in `require_or_load' /home/jasperko/wisconsindells/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:248:in `load_missing_constant' /home/jasperko/wisconsindells/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:452:in `const_missing' /home/jasperko/wisconsindells/vendor/extensions/page_meta/page_meta_extension.rb:6:in `activate' /home/jasperko/wisconsindells/lib/radiant/extension.rb:39:in `activate' /home/jasperko/wisconsindells/lib/radiant/extension_loader.rb:118:in `activate' /home/jasperko/wisconsindells/lib/radiant/extension_loader.rb:106:in `activate_extensions' /home/jasperko/wisconsindells/lib/radiant/extension_loader.rb:97:in `activate_extensions' /home/jasperko/wisconsindells/lib/radiant/extension_loader.rb:42:in `run' /home/jasperko/wisconsindells/config/../lib/radiant/initializer.rb:45:in `initialize_extensions' /home/jasperko/wisconsindells/config/../lib/radiant/initializer.rb:38:in `after_initialize' /home/jasperko/wisconsindells/config/../vendor/rails/railties/lib/initializer.rb:118:in `process' /home/jasperko/wisconsindells/config/../vendor/rails/railties/lib/initializer.rb:47:in `run' /home/jasperko/wisconsindells/config/../lib/radiant/initializer.rb:34:in `run' /home/jasperko/wisconsindells/config/../config/environment.rb:12 /usr/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' /home/jasperko/wisconsindells/vendor/rails/railties/lib/tasks/misc.rake:3 /usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:362:in `invoke' /usr/lib/ruby/1.8/thread.rb:135:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:355:in `invoke'
Re: [Radiant] meta tags for 0.6.4
Hey there Jasper, I developed the Meta Tags extension and it works just fine under 0.6.4. As to the repository at http://dev.radiantcms.org/svn... That's a special set of extensions that is stored in the Radiant Subversion Repository (not sure what gets you in that list -- I'm guessing you need to be a member of the radiant core team of developers). The rest of us mere mortals ;-) host our stuff wherever we have server space. Anyway, if you look at the list on the Thirdparty Extensions page (http://wiki.radiantcms.org/Thirdparty_Extensions), you'll see that it's broken into three sections: 1. Extensions from the Radiant Subversion Repository (this includes the .../rel_0-6-4/extensions/ you found) 2. Extensions from the Ruby-Lang Subversion Repository (not sure if those are radiant extensions or whether some are actually rails plugins) 3. Other Extensions (that's the rest of us - and sorry, there's not a good system to identify which extensions are compatible with which versions of radiant I'm afraid) I hope that helps. Welcome to the party. -Chris Jasper Kooij wrote: Do meta tags work in 0.6.4? I'm new to radiant and i'm trying to figure out how radiant works. I've found http://dev.radiantcms.org/svn/radiant/tags/rel_0-6-4/extensions/ with the list of extensions. but that does not contain the meta tags extension that I found here: http://wiki.radiantcms.org/Thirdparty_Extensions I'm fairly new to RoR Jasper ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] meta tags for 0.6.4
Please don't take my answers as gospel - but I hope they help. Perhaps some others could offer some helpful insight here... See answers below: Jasper Kooij wrote: Thanks Chris, I will check it out. Also I will keep notes on my first development of a website. I've found lots of info on extensions. Layout building info seems sparse I'll contribute. I'm not new to CMS's, I've done a number of sites on drupal so i'm getting my bearings. I like the natural content organization of the cms. I've went through the install ok on my site with site5. In the end i've downloaded the entire install rather then the gem install. The admin kept reporting that I had version 0.6.1. I do have 3 questions, maybe you can help me get directly to the info 1. how can I construct a contact form, it that the mailer extension? Yes, the mailer extension is the one I've heard of most (though never used). Others may be able to chime in with additional solutions (and which ones work with the most recent version of Radiant). I've been talking with an individual on the core team about a more general forms solution for Radiant but that is still in *early* pre-alpha. 2. does any of the editors (tinymce, fckeditor or wym) work with images uploads? There are a couple of image upload solutions out there and there are several content editor extensions too. I'd go to the content editor extension developers directly about adding in images directly. Seems like someone mentioned the capability (though I'm not sure if the solution was publicly available). Anyone else here? 3. can a user role be added of a member to the site? Radiant isn't really geared that way - though you could extend it to do so. There was a recent discussion on this (try searching the mailing list for Role Based Access Control). I think the consensus was that membership and admin users are separate things (and the former are up to you to build). Jasper btw the wiki seems to be inaccessible alot. Any idea why? No idea - been seeing that too. -Chris ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Help with tables in Radiant?
Jim Gay wrote:
When in doubt, use wacky background colors.
Depending on your design, red, lime, yellow, and blue are quick
keywords that clearly alter the view without altering the layout (like
adding borders does). You could try floating the list items left (and
set the ul to overflow: hidden so that it expands to contain the
floated items)
I'd argue that this isn't really tabular data, or at least that you
don't intend to display it as such since each new row doesn't
represent a new group, but a continuation of the previous one.
Unordered list makes more sense to me.
Having said all that, I'm not sure how to achieve the table layout you
want with radius tags. Sorry to be of no help there.
On Jan 21, 2008, at 11:05 PM, Ryan Heneise wrote:
I agree with Jim. Though I'm not such a purist that says you can never
use a table for layout -- I just think a table is more trouble than it's
worth here and not a good structural match anyway.
As to using tables with Radiant, I don't understand your question.
Using tables is like using any other markup with Radiant. You can. Or
were you trying to automatically create this page from a db somehow with
your own custom tags?
Anyway, this is more of a CSS/Markup question than a Radiant one. I'll
offer my thoughts, but if you want to discuss more, email me off the list.
My suggestion...
So, I'd stay off of the tabular bit and keep your unordered lists. You
can probably find a way to use inline-block but FireFox still doesn't
support it (though it does offer: -moz-inline-block which is similar).
The quick solution is to return to the float: left (that is see you have
commented out). The problem is that you need to clear every 4th item so
that it fully wraps to the left and creates a new line (I might use
something like li class=newRow. Then change your CSS:
ul#staff li {
float: left;
width: 155px;
margin: 0 10px 18px 0;
vertical-align: top;
list-style: none none inside; -- added this (display: block
will accomplish this in many browsers too).
}
ul#staff li.newRow {
clear: left;
}
I realize that this isn't ideal since you're adding some style-info into
markup but, hey you were considering tables -- and that's pure style
embedded intermingled with markup -- so I figure this solution would be
acceptable.
Disclaimer: This might need some tweaking across browsers but probably
not much if any. Works just fine in FF (don't have time to test in all
browsers right now).
By the way, some of your email addresses are too long and extend over
into the next column.
Hope that helps,
-Chris
___
Radiant mailing list
Post: Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Radiant Bug
Andrew O'Brien wrote:
Ugh, now I can't replicate with edge... I must have been mistaken.
And ignore what I said about Rails 2.0... looking in svn, I see that
the Rails 2.0 upgrade is in a different branch.
In any event, the only other thing I'd suggest to you Chris, is to
check your environment.rb and make sure it has something like this
(should be near the bottom):
ActionView::Base.field_error_proc = Proc.new do |html, instance|
%{div class=error-with-field#{html} small class=errorbull;
#{[instance.error_message].flatten.first}/small/div}
end
-Andrew
Thanks for your hard work Andrew. I'll take a look later this evening.
But it's not me I'm concerned about -- after all the RadiantCMS demo
site shows the same behavior. I'm concerned that this could be a
widespread bug -- one that we wouldn't hear about from our users because
they'd just think this is frustrating - but that's just the way it has
to be. Something that goes against the design ethic of Radiant, I think.
-Chris
___
Radiant mailing list
Post: Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Radiant Bug
Andrew O'Brien wrote:
Ugh, now I can't replicate with edge... I must have been mistaken.
And ignore what I said about Rails 2.0... looking in svn, I see that
the Rails 2.0 upgrade is in a different branch.
In any event, the only other thing I'd suggest to you Chris, is to
check your environment.rb and make sure it has something like this
(should be near the bottom):
ActionView::Base.field_error_proc = Proc.new do |html, instance|
%{div class=error-with-field#{html} small class=errorbull;
#{[instance.error_message].flatten.first}/small/div}
end
-Andrew
Well, you may have hit on it Andrew. If I look at my project with
radiant installed in the /vendor directory, I see the code you mention in:
/vendor/radiant/config/environment.rb
but not at:
/config/environment.rb
And adding the code to the /config/environment.rb seems to fix it. So
can anyone explain why these versions are different (and if it's
actually a Radiant issue)? (Actually there are more differences in
these files than just this one but most of the others seem explainable).
And I might consider trying to write a patch but I don't even know what
I'm trying to patch -- a rake task maybe? Nor am I sure what kind of
testing that would require. Can anyone on core offer some insight here?
-Chris
___
Radiant mailing list
Post: Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] Radiant Bug
I want to bring a bug to the attention of the newsgroup that I haven't been able to track down. John has asked that I post this here in hopes that one of you might be able to identify this issue and submit a patch. In some cases Radiant is failing to provide validation error messages to users. Instead of providing specific messages tied to the offending fields, they only get the one error message across the top of the screen. When that's their only message it comes across like Oops, you goofed. Now let's see if you're smart enough to figure out where. Mwaa haa haa haaa! (well, ok different users read things differently). Now, this doesn't happen in every installation. I notice a relationship depending on whether I'm running radiant via gem or with radiant installed in my project's /vendor directory (running from gem works fine, installed in /vendor doesn't). Please note: this is an observation and a starting point but I haven't proven anything so far. By the way, the Radiant Demo (http://demo.radiantcms.org) is missing these error messages. My ticket is here: http://dev.radiantcms.org/radiant/ticket/601 -Chris ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Standard Rake Install/Uninstall Tasks for Extensions
Sean Cribbs wrote: I've kind of kept out of this discussion so far, but there does exist an 'update' task that is generated for new extensions since 0.6.3 (I believe). It copies files from the extension's public folder to the project/instance public folder. However, there is no reverse operation for it currently. I imagine the tasks might look something like this (cleanup would be the reverse of update): task :install = [:migrate, :update] task :uninstall = :cleanup do ENV['VERSION'] = 0 migrate end I've used the built-in rake 'update' task and was wondering how it was different from the 'install' being proposed here. You're right Sean, they're really asking for both: rake production radiant:extensions:my_extension_name:update and, rake production radiant:extensions:lmy_extension_name:migrate However, what is also being asked here but can get sticky is an 'un-update' task which, at this point, doesn't exist. IMHO, it should do the following: * Take an inventory of all the files in the extension's public folders that would be copied by the 'update' task. * Look for those files in the application's public folders and: o If they exist and are an exact (binary) match, delete them o If they are exist but are different (same name, different file), leave them alone o If they don't exist, do nothing. * Spit out a report showing which files were deleted, which weren't and why, and which were expected but missing. That way people could update a css file or change a jpeg that came with their extension and not have to worry that uninstalling would erase their work. But I'm not sure what ruby offers to aid in performing a diff-check against two files, though. Ideas anyone? -Chris ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Hiding Extensions
Sean Cribbs wrote: Almost forgot... plain users don't have access to Extensions, IIRC. Don't give them the admin or developer role and you should be fine I'm thinking more from the perspective of hosting a website for a client where I've developed some core extensions (core to their site's needs). In this case, they would have admin rights (it's their site) but turning off these core extensions makes about as much sense as offering them a checkbox to disable Radiant. I could tell them just never turn this off if you have admin privileges but I'd rather keep the ui clean and un-confusing. So, there are some extensions that they should be able to enable/disable (like, say, textile) but others (like shards) that I wouldn't even want them to see or have control over disabling. Currently, the vendor/extensions/my_extension/my_extension.rb file allows me to declare the extension's description, version, and url. It would be nice to be able to add a declaration to tell Radiant don't include this extension in the extensions list at all -- sort of a developer's-level extension enabling, if you will. I was hoping something like this exists already. If not, I'd be happy to submit a ticket. -Chris ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] [ANN] PageMeta Extension
Made some updates over the weekend. It doesn't need Shards now (actually didn't really before) so this should work for older versions of Radiant too (as long as the PageController and page/edit.rhtml work with the @meta array which I think goes back pretty far). Here's the latest svn version: https://secure.svnrepository.com/s_swanki/open/radiant/extensions/page_meta/tags/v0.1.5/ -Chris ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] Hiding Extensions
I'm working on some extensions that I'd like to keep the user from turning off. Is there some way to keep users from disabling (or, better yet, even seeing) extensions in the admin ui? It seems like Shards would be a candidate for this too (I'm not sure I want a user to be able to turn Shards off while leaving my dependent extensions live). -Chris ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] [ANN] PageMeta Extension
Here's a new extension to store the keyword and description meta-tag values for pages (they show up in the expandable, meta-extended section of the edit-page form). I think that there used to be something like this once upon a time but I haven't seen it in a while and needed one. And of course this one works with the latest versions of Radiant and Sean's Shards Extension. And of course you need a way to render these things in your page/snippet/layout so this extension creates a r:meta / tag to render the values for the current page. So if meta_keywords = keyword1, keyword2, keyword3 in your page then... r:meta name=keywords / produces... keyword1, keyword2, keyword3 r:meta name=keywords as_tag=true / produces... meta name=keywords content=keyword1, keyword2, keyword3 / There's also an r:meta as_tag=unless_blank / option to avoid rendering the whole tag if the field's contents are blank. Check it out here: https://secure.svnrepository.com/s_swanki/open/radiant/extensions/page_meta/tags/v0.1.0 Let me know if you have any questions... -Chris Parrish ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Rails Upgrade
John W. Long wrote: Trunk may be a little unstable today. I'm working on upgrading everything to run on Rails 2.0. -- John Long http://wiseheartdesign.com ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant Woo hoo! ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] Rendering Partials within a Radius Tag
In an extension I'm working on, I'd like to define some medium to large blocks of dynamic html to be inserted via a single radius tag. Because this html isn't just a line or two and is tied to models and their data, I'd love to be able to create a true rails partial and tell the snippet to behave as a pseudo-controller and render the view in place of the radius tag. I'm trying to keep a separation of concerns here and keep my code clean (and make use of all the html/erb sugar already built into rails). I don't suppose that there's any way to have a tag call 'render :partial = ...' much less get around the rails double-render when the SiteController tries to render. Clever thoughts anyone? -Chris ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] RESTful Radiant
With Rails 2.0 coming soon, are there any near-term plans for Radiant's admin tools to move towards a more RESTful design? I've been working on an extension that inherits quite a bit from Radiant's AbstractController and have found several places where the going would be easier were it REST-oriented (it would probably simplify things like PageController too). I guess I'm saying that it would be nice to bite the bullet sooner rather than later -- before too many extensions get built that would have to be reworked. -Chris ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] Migrating Extensions
What is the radiant method for reverse migrations? I would have guessed: rake db:migrate:extensions:my_extension_name VERSION=XXX but of course this does not work. This also brings up a second issue: Is it even possible to migrate one extension without doing them all? Again, I would have guessed something like the following would be possible: rake db:migrate:extensions:my_extension_name -Chris ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] [ANN] Validation Extension
Just got my Validator Extension polished enough to release: http://swankinnovations.svnrepository.com/svn/open/radiant/extensions/validator/tags/v0.1.0/ What It Does: It adds a button to your edit-page pages to allow the user to validate their markup via the W3C's (X)HTML Validator. A report of the results is shown in a separate window. Also, if your db supports transaction roll-backs, it'll even validate the current markup in the page (without having to save first). If your db doesn't - I'm pretty sure it'll validate something... but I have *no* idea what. What It Doesn't Do: It's only HTML for now (though I'll add CSS validation in short order) and it isn't smart enough to prevent you from, say, submitting your javascript page for HTML validation. Other Future Plans: Since I have to render the current page to validate it, I'll probably add a page preview button in there too to take over the role of Sean's preview extension (if that's cool with you Sean). I also plan to add link checking in a near release. For more info and plans, see the README file. This is an early release but functional. I'd love any feedback (especially if it's in denominations of $50 or $100 ;-) ). -Chris Parrish ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] shards and admin_tree_structure
Daniel Sheppard wrote: We really need to get some browser-based testing (selenium maybe?), as javascript bugs seem to be a fair proportion of the problems these days. I second. I've been looking at the selenium_on_rails plugin to add testing for an extension that I'm working on. I'd love to see not only radiant using selenium but to have it integrate with extensions (after all, they're the source of much of the breakage). Writing good tests might get sticky in certain cases where extension A overrides extension B or Radiant, though. -Chris ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Virtual Pages via Extension
Andrew O'Brien wrote: Agh! Should have proofread... Personally, I like the bit where you say... I can be a little confusing at first, but... ;-) Thanks for the quick replies, guys. -Chris ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Sitemap doesn't validate
Andrew Neil wrote: Currently, there is no tag equivalent to r:has_child, as far as I know. There are tags r:parent / and r:unless_parent /. If such a tag was to be created, it would probably be useful to create its opposite as well, e.g r:has_no_child or r:childless. (Any thoughts as to how the pair of tags should be named?) A while back I mocked up an extension that abstracted conditionals. I like having a test for children as Andrew suggests but does anyone else think it would be useful to have a general r:if radius tag so that things like this could be added without cluttering up the number and variety of default if_tags out there? So instead of: r:if_parent r:if_content r:if_children r:if_next_great_idea you'd have something like: r:if cond=parent or, maybe r:if cond=page.parent exists? r:if cond=parts r:if cond=children It's not my suggested syntax that I'm so concerned about here as the concept of keeping all the r:if_stuff code DRY and reducing the number and complexity of all the different tags for the user. I'm guessing that this won't be the last conditional radiant adds. Oh, and to answer your question Andrew. I think that existence-test tags in radius are usually named like: r:if_children and r:unless_children or, r:if_child and r:unless_child Of course you could also go with the King James Translation: r:if_withchild and r:if_barren :) -Chris ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Checking for other extensions and gems
Aitor Garay-Romero wrote: And be sure that your extension loads after shards What is the mechanism for forcing extension load order? -Chris ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] Checking for other extensions and gems
I'm writing an extension that depends on shards. I'd like to check for it and raise a useful error message when my extension is initialized. Any suggestions as to the best way to do that? -Chris ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Radiant Best Practice
Sorry for such a late response here. Just reading through posts I'd missed while away and came across this. Aitor Garay-Romero-3 wrote: I see the problem. It would be nice to allow parametrization of snippets, but right now that it's not possible. This behavior can be implemented with a custom extension though. /AITOR This need is one of the main reasons that drove me to create my Vars/Conditionals Extension. In my case I had a series of wrapper divs that made up rounded boxes on my site. There were several variations, and some had different content inside and/or unique classes that needed to be applied. It seemed wrong to have 30 different snippets that were all variations on the same theme. My goal was to make snippets more like rails helpers or partials -- which meant that you needed to be able to pass (and then process) arguments. I even wrote a special modification to the r:snippet tag for this very reason (though it's not technically necessary) In the body you'd add: r:snippet name=box vars=content:text to fill / r:snippet name=box vars=content:second text to fill / Then in the snippet, you'd add: div class=foo r:puts value_for=vars[content] / /div If you want to get fancy, you can also pass multiple, optional parameters, like: r:snippet name=box vars=content: 'text to fill'; id: myId / and: div class=foor:if cond=vars[id] id=r:puts value_for=vars[id] //r:if r:puts value_for=vars[content] / /div In this case your snippet adds the id tag to your div IF you include a value for it. Feel free to download the extension and try it out: http://swankinnovations.svnrepository.com/svn/open/radiant/extensions/vars_if/trunk/ Hope this helps! -Chris On 9/18/07, Andrea Otto [EMAIL PROTECTED] wrote: Hi, I'd like to know how can I use radiant at the best... For example: I have a Homepage with a lot of boxes with same graphic. How can I deploy this? My first thought was creating something like this in the body: r:snippet name=boxtext to fill/r:snippet r:snippet name=boxsecond text to fill/r:snippet and create a snippet like this: div class=foo r:content /div I know that it can't be done... but it is my first use logic... So... How can I do it? My only working solution is to create a lot of childs page, all with a mytext part, put r:snippet name=box in each body, create a snippet like this: div class=foo r:content part=mytext /div and include all of my childs_box in the homepage with r:child:each Is it the right solution? Or there's a more pratic and fast modus operandi, like the first I exposed? -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant -- View this message in context: http://www.nabble.com/Radiant-Best-Practice-tf4472903.html#a13265682 Sent from the Radiant - User mailing list archive at Nabble.com. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Radiant Best Practice
Aitor Garay-Romero-3 wrote: I like the idea of parametrized snippets. I hope that the core team considers this for future releases, i believe that the idea is simple and fits in the philosophy of Radiant. I agree. My original goal was to create something that would fit within the core values - simplify a common task in a easily used way. This one gets to be a challenge because it reaches a little deeper into programming than some other tags. Aitor Garay-Romero-3 wrote: I would suggest to add the parameters individually to the r:snippet tag, and to allow a body to be defined: r:snippet name=rounded-box class=whatever bg-color=blue This is a parametrized snippet... /r The direction I went was with declaring variables rather than purely passing parameters. I then enhanced r:snippet to let you declare variables at the same time (I have a standard to also just r:store vars=myVar1: Chris; myVar2: 47; myVar3: false). The idea here was that you could access those values in a snippet but also elsewhere in the same page, or within other contexts. You could even set a variable within a snippet and then use it back within the calling page. That's why I named it 'vars' instead of 'params'. Overall, I like the simplicity of your modified r:snippet. But I also feel like it is too limited. I also have an application that needs variables outside the scope of snippets. I wonder if any of the core guys have an opinion here? John? Anyone? Aitor Garay-Romero-3 wrote: The name attribute is reserved. The user is free to use any other, and they will be passed to the snippet code, may be with a r:param and r:body tag: div class=r:param name=class rounded style=background-color:r:param name=bg-color r:body /div I prefer my format with a single attribute for all the variables/parameters for no particularly exceptional reason. I'll have to think more on your idea -- it's got merit. (Though it's nice to not deal with any reserved attribute names). I *really* like the idea of adding content to the snippet tag that is consumed by the snippet (you used the r:body tag). One thing that you didn't address here is that once you start dealing with variable/parameters, conditionals quickly become necessary. Often you want to respond one way or another within the snippet depending on the value (or lack of value) stored in a variable/parameter. So I ended up creating generalized r:if and r:unless tags -- to give the user a protected way to respond to these variables/parameters (but also to respond to items like page.title or page.part[partName]). Do you have any suggestions here? Aitor Garay-Romero-3 wrote: Backdoor 0.3.0 has a r:tag and r:erb_tag that can be used as parametrized snippets, but it has the known security implications. It's the security stuff that prevents me from touching backdoor. And it's not just that I have users that I don't trust with the full power of ruby -- I don't trust me. A bit like giving a kid a rocket launcher for Christmas - sure it keeps the bullies away but you're asking for trouble ;-). -Chris -- View this message in context: http://www.nabble.com/Radiant-Best-Practice-tf4472903.html#a13282850 Sent from the Radiant - User mailing list archive at Nabble.com. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Detecting Page Changes
Aitor Garay-Romero wrote: I'm trying to figure out a way to track whenever a given page's rendered output may have changed. Just curious, what functionality do you want to achieve with this? I am building a validator extension - I'll announce v0.1 here shortly. Initially, it will retain no memory of the tests - you just run it on a page to validate the markup and get handed the result. In future versions, however, I'd like to store the results of the validation (passed, failed, unknown, etc). That way I could present a report/view to the users showing which pages been validated (and their results) and which haven't. As you've probably guessed, if I want to store whether the page is valid, I need to know if a page has changed so that I can change its status as 'unknown'. -Chris ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] Detecting Page Changes
I'm trying to figure out a way to track whenever a given page's rendered output may have changed. Kind of tricky since changing the layout or, worse yet, a snippet could change the page's output. And then, of course, there are those silly extensions people keep making :-D with all their dynamic tags. Does anyone have any clever suggestions to deduce that the page's output may be changed? I'd love to have an event (or set of events) to trigger the check but would settle for a smart polling solution (but it should scale well). BTW, I'd love to be able to know that the page had changed but, for my purposes, even being able to suspect it's guilt would be sufficient. -- View this message in context: http://www.nabble.com/Detecting-Page-Changes-tf4603945.html#a13145924 Sent from the Radiant - User mailing list archive at Nabble.com. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] [ANN] Variables Conditionals Extension
Here's a proof-of-concept extension that I've been working on. I originally hoped to have polished this all up but haven't had the time for development. So, rather than stick it on a shelf, I thought I'd toss it out there in case it could benefit anyone. Besides, I want to find out what others in the Radiant community think =^D. http://swankinnovations.svnrepository.com/svn/open/radiant/extensions/vars_if/ SVN Repository Location Quickie Overview: This extension is essentially two extensions rolled into one. I just put them together for now for simplicity. It consists of: 1.) Abstracted Conditionals - instead of r:if_myWhatever I've created generic r:if and r:unless tags that let you build your own conditional statements. Existing Radiant tags can be rewritten as such: r:if_content part=my page part becomes... r:if cond=page.part[my page Part] and r:if_url matches=regexp becomes... r:if cond=page[url] matches regexp But more importantly, a wider range of conditionals becomes possible such as: r:if cond=page.part[my page Part] blank? , or r:if cond=page.part[my page Part] matches /myKeyword/, or r:unless cond=children[count] 10 And, more important still, the goal is to allow extension developers to easily hook into this so that their own custom values can be used in conditionals. So, instead of creating new r:if_newTagName tags, they could enable: r:if cond=myExtension[value] empty? or r:if cond=myCustomQuery[results] != myCustom[value] All they'd have to do is provide a method in their extension to resolve myExtension[value] for the conditionals to use. 2.) Abstracted 'Puts' Tag - because the conditionals must resolve symbols such as page[url] or MyExtension[value], I've also created a: r:puts value=page[url] / (which is functionally the same as r:url /, or r:puts value=page[title] / (which is functionally the same as r:title/ and, of course, the extension developer can now instantly offer: r:puts value=myExtension[value] / 3.) Variable Declaration - This one could be its own extenson. It provides a method to declare (store) variables in a local or global context (depending on whether its a single or double tag). These variables can then be displayed elsewhere (via r:puts) or evaluated (via r:if or r:unless). Examples: Put it all together and the following becomes possible: -- in page body -- r:store vars=class:myClass; quote:'my important string of text for quotation'; author:'Chris Parrish' / r:snippet name=quote / -- in snippet: quote -- div class=quoteSet blockquoter:if cond=vars[class] class=r:puts value=vars[class] //r:if r:puts value=vars[text] / /blockquote p class=authorr:puts value=vars[author] //p /div -- output -- div class=quoteSet blockquote class=myClass my important string of text for quotation /blockquote p class=authorChris Parrish/p /div To learn more, check out the README file and the tag descriptions (in code or via Radiant). Plus I've tried to put extra comments in the code. What I'm hoping for: 1.) Feedback - does anybody else think that this would be useful or am I just out in left field. 2.) Suggestions - I have some blatant unresolved issues here that someone might see a good way to address (see the README for more). Ideas anyone? 3.) Improvements - at the moment the repository is read only but I'll gladly accept patches, or even grant access for those that truly want to contribute. -- View this message in context: http://www.nabble.com/-ANN--Variables---Conditionals-Extension-tf4580441.html#a13075290 Sent from the Radiant - User mailing list archive at Nabble.com. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] [ANN] Variables Conditionals Extension
Mark D. Anderson wrote: doesn't r:if conflict with back_door ? -mda That would definitely depend on whether I knew what back_door was :-P . Sorry for my ignorance -- could someone give me some guidance here please? ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] [ANN] Variables Conditionals Extension
Chris Parrish wrote: Sorry for my ignorance -- could someone give me some guidance here please? Nevermind, I found it -- great minds, I guess. Wow, quit monitoring the group for a few months and look what happens... Anyway, my objectives are a bit different than back_door in that: 1.) There is NO WAY I want users to have full access to ruby. I wanted something as benign as r:if_parent but more flexible. I wouldn't build a site for a business and then hand the secretary or office staff that kind of a weapon. I'm not even sure I'd trust myself if the site was important -- after all, there's no way to test whether your code breaks your live site without breaking your live site (no real testing environment). 2.) I want something that designers and other non-coders could use. I don't want them to have to learn ruby. My thoughts here are probably closer to John's (can I say that?) when it comes to throwing in the kitchen sink -- just enough and no more... done elegantly (by the way that phrase is now trademarked, John) 3.) I wanted to give the extension developer a way to easily expose values from their creations and use them in conditionals -- yet also control what can be freely accessed and what is protected. Again, flexibility with security. 4.) I wanted something that was on a separate layer from the underlying ruby code. That way if Radiant 4.2.5 changes the way page titles are accessed, I only need to update my extension code -- not all my static pages that now have Radiant-specific back_door code. 5.) On a different note, the 'vars' stuff I created is different (though I'm sure that you could build that using back_door and Ruby code). Please don't misunderstand me -- I LIKE having back_door available but the needs driving this are very different (hey, that's why we have extensions). So, yes, it does conflict with the r:if and r:unless tags that Aitor created (I frankly love that he also used cond= -- ha!) I suspect that most developers would opt for one OR the other, though, based on their security needs. -- View this message in context: http://www.nabble.com/-ANN--Variables---Conditionals-Extension-tf4580441.html#a13078770 Sent from the Radiant - User mailing list archive at Nabble.com. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Missing Page = Application Error?
Sean Cribbs wrote: Yes, a ticket for that would be great. Sean Done: http://dev.radiantcms.org/radiant/ticket/515 By the way, sort of related... Entering other invalid urls below /admin/ (like: http://demo.radiantcms.org/admin/pages/garbage) don't require any kind of login and instead return the site's 404 page. Should the admin_controller have a method_missing to handle this kind of stuff (perhaps requiring login and/or providing a radiant admin 404 page)? -Chris -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Seperate Stylesheets for IE6 and Mozilla/Firefox
Ben, I think that I understand your problem (I have a similar situation). The solution depends on your exact needs: If EVERY page needs this, then the magic that makes your styles work goes in your main, site layout -- right in the head section as you mentioned. Then, if every page uses this layout, every page gets your magic. If you only need this for a few select pages, then you either create a custom layout for those pages and apply that layout to the needed pages or, use a method similar to the one I mention in this post: http://www.ruby-forum.com/topic/109023 As an aside, since I found that I needed a few extra css definitions ONLY for IE 5 6, I used IE proprietary conditional statements (like: !--[if lt IE 7]style type=text/css media=screen@import /css/default-old-ie.css;/style![endif]-- )instead of javascript browser detection. I'm not a huge fan of IE conditionals normally, but because it was IE only, this was a very clean way to accomplish my goals. Had I also needed a stylesheet to handle Safari bugs (or Opera, etc), I'd have gone the way of js. Just a suggestion. -Chris -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] Missing Page = Application Error?
I just refreshed an page edit screen for a page I'd just deleted and I got an application error. Even the RadiantCMS Demo site shows this behavior -- try: http://demo.radiantcms.org/admin/pages/edit/777 I'd be happy to create a ticket for this but I didn't know if it was intentional for some reason. -Chris -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Relative Linking in Radiant
John W. Long wrote: a href=./f/F/a or a href=./g/G/a Granted the extra dot is more explicit, but it seems more semantic, especially when you compare it to how you link to siblings: a href=../b/B/a or a href=../c/C/a But perhaps I'm strange. -- John Long http://wiseheartdesign.com Perhaps. But you make up for it in not being opinionated like I am. ;) -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Relative Linking in Radiant
Back on track... I see three possible methods: 1.) Current behavior with trailing slashes (slash no-slash are the same) 2.) Force a trailing slash (redirect the user's browser to address ending in a slash) except for certain file types (CSS, JS, etc). 3.) Strip all trailing slashes (redirect to the address not ending in a slash) Which are acceptable for Radiant to support/permit? If more than one way is permitted, we need some sort of configuration. How would you like that done/named? -Chris P.S. your ./ thing is wild. If I ever learned that one, I've long forgotten it. I don't think I've ever seen it used. -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Relative Linking in Radiant
Keith Bingman wrote: I am not really sure what your problem is here. Parents act like folders as far as the browser is concerned, so nothing has really changed. Ithink your only problem is the leading slash, which will tell the browser to look at the root. So in your example, instead of writing a href=b, you need to write a href=/b. Starting with a leading slash makes the URL absolute rather than relative (not relative to the current page, anyway). I am beginning to think that this is the only real solution. If you have a hierarchy where the pages can get quite deep, this can be a bit of a challenge to remember and type every time, though. -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] SEO in Radiant
dave4c03 wrote: - Common sense would suggest that search engines identify context from that which people see and use which is navigational menus andlinks to the page (and not by deconstructing the URL). You might think that, but it does seem documented that engines deconstruct the URLs and use this info. I think it's fair to say that the linking structure of the site IS more important to them, though. - You do not want to contaminate the URL in any way and that means you do not want keywords that are not supported by the page content in your URL. In particular, you do not automatically want any navigational context keywords or directory structure keywords in your URL. That really depends on your organization, doesn't it. A well planned website will usually organize parent/children by their topic creating themes. And you DO want this to show up in your URLs. In fact most testing suggests that this strengthens your site from an SEO perspective. Granted, if you arbitrarily create a structure like example.com/bodies-of-water/tulips/neil-armstrong, the URL probably won't help you. - Furthermore, as the web site content grows and changes, as they areprone to do, you want to be able to move the page and change the menu/navigational structures without breaking internal or external links to a URL resource. Sure, but this is wholly separate from everything else. If you move a page, you must either: change all links to it, have some automatic mechanism for changing all links to it, or else have Radiant do a redirect from the old page to the new one for you. Picking a Radiant tree location and a different URL doesn't solve this problem. There has been discussion about this. - The Menu1/SubMenu2/keyword1-keyword2-keyword3 and the Menu3/SubMenu4/keyword1-keyword2-keyword3 menu/navi- gational structures should both refer to the same page (http://example.com/keyword1-keyword2-keyword3). After all, a page should be able to participate in multiple navigational contexts. You can do this today. Make a page with your content at the desired URL. Make another page at another desired URL and include the following in the body: r:find url=your/first/url r:content / /r:find Or, if you want to be TOTALLY abstract, create your pages in any organizational structure you want (say /repository/your/favorite/structure/here) with NO links to that content (maybe even using 'hidden' page type). Then create all the URLs the way you like them and link to your content in the repository. This solution affords you the benefit of a tree view that shows you the different URL structures that you are using while allowing you to store your content in some other structure. Personally, I'd work on organizing my site based on SEO themes and gain the benefits of simplicity and not having to worry about Google changing their algorithms to penalize people with 10 different pages that all have the same content (because this matches spammer behavior). -Chris -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] SEO in Radiant
jf wrote: Once again, it's not a big deal -- just a minor disadvantage. It seems like the engines LIKE to see your themes, linking structure, and urls all reinforce each other. So, a site that is structurally organized (this means subfolders) the same way as its linking and themes are, is an advantage. Of course if you only have a single SEO theme to your site then you would rightly put all the content in the root (in this case, you wouldn't have too much content either so it works out nicely). -Chris -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Relative Linking in Radiant
Sean Cribbs wrote: When I worked on kckcc.edu, we had a pretty deep structure in some places. If I wanted quasi-relative URLs I took to using r:url/ or r:parent:url/ where necessary to cut down the typing errors. Sean So all your URLs wound up as absolute (href=/path/to/the/new/page) but you only had to input them in a relative-ish fashion (href=r:url/new/page). Interesting. It's beginning to look like true relative links are unworkable (or untrustworthy). -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Relative Linking in Radiant
Sean Cribbs wrote: They're not unworkable, you just have to be very careful about how you use them. I'm in a page with the links slug, I would do href=links/rails to get the rails child page. Actually, the example above, it only works if your browser is pointed to: 'example.com/links' (i.e. the browser 'thinks' its opening the links file in the root directory). If, instead, your browser is pointed to: 'example.com/links/' (i.e. the browser 'thinks' its opening the default file in the links directory), the link sends the browser looking for 'example.com/links/links/rails' My point about 'unworkable' is that, there is no way to guarantee that user's browser is always at the address with (or without) trailing slash. And so, if your href's don't give the full address from the root, your links may not work. The problem is that Radiant gives feedback that the user's at the right page even when, in fact, they may have the slash wrong for the relative links to work. As for the ability to limit this issue by forcing a trailing slash on every page (or preventing it everywhere), I never considered using the server. I like that. I also agree with Oliver that it fits well in Radiant (I would certainly configure it within Radiant if given that option). But it's also not something you'd change regularly, so I could make do with Apache. -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Relative Linking in Radiant
Oliver Baltzer wrote: On 12/06/07 07:10 PM, John W. Long was heard to say: * URLs without file extensions automatically get redirected to URLs with trailing slashes * URLs with extensions (like .css or .xml) are left alone * There is a configuration variable that turns this behavior on or off Hi John, thanks for your input. I do not think that the file extension is in the general case a good indication for whether a URL should have a trailing slash or not [1]. The canonical URL of a resource should be determined by its corresponding model. ATM, everything in Radiant is a page whether it is HTML or CSS. I would suggest the site controller uses Page#url to determine the canonical URL of a page and redirects accordingly. Page#url or any derived form of it is then responsible of deciding if a trailing slash should be added. If we then want to have CSS and XML without trailing slashes, we can just add a new derived page model that computes the canonical URL differently. [1] http://www.w3.org/Provider/Style/URI Cheers, Oliver The interesting thing with Radiant is that it eliminates possible the namespace confusion of something like: root |- A (folder) | |- index (file) |- A (file) which made distinguishing between example.com/a and example.com/a/ necessary for browsers in the first place. So, you can safely choose to add slashes or not for EVERY file and know that it'll all work out. That said, I'd prefer to represent each page as a file to the browser (i.e. example.com/a) unless someone has a compelling reason it should be treated like a folder. In addition, this method cleans up the whole extension parsing (who cares if it's a CSS file -- nothing gets a slash). @John, So, how about a Radiant configuration setting to either strip all trailing slashes or don't mess with my slashes dude (current behavior)? I guess a third option could be 'force trailing slashes' (but someone else can contribute that one :P ). -Chris -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] SEO in Radiant
Actually, I've got an extension that allows me to add meta keywords and description to each page. I also added a way to create a unique title for the times I wanted a different one from what's used in the h1 tag. In the layout, I just add a tag like r:meta_description and it renders the whole tag. I didn't consider the idea of combining child keywords and I'm not sure I'd recommend it (a lot of SEO best practices I've read seem to think that you should limit the number of keywords used on a page). Anyway, I'd be happy to release it but, because it messes with the edit-page, it really is a job for something like facets (any news on progress here core team?). Right now, it would break any other extensions that re-work this page. The other issue you run into with this approach is that keywords, title, etc are put on EVERY page which is a bit nonsensical for things like CSS or javascripts. What Radiant really needs (IMHO anyway) is some standard method to handle different page types. That way HTML pages would get all this stuff and CSS page entry would look different. (Hint, hint core team) -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] SEO in Radiant
Oliver Baltzer wrote: Maybe someone can fill me in or point me to relevant documents. Why is a flat URL namespace so much better for search engines than a hierarchical? From an algorithmic point of view I don't seem to see the difference except that a hierarchical space gives you the benefit of a context, which certainly some spiders (should) use. Actually, from my research it doesn't seem all that clear that a flat URL tree is better for SEO. It should be obvious to most that some of the best ranking, sites don't put all their pages in the root. That said, I have read several authors who have supposedly tested and seen benefits for smaller sites if all the pages were in the root. What isn't clear, however, is just how old those tests are. Some seem to think that older algorithms simply tracked the depth of the page and made assumptions from that as to how important the content must be (I even read one author who seemed to think that page names that were too long would trigger this effect). Anyway, those algorithms also seem to have changed as the search engines have grown up. Most site developers favor the organization that folders bring over the potential boost that a flat tree could give. It also seems clear that, if your site has more than one theme, grouping the content into an appropriate folder structure will help the spiders organize your content and can strengthen your rankings for pages. Short Answer - don't bet the farm on any magic techniques if they don't make good common development sense. Over time, the engines adapt to eliminate the sneaksters and ensure that those who aren't, aren't penalized. -Chris -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] SEO in Radiant
jf wrote: I think the original person's point was that a flat namespace allows you to design the URL structure that fits your scenario best. So, if you want a page to appear to be part of a folder, then you can assign it an appropriate slug. If you want child pages to not carry the name of a folder in the URL, then you have that option as well. Drupal is a good example of a CMS that allows this flexibility. From a practical standpoint... If you look at Radiant's style and purpose, the simplicity of use becomes polluted as we add features like put this file under this parent... but don't make it act like it has a parent. Sure to confuse basic users. Then there's maintenance. As I look at my tree how do I know which of those leaves are imposters? Do I have to open them one-by-one or do I have some alternate tree (or is it 'lawn') view. Finally, there's namespace issues. For instance, in the following: root |- A | |- B | | |- D | | |- E | | |- F | |- C | | |- D | | |- E | | |- F |- E Which page does http://root/e render? The above is perfectly valid (and common for some sites). Sure you can add validation rules to prevent saving a potential conflictingly-named file (similar to rules that exist for sibling files in a tree) but now you're complicating Radiant's code for a fringe case. So, if what you want is a site with all the pages in the root, why not create all the pages in the root? From a practical standpoint, this is the best. You get what you want, and still make it easy for another person to pick up your project and know exactly what's going on. The UI does its job of showing them what to expect, how it works, and what to do to create more of the same. Oh, *whispers* and be careful throwing around names like Drupal. It's been made very clear that Radiant is not intended to be anything like Drucckkrrrgghhh... *death gargle as writer is dispatched by a certain (unnamed) creator of Radiant for even putting that CMS in the same sentence as Radiant* ;) - Chris -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] Relative Linking in Radiant
My apologies if this has already been discussed... I'm converting a website which uses relative links into Radiant. Relative links are a bit screwy in Radiant because Radiant has done away with folders. I like this convention -- that pages can have children -- but browsers still think in terms of folders. The issue is the trailing slash. In the following example: root |- A | |- C | |- D |- B In Radiant, I can render page A in my browser with either: * http://root/a * http://root/a/ This makes perfect sense since page A is both a child of root/ and the parent of other pages. However, if in page A I have a relative link: a href=b, the target page depends on the address used. In the first case, I will be directed to http://root/b because the browser thinks I'm in the root/ folder. In the second case, I'm sent to http://root/a/b because it thinks I'm in the root/a/ folder. Has anyone else run into this? If so, how are you solving it? Is there a best practice here or some Radiant tag, or is everyone just using absolute URLs? -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] JavaScript in a Page?
In a site that I am building, I have a similar requirement. There are
standard, site-wide css and javascript files that are included in my
layout but I also have page specific javascript or css that occasionally
needs added to the head section.
I solve it by including the following in my layout:
html
head
...
r:if_content part=cssr:content part=css//r:if_content
r:if_content part=jsr:content part=js//r:if_content
...
/head
...
Then, in the appropriate pages, I create a new page part named css or
js and put in my code in there.
The cool thing about this method is that I can declare inline javascript
or css like:
style type=text/css media=screen
#mainPic {display:none}
/style
or I can include an external file like:
script src=/my/special/script.js type=text/javascript/script
-Chris
--
Posted via http://www.ruby-forum.com/.
___
Radiant mailing list
Post: Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Saving changes without publishing
Dave Olsen wrote: Anything more (e.g. a snapshot) sounds nice but you'll just add a level of complexity that not worth maintaining going forward. Come to think of it, once import/export is fully functional, if my clients could backup their site using export and recover with import, the whole rollback thing becomes kinda unnecessary. -Chris -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Saving changes without publishing
Mislav Marohni�? wrote: acts_as_draftable? Never knew of it. Me neither. Apparently there is an acts_as_versioned by the same author and both look pretty cool. Not sure what the difference is but googling turned up some interesting write-ups. Anyone know how well/if radiant would take to this? Even better, anyone interested in crafting an extension to add versioning functionality to radiant? -Chris -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] New Look
Ooooh John, you're so cool. http://dev.radiantcms.org/radiant/browser/trunk/images/blade/edit-page.png?rev=408 Thanks for all the hard work BTW. -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] CSS Bugs (mixed in with IE)
Happy to. Is there anyone intimately familiar with main.css? There are a few elements that look to be remnants from earlier stylings (like they once applied to this issue but now don't do anything). I'd like to clean those up too but I'd hate to learn that some secret page somewhere needs them. Anyway, it would help if someone was available to ask questions like what's the story behind this? Unlike ruby, CSS is ghastly to read and decipher. -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: [EMAIL PROTECTED] Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] CSS Bugs (mixed in with IE)
Well I'm done just lurking and have finally begun working with radiant. Like it. On this project, we've had to modify the edit_page.rhtml to add some fields. I ran into issues when trying to stylize these elements First of all, the CSS problems don't seem to be limited to IE (I'm testing with 6 right now). I also get some odd results using Firefox and Opera. I'm seeing two distinct issues: 1.) The .fieldset tables (within the div.extended_metadata) is set to choose some odd widths for the columns with input textboxes. Right now the textbox width is derived from a weird combination of the 100% style and the maxlength property. Actually, this looks fine on the default edit_page using Firefox but add a text box with a greater maxlength (currently the largest is 160 characters) and watch what happens. And even Firefox shows this odd behavior on the default edit_layout page (click more for content-type). Opera shows all these oddly but IE 6 really goes bonkers with this one - sending the textboxes off the edge of the screen. Though, in this case I don't fully blame IE - the applied styles here are a bit, well, interesting. 2.) I'm not even sure what to call this issue (reminds me of the good 'ol IE peekaboo bug). When you load the edit_page page, the title label (the one that says Page Title) is not shown. Try to select the text or maybe scroll just the right way, and it suddenly appears. The 2nd problem is all IE but is also easy to fix (one added line). The first one is a bigger change (actually it looks like the main.css could use some spring cleaning). So, I'd be happy to contribute here but I don't want to duplicate work that is maybe already being done. I also don't want to spend a lot of time only to learn that something like the facets branch is going to obliterate my work. Let me know how/if you want some help here. -Chris Parrish -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: [EMAIL PROTECTED] Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] RSS Feed for archive with sub categories
I was hoping somebody put would together something like this. Nice job Nancy! ...With one exception. You've got me down as releasing two extensions. Unfortunately I have no extensions out there. I'm just opinionated enough around here that it /appears/ like I am producing something ;). I didn't want to take credit where it isn't deserved. -Chris -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Two new extensions - WYSIWYG editor and Maruku filter
I just finished building a site that used a lot of PDF files scattered across pages. At over 50 pages, in some cases a single PDF fit well on more than one page. Now that I'm done, it looks like I am going to build another page listing all the PDF documents - an asset tree, if you will. This way, if the user remembers seeing a particular asset somewhere and wants to see it again, they can find it more directly. I've already organized my PDFs in an organized folder structure inside /public. I did this naturally -- in keeping with Dan's comment that all the assets in one folder would be a big mess. It seems to me that if I organized all my PDFs in some sort of asset manager centralized location, that I could now automatically create the asset tree summary page I need - complete with organization. Just like you'd create a menu using radiant tags based on pages. -Chris -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Two new extensions - WYSIWYG editor and Maruku filter
Nathan Wright wrote:
While I agree that they are an asset in a sense, they are also an
asset
with a behavior, and that certainly complicates things quite a bit.
Depending on the technical skill (or lack thereof) of a user they could
even bring down your site (image a bad javascript file that writes in
pr0n
to your page or a css file that includes the declaration body {
display:
none; }). For most purposes, I'd think that this would be giving too
_much_ power to the average user.
I'm not sure that it's a problem in most cases but certainly the
developer ought to be able to say that for this site, users won't be
able to add js but css is ok -- or whatever.
In another site, like one I'm building where the users are trustworthy
and where it will also require approval before publishing, this is
perfectly fine.
I see it like configuring your WYSISYG editor to allow H1 tags or not,
or blockquotes -- or anything that the developer, owner wants to offer
or hide, really.
-Chris
--
Posted via http://www.ruby-forum.com/.
___
Radiant mailing list
Post: Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Buckets, Page Types
Dan, thanks for your posts. You've given me the best example of a user's need for the asset to be seen as part of a page instead of in the radiant vat(tm) (kudos to Sean). To me this issue has nothing to do with where the asset is stored but rather the interface and how simple and intuitive it is to the user. In your case Dan, it is obvious that the user (you) needs a particular image and that the image's address is based on its use elsewhere. In the case where an one user uploads 100 clip art images for other users to use in their pages, the location (in the user's mind, anyway) is not related to where this image might already be used. In fact it would be bad if both writer A and B use the same picture (B by reference to A's work) and then A went and changed theirs. Similarly, in my case I upload a stock photo for use and, 100 pages later, I write another piece that could also use it. I don't remember which page I put it on before and it would be wrong to describe the picture as belonging to another page. So I'd just use r:image vat=/stock/set1 name=myPic /. In either case, I don't really care WHERE the picture sits -- just that the user can ask for it using the correct address (how they think about or need it). Both addressing methods are clearly needed. Like you said, it is all interface. Your extension could be extended to add a vat(tm) view with organization, browsing, etc. A vat(tm) based asset manager could allow for tags that reference the asset as such-and-such-image-on-page-x. Oh, and one other great point, Dan... A vat(tm) with too many items is hard to manage. It needs to be organizable (I implied a folder structure in my tag above but, of course, there are other ways). After all, the vat(tm) can hold assets long before they are used in a live work. Finally, I'll repeat my other concern. Regardless of implementation, there is a valid need to track which pages use asset-x -- not just which assets are used in page-x. This issue is the one that may dictate implementation (a central vat(tm) might make this easier). -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Two new extensions - WYSIWYG editor and Maruku filter
Nathan Wright wrote: I think that John believes that assets should belong to a page rather than being more universal in nature, but I honestly think that this may complicate things too much for the average user. In my system all assets are available to all pages. You add those assets (be they images, pdfs, whatever) to your bucket (yes, I'm shamelessly ripping off Mephisto's buckets), and then you simply click on them to insert them into your page. I agree with John and other's drive for simplicity in design and implementation. So there, the attach-an-image-to-a-page makes some sense -- but only as long as users only ever use a given asset once. The minute they want to reuse it, we've just made the user's life harder. The concept that an image is owned by page A and not page B is arbitrary (I can see them thinking that it is somehow unfair to page B and would probably just store the image with each page -- messing things up when they must update that image and kissing DRY goodbye. It also forces the user to use their memory instead of having the system keep that knowledge: I need picture X -- I know I used it before. Let me see, where did I put that... In my opinion, any good system should be able to tell you where (or if) assets are being used (in other words look at it from the asset perspective too). The insert behavior is smart. If you are inserting an image, it will insert an image tag into the page. If you try to insert a PDF, mp3, etc. into the page (or something else that can't be directly viewed by the browser) the insert behavior will stuck a link into the page instead. Like above, the precise form of this link will depend on the filter that is applied to the page. In short, I think that inserting an asset into a page should be a simple procedure ... the user shouldn't have to think about the markup required to insert it. I like this approach too. In fact one of the concepts that I've been playing with is uniquely styling elements in certain pages -- rather than sticking every possible fringe case into my main CSS file. Similarly, I may create a dynamic page or two (say with an interactive maps) that needs some unique javascript. In these cases I build mini CSS or JS files that are, really just assets to me. These need that same smart behavior to include them in the page correctly. Of course, in this case, they are added to the head section (automatically). This is certainly beyond what most asset managers are attempting but the use cases are, really, identical with insert an image, figure out where this image is used or remove image from page. Is this at all like what you're looking for? What are your ideas on the matter? Sounds like you're heading in the right direction (IMHO, anyway). Feel free to contact me directly. Others are welcome too -- I'd like to consider all possibilities. I think that this is a much needed aspect to radiant (though maybe not something you'd ever put in the core). -Chris -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Buckets, Page Types
As to your page types, I was kind of surprised to see your grouping page. I plan to develop an extension shortly for a project that might line up with your grouping. I'll share it here in case it actually is a more generally usable concept than I thought. I apologize in advance for all the lead-in... I have a website that is collecting stats on various cities in the region. Since these stats may be used on multiple pages and the data changes from year to year, I plan on sticking them in the db and calling them from custom tags within static pages. For example: \Cities (index page) \City A (static content plus stats from db) \Map (static content plus map built from db) \Chart (static content plus charts from db) \City B (static content plus stats from db) \Map (static content plus map built from db) \Chart (static content plus charts from db) ... Essentially I'm grouping cities together here. I'm planning to make an extension to set the property for each city page based on choices within the db (i.e city=City A). It's children would inherit this property. Now, I obviously need to build my own tags/extend radiant for each of the dynamic pieces (stats, maps, and charts). That way, in the chart page I could just insert r:chart city=current /. Why be this fancy? I have multiple categories (cities, counties, school districts, etc.) -- all of which can overlap in weird ways. Now I'm wondering if it's actually a unique need. I'd be happy to develop a public extension if I thought anyone other than me would use it. Any takers? -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Two new extensions - WYSIWYG editor and Maruku filter
Sounds good. I'm looking forward to playing with this. I can see it being very useful (though I share John's distaste for using WYSIWYG editors) for my customers. Are you willing to provide any details on the asset management piece you are working on? I've read about what the others are doing on and none of the approaches seems quite right for my needs. Actually, anyone working on an asset management system is welcome to contact me directly. If there is some way to make things work, it is possible that I could generate some funding to help develop it. -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] My notes/ideas on Page editor extensions
Daniel Sheppard wrote: I think the first step needs to be breaking down the existing parts of the edit page into partials so that the actual edit page itself contains barely anything except a list of includes. From that point, you could do a lot of editing of the interface without getting out of step with any additions to the core features. Can you make a pass at that? Oh yeah. Liking this one. I've actually been thinking about this a lot lately. Just so you know John I have an app that needs to store meta tag stuff like keyword, description, and some other custom fields with each page -- much like Dan does. I suspect this is a *common* need (except different folks will need different fields). Is there any way we can not only make it easy to customize the page edit template but standardize a way to add basic fields (I'm defining a basic field here as any one-to-one relationship to a page)? A standard could then allow for things like having your up-and-coming import/export feature (http://dev.radiantcms.org/radiant/ticket/301) auto-recognize and import or export these custom fields. -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Ordering of pages
If you start typing into this box, it becomes an AJAX-y auto-complete box with the names of pages whose page name or url matches what you are typing... when you select a parent, the full url is shown in the text box. The issue with separating parenting from ordering is twofold: 1.) Two different actions for the user to learn. 2.) If you want the 2nd document under parent #1 to become the 3rd document under parent #2, you have to do two steps. Parent, then order. Fundamentally, it just goes against the user's goal. In the their mind, the thought is simply I want this moved to here and a single operation follows that thinking. The complexity of implementation -- well that's a whole other issue. BTW, John W. Long wrote: I think I favor drag and drop reparenting, but with the option to Cancel if you make a mistake. Much like the implementation of the current reordering patch. The cancellation step is where I would provide the *option* of automatically creating a redirect page upon completion (say, a box -- unchecked by default -- to preserve the old uri). If you want to get really fancy, you could control the default checkbox state or even if the user has that option in some admin configuration. This way an admin could establish it as a site policy. -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Reusable Page Parts - With A Twist
Kevin Ansfield wrote: If you're trying to do what I think you're are then it should just be a case of using the radius tags... r:find url=section/page-name r:content part=part-name / /r:find That will pull the page-part you specify out of the page that you selected with the find tag. Does that help at all? Thanks Kev - not sure how I missed that one. -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Reusable Page Parts
By the way, this problem sounds an awful lot like the whole resources thing to me. Sure, in many cases a resource is only used once and can be attached to that page. But in other cases, say with a logo or other commonly used element, the resource belongs more to the site than any one page - just like a style sheet. When I think about the resource/attachment problem, I see: Primary Issue - Who/What owns the resource (or in my case the sub-element) and how do you reference it from multiple pages. Secondary Issue - How can you find out where (or if) the resource is being used (for cleanup and maintenance reasons). Just my $0.02 -- hope it helps how the whole resource problem is approached. As I said in my original post, my problem here is really common when abstracted. I only need the Primary Issue solved for now, though. -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
