cuenca

@pehaa,

How can you say that a solution was found and this is resolved?

1. Expand on click still does not expand on click for posts that were originally published with expand on click.
2. Expand on click is no longer an option in the block editor for adding new photos.

The current state is that expand on click still no longer works and it’s no longer available in the editor. Will there be a fix forthcoming?

Thank you.

@happyaxident, Thank you for your response.

I have many older posts that have Jetpack tiled galleries that are displayed using the carousel upon clicking on any of the gallery images. I haven’t been doing these tiled galleries for quite a while now, but have recently been pleased to use “expand on click” for single images appearing in posts.

Following your instructions, I disabled the Jetpack image gallery carousel option.

Results:

1. Jetpack tiled/carousel galleries lost the carousel display, creating an unwanted user experience.
2. Clicking on an existing “expand on click” image that was set up that way when the “expand on click” option was still present in the block editor did nothing. The image still did not expand.
3. Using the block editor to attempt to add “expand on click” to a single image that did not already have it was not possible because the “expand on click” option still was not available.

Viewing the GitHub discussion, I don’t see a solution to this yet. I still need to have the Jetpack tiled galleries to work with carousel and “expand on click” images to expand on click.

Thanks for the Gutenberg clarification. My understanding was that when the Gutenberg functionality was officially added to WordPress core, it was called Block Editor, not Gutenberg, and Gutenberg from then on was referring to the Gutenberg plugin. That would seem to be a less confusing way to refer to these things. Now I know that’s not the case.

Anyway, I still hope for this carousel vs “expand on click” issue to be resolved soon. Thank you!

NOTE: I posted the following in another thread on this same topic. Also, to clarify, it cannot be caused by Gutenberg because I do not have Gutenberg installed. The Github Issue linked above categorizes this as a Gutenberg problem as well as one of image alignment. Again, I don’t have Gutenberg and have no alignment set for the images but I do have the problem.

The “expand on click” option was working for me as recently as early April. Yesterday I discovered that it is not working anymore. In addition, the option has disappeared from the block editor.

The behavior that I now experience is the inability to specify the “expand on click” option for any newly-added images because it has been removed from the block editor. And when clicking on an existing image that had “expand on click” enabled, nothing happens. The image does not expand. Previously, this was working.

Contrary to information appearing above and in other posts on this topic, I am experiencing this problem and:

• I do not have the Gutenberg plugin installed.
• I do not have “expand on click” images linked to anything.
• I do not have any alignment specified for the “expand on click” images.

I do have Jetpack. I am not using the Twenty Twenty-Four theme.

I see that others have been experiencing the problem much longer than I have. I would like to see this addressed and resolved. It seems like it’s more than simply a bug given that it’s been removed as an option on the block editor. I prefer using “expand on click” rather than linking to the image’s attachment page.

The “expand on click” option was working for me as recently as early April. Yesterday I discovered that it is not working anymore. In addition, the option has disappeared from the block editor.

The behavior that I now experience is the inability to specify the “expand on click” option for any newly-added images because it has been removed from the block editor. And when clicking on an existing image that had “expand on click” enabled, nothing happens. The image does not expand. Previously, this was working.

Contrary to information appearing above and in other posts on this topic, I am experiencing this problem and:

• I do not have the Gutenberg plugin installed.
• I do not have “expand on click” images linked to anything.
• I do not have any alignment specified for the “expand on click” images.

I do have Jetpack. I am not using the Twenty Twenty-Four theme.

I see that others have been experiencing the problem much longer than I have. I would like to see this addressed and resolved. It seems like it’s more than simply a bug given that it’s been removed as an option on the block editor. I prefer using “expand on click” rather than linking to the image’s attachment page.

Thanks for the suggestion, @joecoyle. I don’t use the Theme File Editor because I edit the header.php outside of WordPress using a text editor. The PHP snippet has been successfully added to my header.php, which is in a child theme. That PHP snippet picks up the schema data from the custom field associated with the individual post. What I’m experiencing is that I can’t get the schema data into the custom field because WordPress will not save it there anymore. The other interesting phenomenon is that for the older posts that already have schema data in a custom field, the comment line is present in the head section where expected, but the rest of the data, the actual JSON-LD script for schema markup has been separated from the comment line and placed in the body section.

I wouldn’t want to hardcode the JSON-LD schema markup into the header.php file because the data is different for each post and page.

I’m sorry to learn that you lost the contents of your header.php file and had to restore it from a backup. I’m thankful that you had a backup. If you need to make changes to your header.php or other theme files, I strongly recommend that you create a child theme and also stay away from the Theme File Editor.

Thanks again for all your willingness to help.

Thanks, @joecoyle,

1. These pages and posts are fine for now. I guess if any troubles arise, I’ll change to the new Custom HTML block method.
2. The place I’ve always used for adding new custom fields and data is outside of the block editor. It is just below the bottom of the block editor panel and is hidden by default. To enable it, go to the vertical three dots in the upper right corner, then choose “preferences” and then “panels”. Custom fields should show at the bottom of the list of panels. The custom fields editor will no longer save the JSON-LD schema markup data for me. It will still save other data for other custom fields.
3. I don’t think the block editor can put anything in the head section. The header.php file can be edited outside of WordPress to add things to the header, like the PHP snippet in my original post does. It’s pulling the script in at that position. But somehow only the comment line (first line) shows in the head section. The following lines, the JSON-LD script, show up way down in the body. It’s an unexpected outcome!

I appreciate your interest and assistance. Thanks again.

Hello, @joecoyle,

Thanks for your kind assistance. You led me to learn that the JSON-LD schema markup does not have to be in a custom field now. I tried adding it in a Custom HTML block as you mentioned. It works fine, validated by the Google Rich Results Test tool.

Adding the JSON-LD schema markup via a Custom HTML block puts the markup into the body of the post rather than the head section. Today I learned that Google now says it’s okay to have it in either the head or the body. When I first started adding schema markup many years ago, all of the instructions I found at that time recommended adding it in a custom field and adding the PHP snippet to header.php in the head section to pull the markup into the head of the HTML page.

Using the Custom HTML block for the JSON-LD markup data gives me a solution to use from now going forward. I still have a few questions for anyone who can answer.

1. Will it be okay to leave all prior posts unchanged which used the method with custom fields as described in my original post above?
   
   Even those posts that already have the schema markup in a custom field that the PHP snippet is supposed to pull into the head section exhibit an unexpected behavior. That schema markup now ends up in the body, not the head. Only the comment line (first line) of the JSON-LD markup appears in the head section. The actual script with the schema data is being put into the body. I wonder how that’s happening.
2. Why does the block editor no longer save JSON-LD schema markup data?
   
   While it appears that I no longer need this capability, it’s puzzling as to why it quit working. I can even copy the JSON-LD data saved in a custom field back in January and paste it into a new custom field in a new post and it will NOT be saved. When new data is saved in the value field, it kind of flashes yellow while saving. However, for the JSON-LD schema markup, it will no longer flash yellow and will not save anything.
3. Why does the schema markup data imported into the head section of the document via the PHP snippet (see original post above) get moved into the body section? Only the comment line appears in the head. All data from the <script> tag to the </script> tag is found in the body when viewing the source of the rendered page.

Thanks! And thanks again to @joecoyle for his kind assistance.

Thanks, Jeremy, @jeherve . I’m glad to know it’s not a problem being caused from my side.

I would vote in favor of the change. I’d be pleased to see it show 1K increments from 1000 on up and not forever remain at 10K+ once that number is reached.

Yes, the counts returned after some time away from the keyboard here. That was good to see.

Thanks again for all your help!

Okay, hosting tech support tweaked .htaccess somehow and eliminated the Facebook 404 reported from the sharing debugger.

Still unresolved is the strange 10K+ count showing for the home page on the Jetpack button while the debugger reports 32737 shares.

Suddenly just now, the share counts disappeared from the Jetpack button on all pages and posts. I wonder if it could be rate-limiting by FB. I had that happen to me once before during this transition. I’ll take a break for a while and see if they return later.

With special thanks to @jeherve and @theguitarlesson, I’ve met with promising success on the https conversion and mostly preserving the Facebook sharing counts. My hosting company tech support team has been through quite a workout on getting the .htaccess files working to achieve all of this. That was not nearly as simple as it would have seemed. I often got stuck when it just would not work for me and I had to call on them for assistance. At this stage, I believe that most everything is in place, but some things are not working quite right just yet.

One is that my home page had a Facebook share count of over 32K. The Jetpack button, however, reports 10K+ now. How could this be? The Facebook sharing debugger reports:
Fetched URL https://beards.org/
Canonical URL https://www.beards.org/
32737 likes, shares and comments (More Info)

Can this be fixed?

Another problem is that many pages are not showing any share numbers on the Jetpack button. The Facebook sharing debugger can fetch the http version all right. But the Facebook sharing debugger is reporting a 404 on the https version, even though the page is there. Here is one example:
https://developers.facebook.com/tools/debug/sharing/?q=https%3A%2F%2Fwww.beards.org%2Ftodays-beard-william-20170314%2F

In Google Webmaster Tools Search Console, I tried a “fetch as Google”. I was thankful to see that Google does not report a 404. But something is causing Facebook to report a 404. I’ve done some looking around and see that .htaccess might be suspected.

So far, it appears that URLs getting this Facebook 404 are the https versions of URLs that are only changing from http to https (these are not in the category of those being redirected from a subdomain as I described earlier in the thread)In this case the .htaccess is set up to:
— redirect to the “www.” form of the URL if “www.” is omitted
— redirect to http from https
— exempt Facebook crawler from the http-to-https redirect

With the 404 happening for Facebook, I can’t tell what’s going on here. I’ve got the tech support team looking at it. But if there’s anything that might be an obvious cause, please let me know. Thanks!

Great! Thanks again!

@jeherve ,

Wow, Jeremy! Thanks! I will get busy working with your plugin now.

I recently upgraded to the Jetpack professional plan and have the Jetpack SEO tools activated. That will not interfere with your plugin, correct?

Thanks again for the great service!

Jeremy, @jeherve ,

After all this time, I’ve just recently tried to implement the Facebook share counts solution for switching from http to https. My case has some extra complications because I’m also migrating 202 posts from one WordPress installation into another at the same time as switching from http to https.

At this time, I’m stalling out on how to handle this requirement from https://developers.facebook.com/docs/sharing/webmasters/crawler#updating :
—-
2. Use the old page as the canonical URL for the new page

Add this tag to the HTML of the new URL:

<meta property=”og:url” content=”https://example.com/old-url&#8221; />

This tells our crawler that the canonical URL is at the old location, and the crawler will use it to generate the number of Likes on the page. New likes at either location will aggregate in both places.
—-

You earlier suggested using a filter to modify og:url in the Jetpack Open Graph Meta Tags. From what I see, that will only provide for a generic override that will apply to all posts/pages. I think I would need to custom set the og:url for individual posts/pages, depending on the case. I will have three cases:

1. migrated posts that have URL changes in addition to the https change
EXAMPLE:
OLD URL: https://blog.domain.com/yyyy/mm/dd/post slug/
NEW URL: https://www.domain.com/post slug/
(I have 202 of these.)

2. existing posts/pages that are only changing from http to https
EXAMPLE:
OLD URL: https://www.domain.com/post slug/
NEW URL: https://www.domain.com/post slug/

3. new posts created after the https migration that will not need a modified og:url tag

It seems to me that the only way to handle this would be to have the capability to specify the needed og:url tag for each affected post/page in the editor. I can’t find any plugin that will provide this functionality. Is the only solution for me to create my own plugin for this? I’ve never created a plugin before and there will be a learning curve for me. What’s your recommended solution?

Thanks!

I’m experiencing the same problem as reported by the original poster. I tried it out on a XAMPP test setup of WordPress before attempting it on my real site.

The outcome is that the media is transferred to the media uploads folders on the XAMPP WordPress, however, the posts still link back to the media folders on the old site. Only solution I see is to go through every post and modify the URL for every image. Was it wrong to expect the importer to take care of this?

Thanks again, @theguitarlesson . Your guide is proving to be very useful!