First off, I saw similar posts already, but they weren't exactly what I am asking.
I used the Facebook Dev to create a like button for my website, stuck the code in and the the button showed up. The only issue is that it likes the wrong url when I click the button.
I'm pretty sure the issue is that I have it set to redirect automatically from mydomain.com to the most recent post. I think this is gumming up the works with the like button and causing it to like mydomain.com/mostrecentpost instead of simply liking mydomain.com.
Is there a way to correct this issue without having to get rid of the redirect (because that isn't an option)?
Sorry if that was a little wordy, wanted to make sure I explained the issue fully.
Is there a way to correct this issue without having to get rid of the redirect (because that isn't an option)?
Either don’t redirect in those cases where the user agent header of the request points to it being Facebook’s scraper;
or set the canonical URL of http://example.com/mostrecentpost to just http://example.com/ using the appropriate Open Graph meta tag. (Although that would mean you would not be able to like a single post any more, because all of your posts would just point to your base domain as the “real” website; so the first is probably the better option.)
Related
One of the purposes of og:url -- I thought -- was that it was a way you could make sure sessions variables, or any other personal information that might find its way into a URL, would not be passed along by sharing in places like Facebook. According to the best practices on Facebook's developer pages: "URL
A URL with no session id or extraneous parameters. All shares on Facebook will use this as the identifying URL for this article."
(under good examples: developers.facebook.com/docs/sharing/best-practices)
This does NOT appear to be working, and I am puzzled as to either -- how I misunderstood, and/or what I have wrong in my code. Here's an example:
https://vault.sierraclub.org/fb/test.html?name=adrian
When I drop things into the debugger, it seems to be working fine...
https://developers.facebook.com/tools/debug/sharing/?q=https%3A%2F%2Fvault.sierraclub.org%2Ffb%2Ftest.html%3Fname%3Dadrian
og:url reads as expected (without name=adrian).
But if I share this on facebook -- and then click the link. The URL goes to the one with name=adrian in it, not the og:url.
Am I doing something incorrectly here, or have I misunderstood? If the latter, how does one keep things like sessions variables out of shares?
Thanks for any insight.
UPDATE
Facebook replied to a bug report on this, and I learned that I indeed was reading the documentation incorrectly
developers.facebook.com/bugs/178234669405574/
The question then remains -- is there any other method to keeping sessions variables/authentication tokens out of shares?
I have an aggregator site in wordpress, and was thinking about a way to show new post for visitors. I don't use log-ins, so would be from plain visits. My thougth was to divide new post by a line below. Not sure how though.
Any suggestion on where to start? My site: http://www.skatevids.me
this is a fairly generic/difficult to answer question for Stack Exchange. Not entirely sure if it's a good match to be honest, but maybe I can help you formulate one that would be.
So load your webpage and then right click in your browser. If you're using Chrome or Firefox, you'll want to click "Inspect Element." I'm not sure what the command is for other browsers, but hopefully you have access to Chrome or Firefox.
Okay, so once you inspect the element, you'll see what's called the DOM (Document Object Model. And if you click through that a bit, you'll see something like
I'd look into CSS child/sibling selectors (eg http://css-tricks.com/child-and-sibling-selectors/) and see if maybe there's way to highlight the most recent, say, 6 posts. It's something to look into as a possibility, any way, and if it looks promising, you might want to give it a shot and come back with a question specific to that. As it is, there's about 50+ ways I could think of accomplishing this, some more realistic than others, depending on how your theme works. I think you'll have a lot more like getting an answer that works for your website if you try to think through some ways of doing it and check back with those
If you do that, some added info on how your theme works would be useful.... is that a widgetized home page? Are you telling your theme to display those posts there, instead of something else? If so, how are you specifying that? What is the meaning of "New post"? Less than XYZ days old? Most recent ABC posts? Something else?
As of today, you can use the Highlight New Posts plugin for this.
It sets a cookie with the time of the visitor's last visit. If it returns, it'll show a "NEW" label after the title of posts that have been published after their last visit.
I have a website based on wordpress and newly google shows extended results of this webpage (hope you know what i mean by extended results)
So there are the pages, which should be there like "contact", "services" or "info" but theres also one which shouldn't appear in the results: "domain.xx/xmlrpc.php?rsd". it shows in the results as "wordpress http://..." which is pretty ugly.
i tried to "downgrade" (sorry, dont know the exact translation for this in english) the page in google webmastertools about one week ago, but theres no effect. Actually since then it appears as the second link in the results. before it was the last one..
any hints to get rid of this?
First (and recommended way): In Google Webmaster Tools go to Configuration->Sitelinks and demote your xmlrpc URL.
Second way: Go to Optimization and Remove URL and enter your xmlrpc.php URL there. It will take some time before the URL is removed.
Third way: Block Google to access xmlrpc URL with the help of robots.txt file.
Fourth way: Block Google to access xmlrpc URL with the help of .htaccess file.
I wonder if there is a way to make the Facebook crawler ignore the canonical link on a page.
I have a situation where the canonical link points to a different URL than the one that you are actually on.
This results in that the og:image, og:url etc. that is dynamically added to the page is ignored and the information on the facebook page is completely wrong.
I have searched for an answers to this but come up short...
If I have understood your comments correctly, you may be going about this the wrong way. If you want your like button to like a url different to the page you are on, just change the href of the like button. Make sure the page at that href has the correct og tags and you shouldn't have a problem.
If this isn't what you mean, can you try to explain what you are trying to achieve, rather than what you think the problem is, as you might just be approaching it from the wrong angle.
I just ran across a problem that took a little while to figure out and wanted to document it for someone else that may have the same issue.
Our site can be used in different countries, so we have URLs that look like this:
http://www.example.com/
http://www.example.com/CA
http://www.example.com/UK
The first automatically goes to the US. We use a cookie to remember their country so that when they come back to the site later (http://www.example.com), we redirect them to (http://www.example.com/CA)
When someone wants to go back to the US version, they click a link like this (http://www.example.com/US) which sets their cookie and redirects back to the main site because the US one normally doesn't have the country code.
In doing these redirects, we would do the following if they clicked the /US link:
SetCookie("US");
Response.RedirectPermanent("/");
The problem came when they switched to Canada (which worked) and then tried to switch back to the US. Answer below.
The problem came with Google Chrome. Because we used a permanent redirect, it would not even send http://www.example.com/US to the browser. It said basically:
Oh, last time they told me /US is a
permanent redirect to / so I'll just
request / without sending /US to the
browser.
So the fix was to use Response.Redirect (302) instead of Response.RedirectPermanent (301).