Closed (fixed)
Project:
Metatag
Version:
8.x-1.x-dev
Component:
Open Graph
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
9 Dec 2015 at 00:23 UTC
Updated:
31 Mar 2016 at 20:54 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
damienmckenna... oh dear.
Need to fix this and write tests for it.
Comment #3
damienmckennaComment #4
damienmckennaComment #5
juampynr commentedHere is a patch that fixes it. I took the approach from core:
Comment #6
juampynr commentedComment #7
damienmckennaCommitted. Thanks!
Comment #9
juliencarnot commentedJust updated from beta3 to dev through
drush up metatag-1.x-dev(which worked I got several of the fixes, such as issue #2642430) and rebuilt cache but I'm still seing html tags when using [node-summary] in the description meta:Value of the summary:
This <strong>is a test</strong>Meta description rendering:
<meta name="description" content="This <strong>is a test</strong>" /><meta property="og:description" content="This <strong>is a test</strong>" />Did I miss a step?
Comment #10
damienmckennaOk, lets add some tests.
Comment #11
mr.baileysComment #12
sushichris commentedIf I embed a youtube video in my sites content under "body" and post the content on facebook it does not embed the video, I know when posting videos to facebook you just throw the url in the box and it displays the video, how can I display the video via my sites content? Only the code shows, is that related to this issue? I just created a simple content with the default "body"
<div class="video-container"><iframe width="560" height="315" src="https://www.youtube.com/embed/7t8kmTNLNUQ?rel=0" frameborder="0" allowfullscreen></iframe></iframe></div>I am not sure if this is a metatag feature or if it even is possible, can't tell because of the metatag rendering the html tags anyway.
Comment #13
damienmckennaWhat's weird is that the API docs say that the HTML tags are supposed to be stripped from the content, so it should be working correctly. Definitely need to dig into this a little bit for the next beta release.
Comment #14
damienmckennaBumping this to beta5 so that beta4 can be released sooner.
Comment #15
yury n commentedPatch from #6 will break metatags with tokens for node's image field - it will just strip out
<img>tag. So needs at least check likeComment #16
mikeyk commented@sushichris @DamienMcKenna @juliencarnot - I've been working on the issue of HTML tags still being rendered and think I've found the reason. The PlainTextOutput::renderFromHtml function correctly strips HTML tags, however the value in $token_replacements seems to already be sanitized with HTML tags converted to HTML special characters. Therefore <, > etc remain in the output.
Adding htmlspecialchars_decode to the function resolves this and means all HTML tags are correctly removed. Suggested patch attached
Comment #17
sushichris commented:) I wasn't able to apply the patch but I swapped the line of code that the patch was supposed to and it works. I think because the following line of code wasn't in my file.
$langcode = \Drupal::languageManager()->getCurrentLanguage(LanguageInterface::TYPE_CONTENT)->getId();Comment #18
damienmckennaWould someone mind trying to write a test for this? Thanks.
Comment #19
sushichris commentedwell it kinda worked, one content renders this:
From this code:
Comment #20
damienmckenna@sushichris: Can you please provide the exact HTML tag that is output on the page? No parts of the "*/ /*-->*/ Product Addons SEO" string appear in the HTML chunk you provided, are you sure you're looking at the right HTML?
Comment #21
mikeyk commented@DamienMcKenna Attached is an updated version of my patch with tests. The tests work on three values in metatags -- one without any HTML; one with raw html; and one with escaped HTML. To pass all HTML including escaped should be removed.
Comment #22
mikeyk commentedUpdated patch which includes code from #15 to fix issue with images @YurikK_
Comment #23
juliencarnot commented@mikeyk:
I applied meta_tags_don_t_filter-2631408-22.patch from comment #22 on a fresh 8.x-1.x clone, uninstalled and reinstalled metatag and opengraph&twitter submodules to rule out problems with previous config and used drush cr to rebuild cache.
I get a fatal error on the homepage:
Fatal error: Unsupported operand types in /var/www/html/modules/metatag/src/MetatagToken.php on line 99On the extensions page, there are some notices and warnings:
Comment #24
mikeyk commented@juliencarnot Thanks for the feedback - Here is an updated version with the the langcode array added. This should fix the errors you got from patch #22.
Comment #25
juliencarnot commented@mikeyk: Thanks, the patch fixes the errors and now I get the relative path of the first image stored in my field for the node for twitter_cards_image or all the relative paths separated by commas for og_image (which is not compliant with opengraph apparently, but it might be an issue pertaining to the og submodule). However, it seems that Twitter card validator needs the absolute path. I tried using [site:url][node:field_image] or even putting the website's URL in front of [node:field_image] , to no avail.
Also, a bonus question: shouldn't [node:field_image:1] give only the URL of the second image in the field? It could allow to pick the main image for open-graph.
Comment #26
damienmckennaComment #29
mikeyk commented@juliencarnot @DamienMcKenna I've done some more work on this and fixed a couple more things. The issue that @juliencarnot raised with relative paths is an interesting one - I tested this module with #24 patch on a Drupal 8.0.3 installation and the paths produced were absolute, however once I upgraded to 8.0.4 or 8.0.5 the paths became relative. Drupal 8.0.4 was a security release so this must have been changed for a good reason, but it explains why it's only recently become an issue.
The updated patch should convert a relative path to an absolute one based on the global $base_url. Let me know how you go with this one!
This patch also fixes two related issues I've found with OgImageSecureUrl (not sure if this is going beyond the scope of this issue - I can open a new one if so. The code to fix this is in the same block so I thought to include it in this)
1. Paths for OgImageSecureUrl containing http:// should be converted to https:// but weren't
2. OgImageSecureUrl's attributes had its image property set to False, and so would not be processed as the regular OgImage tag. This has been changed to True.
Comment #30
mikeyk commented@juliencarnot - As for your bonus question, as far as I know the [node:field_image:1] token isn't provided in core or the Token module - but is in the Field Tokens module. If you install that you should be able to do what you want by using the token [node:field_image-formatted:1] (note the -formatted).
Comment #31
juliencarnot commentedTested and approved, the absolute URL is shown! Not using OgImageSecureUrl as all my site is in https, so I'll let somebody else review that part! Thanks for the patches and for your advice regarding Field Tokens, I knew I was missing something!
Comment #32
stevenpatzAny idea on when a new release can happen? #22 fixes an issue I was having with image urls. Applied the patch and all looks good.
Comment #33
sushichris commented@DamienMcKenna: https://modelsushi.com/basic-page/sample If you scrape that link you would see the */ /*-->*/ Product Addons SEO (code in the content description section (body)). It was that the patch I had applied previous, #16 I believe. I reverted back to the original and this is the result
<style type="text/css"> <!--/*--><![CDATA[/* ><!--*/ <!--/*--><![CDATA[/* ><!--*/ #header { background-color:#555555; color:white; text-align:center; padding:5px; } #nav { line-height:30px; background-color:#eeeeee; height:300px; width:100px; float:left; padding:5px; } #section { width:350px; float:left; padding:10px; } #footer { background-color:#555555; color:white; clear:both; text-align:center; padding:5px; } /*--><!]]]]><![CDATA[>*/ /*--><!]]>*/ </style><div id="header"> <h1>Product</h1> </div> <div id="nav">Addons<br /> SEO</div>I may be applying the patches wrong as I am new to patching I applied patch using this method:
curl https://www.drupal.org/files/issues/meta_tags_don_t_filter-2631408-29.patch
Also I would like to note that I reverted by changing the name of the current MetatagManager.php to MetatagManager.php.current and changed the name of the MetatagManager.php.original back to MetatagManager.php
If I am doing something wrong I apologize, I did try this as well but I get errors:
curl https://www.drupal.org/files/issues/meta_tags_don_t_filter-2631408-29.patch | patch -p1
Might this have something to do with the extra html tags drupal always seems to sneak into my code? (right after typing this I unchecked: Correct faulty and chopped off HTML) And the previous code now looks like this:
<style type="text/css">#header { background-color:#555555; color:white; text-align:center; padding:5px; } #nav { line-height:30px; background-color:#eeeeee; height:300px; width:100px; float:left; padding:5px; } #section { width:350px; float:left; padding:10px; } #footer { background-color:#555555; color:white; clear:both; text-align:center; padding:5px; } </style> <div id="header"> <h1>Product</h1> </div> <div id="nav">Addons<br /> SEOComment #34
damienmckennaThis just tidies up the code & comments a little, no actual logic changes.
Comment #35
damienmckennaOh wait, there was one logic change - I removed the special handling for the og:image:secure_url tag because it didn't belong there, there needs to be a new 'secure' attribute that is tag-agnostic.
Comment #36
damienmckennaThe secure URLs thing will be handled in #2684479: Support for 'secure' URLs in meta tags (D7 feature port).
Comment #38
damienmckennaCommitted. Thanks all!
Comment #39
sushichris commentedAwesome, Thanks!
Comment #40
kplanz commentedHey there,
first of all: great work guys, the metatag module is really a must-have and now even available for D8 :)
We use it on a Drupal 8 blog which lives in a subdirectory, e.g. www.site.com/blog/ and the extracted image URLs are wrong in that case.
Currently:
www.site.com/blog/blog/sites/default/files/2016-03/team.jpgCorrect would be:
www.site.com/blog/sites/default/files/2016-03/team.jpgThe problem seems to be the use of $base_url because both the base url AND the image path contain the subdirectory (
/blog).I suggest to use $base_root in this case since the relative image path starts with a "/" and thus references
www.site.com/and notwww.site.com/blog/.Patch is attached.
(Is it OK to re-open this issue or should I have created a new one?)
Comment #41
damienmckenna@kplanz: Oh bummer, thanks for reporting it. Please open a new issue for this issue? Thanks.
Comment #42
kplanz commentedDone: #2689543: Wrong image URL when Drupal lives in subdirectory