Allow the meta tag "Description" tag to be generated from the node teaser
kiamlaluno - September 22, 2009 - 17:12
| Project: | Nodewords |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
| Issue tags: | 6.x-1.0 |
Description
As I already reported in other comments, the meta tag Description
has a purpose that is different from the purpose of the node teaser; then, the meta tag Description
content is supposed to not contain HTML tags, which are allowed in the node teaser.
For this reason, I am planing to remove such feature from the module.
#1
The code has been changed.
#2
Whoops, I respect your decision, but I must admit I was quite shocked.
In my view this is one of the reasons to use this module. If you are worried about html-tags in the metatags, well the strip_tags command is already there... I think you will be generating many support request when people start updating after the security issue mail.
All I want to say:
Feel free to close this issue, but please add a note to the settings page that this possibility has been abandoned.
#3
Another reason I removed the feature is that other restrictions for the meta tag content are different from the restrictions for the node teaser. If you are the administrator of the Drupal-powered site, then you will probably be able to keep the node teaser short enough to make it suitable to be used as meta tag , but the other users of the site could not be aware that they need to make the node teaser not too long.
See what the description for the form field says:
%countis 255 by default.I will add a note in the file README.txt.
#4
I will miss this feature. I wish there was at least an option to have the first 255 characters of the teaser be the meta description, without HTML in it. :-( I'm sorry to say I will have to reconsider even using this module if it can't supply an automated description of some kind.
#5
Actually, I had to remove any reference to the feature in the README.txt.
#6
I'd have to say this is a pretty serious ommision. Like others, I find it was a great feature of this module.
Surely at least having an admin option, as mentioned, to strip_tags and then limit to 255 characters is needed. Most clients hardly ever look at their meta tags, auto generating them is not ideal, but it is a very user friendly feature.
I'm afraid I'll be sticking with my patched version unless this is becomes an option.
#7
If you are looking for a module that auto-generates the meta tags basing on the options set by the administration user, there is Integrated Metatags.
#8
This is a pretty bad decision. I loved this feature and now I have to update lots of articles to set the description. :(
That's quite a lot of work.
I've used the module you propose and now i get the following problem: I want to have the description tag on all pages. If i use the 2nd module you propose, I get description tags for all articles and none for the homepage.
If i enable the description tag in nodewords & use the 2nd module I get two description tags on the articles and one on the homepage.
It is really hard to fix this issue and I believe it was a bad design decision to get this feature out this module. It makes people's lives much harder.
#9
I have to comment on how I agree that this was a bad decision. I agree with others that a choice would most certainly be welcomed. Not only to give people the chance to choose who are new to the module, but for the people who have been using it for a long time as well.
I for one have only lost just one description tag because of upgrading the module on one client's site, but if I did it on another site of mine I would have lost thousands.
I kindly ask you to reconsider this.
#10
The int_meta module simply doesn't have all the features I need. nodewords does.
This modules user base suggest that people like the features this module has, and judging by the comments in here it seems this is one of the desired features.
#11
This is a must. All too often crawlers miss the important text and display the menu items as the description on search results pages. While not perfect, this module did get the job done. Please bring this back!
#12
#13
Even a description tag based on the title, like the new dc.title tag has, would be preferable to none at all. Some search engines use this tag when deciding what descriptive text to display text next to their links of sites.
#14
Bit of a show stopper this one. I aggree with priority critical. Due to the security fix site's are now showing up with "Security update required!".
Yet an update means auto generated descriptions will be nuked.
#15
Did anybody look for issues related with the generation of the meta tag from the node teaser?
#16
I just searched the issues for "Description" and couldn't see anything of relevance to this topic. Please forgive me if there are issues out there in the forums or elsewhere, I did a quick search in the forums and got way too many pages of results to go through in the time I have at the moment to look for relevant posts.
If the main issue here as to why the feature was removed is HTML tags in the teaser being output, then comments #2 and #6 propose using strip_tags to ensure the teaser is output correctly. I've actually had issues on other sites with tags being output in the teaser and used contemplate with strip_tags to output a proper description tag and views as a workaround for getting a proper teaser displayed on my site.
If a solution was put into place where strip_tags or another method was used to output an auto generated teaser that didn't contain any tags or other improper formatting, I believe that would make everyone involved happy. I, for one, would certainly be!
#17
I too had liked the description from teaser feature.
I'd rather have description that might have some html (whatever that might do), than none at all!
Possible to make this an option, with warning saying it's naughty to have html in descriptions and you have been warned??
#18
Just tried adding a description to a page.
I use fckeditor; found that the paragraph codes were saved with the description.
So, to really eliminate html from the meta tags, best to also ensure a wysiwyg editor doesn't work for the editing fields, or at least note that if they do so, you use "source" code editing option so that don't accidentally insert html.
#19
The code used
strip_tags(); that is not the problem. Creating a node teaser in the wrong moment causes problems with some content types (see #364682: Conflict with Ubercart / Ubercart Auction).I am not than convinced that a node teaser is thought to be used as description of a node; it could be used as a kind of summary, but it is not a description.
#20
I've just gone through the issue you had linked to. Am I right to believe that the issue is now fixed? It looked that way from the thread.
If so, I'm not sure why this feature would have been removed. As you have said:
If this is an argument as to what exactly a description should be, maybe that should be left to the site administrators.
In an ideal world, everyone posting content to a website would take the time to write a unique description for each of their pages, and let's face it, people won't. That's where an auto generated description is a life saver. In my experience, my clients, some tech and internet savvy, some not, never really get the importance of meta tags, and can't be bothered to fill them out. So for the most part, I don't even allow the end users to modify the tags and I let them get auto generated. That way there's a description for every page, no matter what. Also, the fieldset adds clutter to the add node form for people who don't fully understand what it does, and in the end, in my opinion, can cause more harm in usability than good. Non technical people get scared by it, and get put off.
There are also many instances where nodes are generated automatically, I have a few such sites where that happens and they all have thousands of nodes. It's not practical to write descriptions for each of them, or that's all I would do all day.
In the end, I don't think the people who want this feature care if it's the node teaser or not, it's about having a way for the description tag to be generated automatically. And not having all of your description tags disappear when upgrading the module because of a security fix.
#21
Given the way Nodewords used to work, I started writing teasers with idea they might be used as descriptions.
Teaser should grab readers' attention, encourage them to want to read more. So could be good as snippet for search results.
Plus, teasers can be better than nothing - and better for search results snippets than some of content that Google, say, can grab.
Too bad re the conflicts; had been a nifty option.
- possible to include as option, with warning things could go awry?
Especially for active forums, handy to have auto-generated descriptions, as otherwise quite a faff to create one for each thread.
#22
Nodewords is not thought to auto generate meta tags; it simply helps in create the content of the meta tags, which can always be overwritten by the user.
If you don't like the user to change the content of the meta tags, then you can change the permission used for the rules of the users (there is a permission for each meta tag).
Another alternative is to use Integrated Metatags, which is thought to generate the content of the meta tags from values obtained from the node (through tokens, or taking the content of CCK fields).
About auto generating the content of the meta tags, Nodewords will implement a page to auto generate them in the future.
#23
Yet the comparison of Nodewords and Integrated Metatags notes:
[I've added comment, saying this isn't the case with updated version]
I've started using Integrated Metatags, for descriptions from teasers (chiefly for forums, so far); yet not so great to have it at same time as Nodewords (which I still have as I wrote custom descriptions tags for several article pages).
Hope you manage to soon implement the page for auto-generating tags!
#24
I reported in that forum topic that the differences between the two modules were not valid for the version I was developing.
#25
I'm surely abandoning this module in favour of Integrated Metatags, due to lack of this must-have feature. Bye.
#26
I have marked #586846: No automatic teaser description after upgrade as duplicate of this report.
#27
Ouch... this security update certainly came with some changes. I thought I was out of the woods after finding the new hook names (which seem to be buried in a issue), but this change I don't really understand.
Why not at just leave the option available and defaulted? It's certainly going to annoy a lot of people who are just updating for security, and it's not as though it didn't serve some purpose.
I vote for its return as well! :)
#28
how serious is the security issue in the update? i will likely be rolling back to the previous version or switching to Integrated Metatags
#29
@KiamLaLuno
You are killing this module. You need to put this feature back in. In less then 24 hours you have 10+ people complaining, and with a project of this size (30k users) it's only going to get a lot worse.
Will you accept a patch, or are you going write the patch?
#30
#29, mikeytown2 - Couldn't agree more.
And yes, KiamLaLuno, will you accept a patch?
#31
working my way back from the point of tag insertion seeing where one can easily inject the description.
For a node with nid of 50
function nodewords_preprocess_page(&$variables) {list($type, $ids) = _nodewords_detect_type_and_ids(); //$type = node, $ids = 50
$variables['head'] .= nodewords_output_tags(nodewords_get_tags($type, $ids));
}
nodewords_get_tags
nodewords_get_possible_tags
module_invoke($module, 'nodewords_api'); // make sure its 1.1
module_invoke($module, 'nodewords_tags_info');
basic_metatags_nodewords_tags_info() // settings, nothing special.
// Allow third-party modules to alter the meta tags.
drupal_alter('nodewords_tags', $output_tags, $tag_options); // Might be a good place to hook in...
Implement drupal_alter; grab $output_tags & $tag_options find description and set if empty
Hardwire way to hook in
nodewords_output_tags {
foreach ($tags as $name => $content) {
if (empty($content)) {
continue;
}
$parts = explode(':', $name);
In the above code, IF $parts[1] == 'description' && empty($content) THEN $content = node's teaser
#32
Another way would be to mod the basic_metatags_description_prepare() function.
<?phpfunction basic_metatags_description_prepare(&$tags, $content, $options) {
if (empty($content['value']) && count($options['ids']) == 1) {
switch ($options['type']) {
case 'term':
$term = nodewords_get_term($options['ids'][0]);
if ($term) {
$content['value'] = $term->description;
}
break;
?>
Already sets the description for terms & vocabulary; nodes could easily be done here. This is the best option IMHO.
#33
Untested patch, should work.
#34
This better conforms to the nodewords pattern. Still missing an on/off button, if description is empty, it will grab from teaser. Still untested.
#35
Above patch WORKS! It needs to go through all the filters though, image assist gets outputted. This patch fixes that.
#36
do trim; kill any white space at begging or end.
#37
I'm happy with the next patch. Goodnight.
#38
I will read the feature.
The last patch reported here needs work; nodewords.module doesn't use a constant for the content limit, but it uses the value reported in the settings by the administrator user. Also, any call to function that filters the meta tag content are done by nodewords.module for all the meta tags added; it's not the task of the prepare functions do that.
#39
nodewords_output_tags() only does a check_plain(). Teaser can have almost anything in it. Once it is stripped to just text, then there will be less then the maximum value in it, if all the checks are moved to the nodewords_output_tags function.
#40
actually because of the check_plain we need to decode, then encode; cut to length, then decode. Otherwise we risk the chance that this is over the max limit or characters get double encoded.
#41
The attribute for the element is declared of type CDATA, which is described as (see http://www.w3.org/TR/html401/types.html#type-cdata):
I re-added the feature in the development snapshot; the only difference with the previous code is that
node_access()is not called as it is not really necessary (especially because the module knows when Drupal is outputting an error 403 page, and outputs a different set of meta tags).#42
Basing on what reported in the W3C, the call to
explode()is not necessary, and the other code needs to be moved to the function that creates the HTML output.#43
With this patch works again that the description tag is automatic?
#44
@k74
yes automatic description tags from the teaser are back.
@KiamLaLuno
wordwrap splits up the text, delimited via "\n"; the explode("\n", ...) is necessary, its what cuts the string to the correct length.
#45
@miketown2: The browsers are supposed to replace any carriage return with a space (see my previous comment); that code could be removed, then.
The other code can be moved to the function that creates the HTML output, as most of the meta tags require the same treatment (i.e., HTML tags should be removed also from the meta tag ).
#46
Looking at
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/nodewords/b...
I like the idea of grabbing the alt text. Issue I still see is the max description length isn't always set to it's max, it can be under. Using http://api.drupal.org/api/function/truncate_utf8/6 is better then my patch. The last thing to do IMHO is trim so it fits; might want to move that to the nodewords_output_tags() function.
#47
The maximum description length is the maximum length a meta tag content can have; it's not the length the meta tag content must have.
Does the code I committed for this feature need to be modified?
#48
image assist gives
[]as output and&characters get double encoded as&amp;; length is not set to 255, I got 484 for one of my nodes.#49
The problem of the HTML entities being encoded twice is already reported in a different report (see #587094: HTML entities cannot be used in the meta tags content).
The output you get is caused by the fact the attribute probably contains an empty string, or is not set at all. The part of the code was already present in previous versions.
I would then mark this report as fixed, and open a new report for the problem you reported.
I don't understand why the meta tag is longer than the limit set by the module; the meta tag description is truncated by
node_teaser($node->body, $node->format, variable_get('nodewords_max_size', 255)).node_teaser()contains the following code:<?php
// If we have a short body, the entire body is the teaser.
if (drupal_strlen($body) <= $size) {
return $body;
}
// If the delimiter has not been specified, try to split at paragraph or
// sentence boundaries.
// The teaser may not be longer than maximum length specified. Initial slice.
$teaser = truncate_utf8($body, $size);
?>
I noticed that the code I wrote is missing a part I thought I have already added, and which could cause problems when the node body is using the PHP input format.
As the feature has been already added, I am marking this report as fixed; I will create another report for the changes that needs to be done to the code.
#50
with this patch in some nodes do not see the description tag with the description automatically generated and other
yes, for no apparent reason...
#51
Using 6.x-1.2
I solved in this quick and dirty way:
<?phpfunction custom_functions_nodewords_tags_alter(&$output_tags, $tag_options){
if(
($tag_options['type'] == "node") &&
(count($tag_options['ids'])==1) &&
(empty($output_tags['description']))
){
$node = node_load($tag_options['ids'][0]);
if ($node && node_access('view', $node)) {
// HACK: see <a href="http://drupal.org/node/79315" title="http://drupal.org/node/79315" rel="nofollow">http://drupal.org/node/79315</a> (can't use php functions in
// body of nodes). Note that this still won't work if you have a
// CCK field with PHP format.
if (filter_format_allowcache($node->format)) {
// We would like to use node_view($node, TRUE, FALSE), unfortunately
// this uses theme_node() which, by default, adds 'Posted by ...'
// information (which we don't want). The code below calls all
// functions node_view() does, without the theme.
$nodeContent = node_build_content($node, TRUE, FALSE);
$content = drupal_render($nodeContent->content);
$nodeContent->teaser = $content;
node_invoke_nodeapi($nodeContent, 'alter', TRUE, FALSE);
$output_tags['description'] = substr( strip_tags($nodeContent->body), 0, 250);
}
}
}
}
?>
#52
sub
#53
Grab the latest dev or use my patch. They both work and are alt ways of doing it.
#54
The code reported in #51 will cause problems with some custom content types defined from third-party modules (there is already a report about Ubercart).
I suggest to not use it.
#55
Just giving latest patch a try, and not successful so far.
Only seeing single letters for descriptions, keywords.
- such as
meta name="description" content="I"
meta name="copyright" content="C"
Also, not sure if auto-generating is working.
#56
Auto-Generating keywords and description was the best of this module; Please re-enable it.
Thanks.
#57
Just upgraded my Nodewords modules to the latest version and came up against the issues described here. I'm glad I did it on my personal site rather than my important production sites though.
I don't want to sound snappish, because it's easy to make mistakes, but the auto-generated meta descriptions are a KEY FEATURE of Nodewords, so to find it has disappeared completely without warning is a little bit upsetting. Yes, I understand that the Integrated Metatags module does a similar job, but considering Nodewords is the recommended module for generating meta information, it's essential that feature is re-enabled as soon as possible.
If you need any help testing, please get in touch - I'm happy to run patched versions on my test server.
#58
@#57: The feature is already re-added; as usual in Drupal development, the code is first added in the development snapshot, and an official release is then created by the development snapshot code.
#59
As noted, latest dev didn't work for me. [I'm adding note here as important enough that people should not overlook this]
Nearly went to Integ Metatags, but thought I'd try mikeytown's patch. For 1.2 version.
I'm not good w unix, so did a cut n paste patch - may help someone: opened file to change in text editor, found the same line in mikeytown's patch as the one above his lines to add (marked with + signs), copied and pasted this in, and deleted the + signs. Saved file
Then, uploaded the 1.2 nodewords, inc dev, replacing the dev version.
Found I needed to clear cache. Descriptions - main things I'm concerned about - back.
[just noticed
<p>- which turns out to be code for paragraph start at start of a description, similar code at the end; but I don't care too much about that just now!]Thanks, mikeytown!!
#60
I agree that auto-generated Descriptions was a key feature of this module, and it's really a bad decision to remove it.
I wonder if you counted the number of people who need this module to work smoothly with Ubercart vs. the number of people who want auto-descriptions like they used to be, which would be the larger?
#61
...and couldn't you check for the existence of Ubercart and disable it just for those people?
#62
...or just make it a selectable option, rather than removing it outright?
#63
The patch in #40, while much appreciated, is including image captions at the beginning of the meta description tag, which is not ideal. The old way (before the upgrade) worked just fine. Can we return that functionality? If not, I will have to think seriously about rolling back to version 1.0, vulnerability or not.
#64
@WildBill
try the latest dev
#65
@mikeytown2 - what about the big red warning on the project page that warns not to use the dev version on a production site?
#66
subscribe
#67
I am so glad I found this out on my own site, and not that of one of my customers. Thank you for listening to your users and adding this feature back to Nodewords.
Does any one know when the 6.x-1.3 production version will be available? I am not familiar with the "development snapshot code" that KiamLaLuno mentions.
#68
I have installed the 6.1.2 dev but not seeing any descriptions. Any ideas?
#69
See the referring version, which is 6.x-1.x-dev; this mean the code has been fixed in the development snapshot (it is not possible to fix the code of an official release if not creating another official release, which is created from the development snapshot code).
#70
@KiamLaLuno
Do you have an ETA for 6.x-1.3?
#71
I had to clean up the installation files for the Nodewords modules, which included many update functions related with development snapshot to development snapshot updates. I also had to clean up the code to fix any problems created when I changed the module names from the wrong ones to more correct ones.
My intention is to create an alpha version in the next days, but I would not want to make the mistakes I made with the previous official releases I created. It would be useful if I would have more reports from people passing from version 6.x-1.1 to the development snapshot, to be sure the update is possible (even if I imagine there could be problems with people having a lot of meta tags set).
I first apologize for the wrong releases I published; the worry of seeing the module unpublished because a security issue (which was not anyway present in the code I developed) didn't allowed me to better plan the release of version 6.x-1.1. Still, this has been solely my mistake.
#72
Kiam, I personally am grateful for your work on the module, there is nothing to apologize for. Taking the effort and working on it means more than other stuff. Only those dont make mistakes that dont work :)
#73
Ditto, I installed the security update and then discovered the feature is gone.
This feature is the main reason I installed nodewords in the first place, it needs to be back and working in a stable release for me to use the module, so I am downgrading to 6.x-1.0.
#74
I'm thinking about downgrading to 6.x-1.0 as well...
#75
Remember there is a patch for 1.2 at #40
#76
Highly critical, because if you update to this version without checking the changes that have been made you could get kicked out of google index.
If google finds hundreds or thousands of pages of your site with the same description it will not show them anymore (although they still are indexed).
So glad that I checked it immediately after installing this version. Patch at http://drupal.org/node/584720#comment-2081160 works fine.
Nevertheless, thank you again for this module. Must have.
#77
The patch at #40 is not perfect... it doesn't work the way the old module used to...
#78
hi Kiam,
In the latest dev from the 17th I don't have any meta descriptions showing, even though I ticked to enable it.
Would you have any ideas?
Cheers,
G
#79
Sorry, I did not have "Use the node teaser if the description meta tag is not set" enabled.
I enabled it, but I got a fatal error:
<b>Fatal error</b>: Call to undefined function nodewords_metatag_from_teaser() in <b>.../sites/all/modules/nodewords/nodewords_basic/nodewords_basic.module</b> on line <b>314</b><br />#80
It is better to make a different report for that error.
#81
In the new version 1.3 alpha1 the option "Use the node teaser if the meta description tag is not set" is still missing, a patch
to activate? The patch #40 is not valid for the new version
#82
By a mistake, the form field was only activated for the content type forms. This is now fixed in the development snapshot.
#83
I upgraded to the new dev version but I still see the option "Use the node teaser if the description meta tag is not set" where is it?
#84
#83 do you mean you dont see it?
Because it disappeared for me, and I cant see it.
#85
You need to wait until 12:00 PM UTC, to use the correct development snapshot.
#86
ok, with the latest dev version does appear and it works
#87
I tested 6.x-1.3-alpha2.
I see that there is the option to set "Use the node teaser if the description meta tag is not set" either globally (in admin/content/nodewords) or independently for each content type (via the edit option in admin/content/types). I think this is nice.
The global option is working well.
Problem is with the second option (for each content type): I can see and modify the check box when editing a content type, but when I save the content type it does not save my changes. Basically the check box at the content type level always reverts to mirroring the global option: when the global option is on, I can see that it is also checked for all content types, when the global is off, it is unchecked for all content types, but with no way to make changes at the content type level.
Thanks for this great module.
#88
@dawansv: #612210: Global settings not shown on settings page
#89
Thanks Kiam, the new dev version works marvels for me.
I expecially like the option to remove alt tags from descriptions if generated from teasers.
Great job!
#90
@hass: not sure how #612210: Global settings not shown on settings page is related to my problem. My problem is not with global settings not appearing, but with the "description from teaser" option not being saved from the content type edit screen (it appears there just fine)...
Can anybody else reproduce that? Edit a content type, and under the Meta Tags Settings try to change the "Use the node teaser if the description meta tag is not set" option... Then save the content type and reedit to see if your change was saved...
#91
Automatically closed -- issue fixed for 2 weeks with no activity.