Since yesterday when Pinterest updated its website, my Pinterest 'Pin it' buttons stopped functioning properly, i.e. the spinning wheel goes forever in the popup window.
My code - which used to work fine - is:
<a data-pin-config="beside" href="//pinterest.com/pin/create/button/?url=<?=urlencode($url)?>&media=<?=urlencode($image_url) ?>&description=The picture I just pinned!" data-pin-do="buttonPin" >
<img src="//assets.pinterest.com/images/pidgets/pin_it_button.png" />
</a>
I also include the Pinterest js just before the </body> closing tag.
What is interesting is that when I go on Pinterest's website and try to Add Pin by URL, I get:
"Whoops! Invalid URL"
My $url refers to php pages which pass several parameters, i.e.
http://www.mywebsite.com/img.php?img_id=photo (999).jpg&album=...&page=...
Update #1: I noticed that when the posted URL does not contain any parentheses, there is no problem posting on Pinterest directly or via the buttons. Although the URLs are all urlencoded in php, i.e. the ( and ) are encoded to %28 and %29 respectively, which should be taking care of the parentheses, it does not seem to work. The browser still shows the parentheses although I realize that it is interpreting the url encoded %28 and %29 codes.
Update #2: Received reply from Pinterest saying
"Sometimes we see this behavior if a website is blocking Amazon IPs.
Make sure you're not blocking Amazon IPs or whitelist our user agent:
Pinterest/0.1 +http://pinterest.com/
Unfortunately, we don't have a dedicated group of IPs that you could whitelist because our IPs change over time."
Following Pinterest's reply, I did my research and came up with the following relevant links:
http://wordpress.org/support/topic/note-when-entering-user-agent-whitelist
"Pinterest have to be whitelisted as a referrer or agent so that it will see the image - if not it will just see the redirect to a HTML page (thus "not a valid image").
Try to put pinterest and pinterest.com on your user agent whitelist"
Questions:
Has this worked for anyone?
What's the best way to modify .htaccess or robots.txt to accomplish that?
I am facing the same issue with Tumblr as well. I have verified that w/o the parentheses, the share it button works fine. If nothing else works, should I remove all the parentheses from the URIs?
Problem solved!
It was not the parentheses that were causing the failure to pin (or share on Tumblr), but the spaces in the URL (in my case the space before the parenthesis). Although the spaces were URL encoded (+), Pinterest was viewing it as an invalid URL.
I removed all spaces from the picture file names, which means also from the URL since the URL passes as a parameter the picture filename.
This fixed the issues for both the Pinterest and Tumblr buttons.
Related
I have set-up alertmanager and configured it using the official documentation.
The set-up is made to send alerts to Slack, Email and Telegram via the alertmanager.
I have triggered some alerts to see if it is working fine. For Slack and Emails, the generatorURL (A backlink which identifies the causing entity of the alert.1) is clickable and when clicked takes back to the Grafana Explore section which is the expected behaviour. However for Telegram, the generatorURL link is broken (The link is half clickable). The alertmanager uses default template to send the alerts to Telegram.
After some research, I found out that it is because of the url-encoding (i.e. The quotes, square brackets, etc. are not encoded). I don't know how to encode it manually. However I have tried two possible solutions:
Used parseMode as HTML and using anchor tag for the generatorURL - Didn't work.
Used reReplaceAll to replace the quotes, square brackets, etc. into url encoded form from this GitHub Discussion - Didn't work.
I tried the solution provided here, but I didn't get the source URL i.e. It was blank.
What did I achieve: It didn't generate the URL. I mean the telegram message was blank.
What was expected: A fully clickable source URL.
Screenshots have been attached.
Implemented GitHub solution for GeneratorURL
Result
Any suggestions on what can be done to resolve this issue?
This problem exists for all pages on this site. The meta tags appear correct but whether you use the share link on the site, or try to share direct on FB, the image, title and description are not used.
There must be a legitimate issue as the Sharing Debugger also shows an empty/plain sharing dialog. But the Facebook share debugger isn’t given me any helpful info. It sometimes shows a 302, which I don’t understand as there is no redirect on the site. Refreshing the scrape sometimes shows an error Unknown Image Error, which also doesn’t seem to be a legitimate issue.
Almost always the Facebook share debugger shows a 302 the first time and then follows with other unhelpful errors.
Maybe a DNS issue, weird that it would be site wide.
Example Links:
[http://pikespeakharleyownersgroup.com/group-riding-pphog-405/][1]
[http://pikespeakharleyownersgroup.com/tell-tires-toast/][2]
[http://pikespeakharleyownersgroup.com/30th-annual-high-country-toy-run/][1]
Any and all help is very appreciated.
Try debugging your page URL on below link:
https://developers.facebook.com/tools/debug/
Once you scan your URL, on the link I provided, you will see "Warnings That Should Be Fixed" section. Try resolving warnings mentioned in that section.
Hope this will help you!
A client had sent out a mass email using Constant Contact and all the links contained the unicode text character "Heavy Black Heart", all the available formats can be seen here http://www.fileformat.info/info/unicode/char/2764/index.htm:
So the Constant Contact Mail Out has links that all similar to the following
http://www.wordpress.com/events/❤-heart-card-event-at-kendra-scott
They link to a 404 as they are parsed by Constant Contacts Engine and when clicked from the newsletter go through Constant Contact and become the following:
http://www.wordpress/event/❤-heart-card-event-christofle-2
So...
Because we cannot un-send the newsletter and Constant Contact is well a Constant, I'm stuck with trying to convert the Unicode heart from the unicode heart, back to the unicode heart after being parsed by Constant Contact.
Things I've Tried:
1.Changing the slug of the the event/post in wordpress, wordpress will not recognize the html ❤ and just ignores it upon saving.
2.Changing the slug link of the post/event to a%c2%9d%c2%a4 (the hex version escaped) for the heart, no good, it still comes out using the ❤ in and sending to a 404;
3.Trying to use the .htaccess mode_rewrites file to grab the html version of the url and redirect it to the Unicode hex version (really thought this would do it) nope, it still loads and directs to the good ol 404.
4.Using the strange already parsed resulting characters ( the A, big O, little O) in the slug, this one actually took and altered the slugs but still did not link to the url from the newsletter.
So now i'm just spinning wheels and still need the newsletter to link to the proper post/event page. Any Ideas would be greatly appreciated.
Just a note: My client thought the heart inside of a url would be cool and sent the letter by copying and pasting directly into the Constant Contact form. I'm assuming that CC takes the link and parses it using it's own system and then rebuilding the link for tracking so as far as I can tell, linking with a Unicode Text Character is a big "Do Not Try" no-one informed them of.
If the newsletter had not already been sent this would be a snap to fix but since it's already out, the only thing I can do is try and find a way to direct the links to the right wordpress posts/events.
Your biggest problem is the fact that anything after (and including) the hash is not sent to the server. So, in actual fact, your server sees the following URL request:
http://www.your-domain.com/event/&
So if you're trying to do a htaccess redirect, something like this should work:
Redirect /event/& /event/❤-heart-card-event-christofle-2
Or, if you can, I'd recommend removing the heart from the permalink and instead doing this:
Redirect /event/& /event/heart-card-event-christofle-2
I have an ajaxified website, and I want all my content to be crawlable. I have a photo gallery, which only loads the photo using ajax, without refreshing the whole page. My root URL is this:
http://mysite/photos
and whenever a photo thumbnail is clicked, it displays the photo, and hash becomes #!/photo/photoid/phototitle, or when you are searching for a criteria, it becomes #!/photos/f-number/1.8/iso/640 e.g. for searching for photos with f/1.8 at ISO 640 (and more criteria can be appended this way). When a user opens up a URL like http://mysite/photos/#!/photos/f-number/1.8/iso/640 the landing page, using a javascript, will redirect the user to http://mysite/photos/f-number/1.8/iso/640 (without the hashbang), and again, there, the page loads http://mysite/Dynamic/PhotoThumbnails.aspx?f-number=1.8&iso=640 using ajax (yes, javascript looks at the location path and parses it according to that format). For the first case (link of a photo itself rather than a search), using again, only javascript, the page loads the photo itself (along with some extra tables showing technical info about photo) from the url http://mysite/Dynamic/RenderPhoto.aspx?ID=123 (where 123 the ID of the photo).
Given this information, my problem is simple: I am planning to (on my masterpage load event) redirect all requests with _escaped_fragment_s to the appropriate RenderPhoto or PhotoThumbnails page, by parsing the _escaped_fragment_ at server side. Will that work? My main concerns are;
Will Google follow the HTTP redirect? (301 or 302)
Will I get into any trouble (such as being removed from index) as I am not showing the exact same content to Google? (a browser will load a side mavigation bar, and all those fancy css styles visually-nice-looking page etc. and then load the real content into a pane at that page, where Google will be getting the "true" content only. My base page, sidebar content thumbnail list page, and photo renderer are COMPLETELY different pages which implement their OWN logic, so I cannot ever merge them)
If there is a risk of being removed due to the reasons above, what are my alternatives (no, I cannot merge the pages, it is NOT an option)? Do you recommend taking regular snapshots of pages and cache them and sending those to Googlebot?
Here is the current BETA of my website (yeah I know about lots of bugs), just to give you the idea how it will work: http://canpoyrazoglu.com/photos
I'm on ASP.NET 4.0, and using jQuery, if it helps.
A new answer to an old question. Yes it will follow it. However you may end up with both the clean and #! URLs. However, check this out (from Google Developer Guides):
Note that if you use a permanent (301) redirect, the url shown in our
search results will typically be the target of the redirect, whereas
if a temporary (302) redirect is used, we'll typically show the #! url
in search results.
This is the Google Developer Guide link:
https://developers.google.com/webmasters/ajax-crawling/docs/faq#redirects
Yes, I'm pretty sure it will follow a redirect. The Facebook open graph debugger does, and this blog post advocates implementing redirects: http://www.yearofmoo.com/2012/11/angularjs-and-seo.html
This is a follow up to my previous question: Problem passing parameters via Iframe in IE. Which was never solved.
Here's the core of it:
I'm trying to execute an HTTP GET from
my website to another website that is
brought in via iframe.
On Firefox, you can see in the source
that the correct url is in the iframe
src along with it's correct
parameters-- and it works.
On IE, you can see in the source that
the correct url is in the iframe src
along with it's correct parameters--
and it doesn't work...
Is there something about IE that
doesn't let you pass parameters
through an iframe in the querystring?
I've tried refreshing the iframe in
IE, I've tried refreshing my page &
the iframe in IE, and I've tried
copying the url and re-pasting it into
the iframe src (forcing it to refresh
as if I just entered it into the
address bar for that iframe window).
Still no luck!
Anyone know why this is happening, or
have any suggestions to try to get
around this?
As for the code, all it's doing is creating
the src from the backend code on page
load and setting the src attribute
from the back end...
//Backend code to set src
mainIframe.Attributes["src"] = srcWeJustCreated;
//Front end iframe code
<iframe id="mainIframe" runat="server" />
I've made a temporary account for you to login and see exactly what I mean. That way you can use firebug or any of your other debugging techniques to figure out why this isn't working rather than having me try to explain what's going on.
EDIT: Changed the account credentials. Please use this one instead
Username: matt
Password: globalbuying
Please follow this link to get to the login page. One you login with the above credentials it will take you to the main backend page. Click the image on the left that says "Vacations", that will take to you a page with the iframe and will execute the Http Get from there.
If you need more details on what's going on in the behind code, etc., let me know and I'll post them.
Thanks,
Matt
After working my way through the HTTP requests with Fiddler2, comparing different browsers, I found that IE makes the request just fine, but fails to set any cookies in the iframe.
I also noticed that if I open that framed page by itself it does work. Even more so, after logging out again there, the iframed version works too. That's because it then already has a session cookie and the iframe no longer needs to set it.
It turns out that this is a known security restriction: IE blocks cookies in iframes. But this can be overcome with the use of the Platform for Privacy Preferences (P3P).
Here are a few links that should help you fix the problem. Starting off with another (answered) question on StackOverflow:
Cookie blocked/not saved in IFRAME in Internet Explorer
Privacy in Internet Explorer 6
IE Blocking iFrame Cookies
The example page you provided is working for me in IE8. The iframe is not as tall as in chrome, but it does have the correct page in it.
As an aside, please note that passing logon credentials via the query string is extremely unsecure and open to various exploits.
It seems that the ampersands in the iframe's URL are HTML-encoded (&).
I think that might cause IE to choke on identifying the param names. Does the problem still occur if you use plain ampersands in the URL?
If the encoding on the src attribute is happening implicitly, you might want to consider using a Literal control for testing purposes and set its Text property to the entire iframe tag to avoid any unwanted encoding.