Given the debate about how to implement an "inherit" functionality for
something that already exists with r:content, I'd say this is bloat.
I think there is a benefit in the user interface though, to have a
text field rather than a text area to manage a small amount of content
so I could be persuaded to leave it in for that reason. But I think
that another option there might be to simply create a new way to add
page parts in text fields near the title area (I don't recall what
shards calls it). Add a part as a big text area in the tabs or add it
as a text field. They could be functionally the same, but depending on
the scenario they encourage (or discourage) a user in entering a
certain amount of text.
I use page parts on the home page, for example, to allow users to
alter things like the footer text on their site. Adding "Copyright
2008 Super Happy Funtime Inc." in a big text area isn't ideal (because
of the size of the text vs the size of the area given) but it does the
job. And it easily is inherited on every page.
I recall seeing the request for r:meta on Trac a long time ago and
just figured it wouldn't be added.
I think, however, that something like a "truncate" attribute makes
sense even for both cases... You can have users fill out a description
part, or just use the first 50 characters (for example) of the body
and use that in your meta tags. This would of course cause problems
with HTML being entered so that would take a little more thinking.
Having said all of that, I don't think its a major detriment that it
exists, but I don't think it is necessary and probably shouldn't exist
in the future.
Should I feel out of place in this conversation since my last name
isn't Cribbs? ;-)
-Jim
On May 19, 2008, at 3:34 PM, Sean Cribbs wrote:
Jamey,
That's great. In response to Jim, it was a common enough use case
for people who do SEO for their sites and such a low overhead to
implement, it seemed like a reasonable thing to add. I'd appreciate
debates on this matter, however, as I'm open to culling superfluous
code from the core.
Sean
Jamey Cribbs wrote:
I just implemented what Jim suggested in my project and it works
great. I created a meta_keywords and a meta_description page part in
the pages that I want the tags. The nice thing is that you can use
the inherit="true" parameter.
On Mon, May 19, 2008 at 11:52 AM, Jim Gay <[EMAIL PROTECTED]>
wrote:
I'm curious about why r:meta was implemented. Couldn't you get the
same
result by using page parts and dropping them in the appropriate
place in
your layout?
I haven't used r:meta yet, so perhaps I'm unaware of some
particular benefit
-Jim
On May 19, 2008, at 11:47 AM, Sean Cribbs wrote:
Personally, I'd like to see inheritance of meta info be optional
and not
the default.
Sean
Chris Parrish wrote:
I just wanted to mention that I just noticed this change and am
glad to
see it implemented in core as well. It eliminates the need for
my page_meta
extension.
I too, like the inheritance idea (an optional attribute of the
tag) but I
would also like to see a feature I had implemented in my
extension.
I the 'tag' attribute (mine was 'as_tag'), I had allowed true |
false |
unless_blank for the reverse case that Jamey is mentioning. I
have sites
where I *don't* want keywords to inherit. They need to be
explicitly
defined or else the page gets none. So, by using the
'unless_blank' option,
I was able to prevent the page from kicking out an empty set of
<meta> tags.
I'd be happy to write up a patch for this if others think that
this would
be helpful.
-Chris
Jamey Cribbs wrote:
First of all, thanks very much to the dev team for all of the
latest
release activity. It is greatly appreciated!
I do have a question about the new metatags fields for keywords
and
description. These work great, but I noticed that there is no
way to
set them to inherit (unless I am missing something). It does
not look
like you can set these fields on a parent page and have the
children
inherit them. I thought that this would be the desired
behavior, but
maybe I am missing something.
Thanks.
Jamey Cribbs
_______________________________________________
Radiant mailing list
Post: Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
