Joe Westcott

James, thanks very much — that URL is indeed handy.

Is there anything else I need to do?

I followed your instructions, setting up categories for posts and pages, and re-synced the site, but there are still no related posts on the test site pages.

Do you have some demo content that I could copy to make this work?

Here’s a quick runthrough of what I’ve tried so far, if it helps:
https://www.screencast.com/t/ZqxDfohRfB (2m 52s)

Thank you,
Joe

Okay, as you suggested, I’ve gone ahead and created a new test page that does _not_ use the jetpack-related-posts shortcode:

https://jetpack.joewestcott.com/jetpack-related-posts/

Then I manually re-indexed at wordpress.com, and checked the source of this page.

The good news is that I see jetpack-related HTML on the page, but the bad news is that this page is not showing any related posts either. Here’s a screenshot of what I see in the source:

https://www.dropbox.com/s/rv6wndvh0j8rtxu/jetpack-jrp-code-in-source-but-no-related-posts.png?dl=0

There’s a div with the expected h3 header, but no posts.

Hi Gemma, thanks for the reply. For more than 24 hours, the “not supported” error was showing in the source HTML, but now it’s a bit different.

Now, I’m seeing some related posts HTML in there, although it’s hidden and there’s no content.

Please refer to this screenshot:
https://www.dropbox.com/s/322kq6ru9lndbc5/jp-related-posts-no-content-now.png?dl=0

What do I need to do for the test site to show related posts on this page? When I created this page, I used several keywords that appear on posts on the test site, to try and generate matches.

Thanks for any help,
Joe

Hi @mazedulislamkhan, this solution doesn’t quite work.

Perhaps Googlebot changed the way that they treat Disallow: /wp-admin/, and now _maybe_ a disallow will override an allow that follows it within the same path?

I have the same exact problem, and when I click “Mark as Fixed,” the problem returns automatically.

Here is the robots.txt:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://www.guitarmusictheory.com/sitemap.xml.gz

I’ve tried this with Yoast, without Yoast, with a default WordPress theme, and with a custom theme.

Regardless, here is the 400 error in Google Search Console:

URL:
https://www.guitarmusictheory.com/wp-admin/admin-ajax.php
Googlebot couldn’t access this page because the server didn’t understand the syntax of Googlebot’s request.

• This reply was modified 6 years, 7 months ago by Joe Westcott.

Thanks, Peter. This is a one-page site, which is why there’s only a homepage.

Appreciate the advice!

Hi @cognac-expert, yes, the inline form for WooCommerce will automatically pass billing address details to Stripe, once you’re running the code to enable wc_stripe_checkout_require_billing_address .

The address fields will be slightly hidden in Stripe, but you can find them in two places on the Stripe website:

1. The Events section of Stripe.

2. Although Stripe doesn’t show the addresses on the Payments page, it does show the billing addresses if you export your payments — click the Export button on the Payments page.

Hi Spencer, if I use my own API keys it works!

If I use the default API keys, it simply doesn’t show the content, only icons. I didn’t realize I had to use my own keys because the plugin wasn’t showing an error message.

Thanks for your help with this!

Joe

• This reply was modified 7 years, 4 months ago by Joe Westcott. Reason: marking resolved

https://staging1.joewestcott.com/

Hey Justin, I’m able to recreate the problem on a completley different server and hosting company, using a stock WordPress theme — Twenty Sixteen — and no other plugins other than Feed Them Social.

The icons load but none of the content does. See link above.

Sure, here you go!

[fts_twitter twitter_name=childcareworks tweets_count=2 cover_photo=no stats_bar=no show_retweets=no show_replies=no]

Hi Justin! Sorry, I was completely mistaken about what the problem is, due to a miscommunication.

The actual problem is that the tweets don’t load at all, whether we use our access tokens or leave them blank.

Here’s the problem, on our test server:
https://childcareworks.staging.wpengine.com/test-fts-twitter/

Hey @acekyd, the fix is so, so close … it removes all SSL errors _except_ when there’s a post without an image. Then the plugin loads this image over a non-https connection:

View post on imgur.com

So the fix might be to load that image like so:

//i.imgur.com/p4juyuT.png

• This reply was modified 7 years, 8 months ago by Joe Westcott.

Same here. It looks like the plugin pulls images via this URL:

https://cdn-images-1.medium.com/

The fix could be to pull images from this URL:

//cdn-images-1.medium.com/

(Just “//” instead of “https://”)

Hey @acekyd, you’re awesome — this improvement is great!

Completely optional — may I suggest that you change “width” to “max-width” in the default CSS, to make sure that smaller-width images have the correct dimensions by default?

(I can fix this in my own custom CSS, but this might help non-developers.)

Here’s the current problem — this is what smaller-width images look like with the current CSS:
https://www.dropbox.com/s/4etork6kt5c7msg/display_medium_posts-image-width-100-percent-issue.png?dl=0

And here’s the fix — what smaller-width images look like with max-width:
https://www.dropbox.com/s/6kneda618ltlv0b/display_medium_posts-image-width-100-percent-issue-fixed-max-width.png?dl=0

In other words, change this CSS:

#display-medium-owl-demo img {
    width: 100%;

to this:

#display-medium-owl-demo img {
    max-width: 100%;

…

Anyway, I’m all set for now. Just a suggestion that might help other people who use your plugin.

Thanks again for adding images — it make your plugin so helpful, and YOU ARE AWESOME for adding this feature.

@acekyd, you’re awesome — this improvement is great!

Completely optional — may I suggest that you change “width” to “max-width” in the default CSS, to make sure that smaller-width images have the correct dimensions by default?

(I can fix this in my own custom CSS, but this might help non-developers.)

Here’s the current problem — this is what smaller-width images look like with the current CSS:
https://www.dropbox.com/s/4etork6kt5c7msg/display_medium_posts-image-width-100-percent-issue.png?dl=0

And here’s the fix — what smaller-width images look like with max-width:
https://www.dropbox.com/s/6kneda618ltlv0b/display_medium_posts-image-width-100-percent-issue-fixed-max-width.png?dl=0

In other words, change this CSS:

#display-medium-owl-demo img {
    width: 100%;

to this:

#display-medium-owl-demo img {
    max-width: 100%;

…

Anyway, I’m all set for now. Just a suggestion that might help other people who use your plugin.

Thanks again for adding images — it make your plugin so helpful, and YOU ARE AWESOME for adding this feature.

• This reply was modified 7 years, 9 months ago by Joe Westcott.
• This reply was modified 7 years, 9 months ago by Joe Westcott. Reason: embedded image #1
• This reply was modified 7 years, 9 months ago by Joe Westcott. Reason: fixed post after breaking it with an image that wasn't really an image... oops

Hi @acekyd, your bug fix worked, thank you! I no longer see this problem at the test URL.