sgclark

I’m seeing the same issue in Twenty Twenty Four. I have numerous image galleries on my site (www.sgclark.com/wallpaper/baseball as an example) that use three columns of images. The tabbed content/interface/presentation is generated via the “Ultimate Blocks” plug in and the ‘vertical tabs’ option within that. I’m using the “Shortcode” block within each tab and the shortcode I am using is similar to below. I also use Enhanced Media Library and Media Categories plug-ins.

[gallery link="file" size="medium" orderby="title" columns="3" media_category="2593"]

When I use my current theme (GeneratePress) it works just fine. When I try to switch themes to Twenty Twenty Four or many other themes, the galleries either present the thumbnail images in only one column or they present the images at full size vs. thumbnails, also in one column.

I have tried removing plugins and most other suggestions with no change. Maybe something to look at.

• This reply was modified 4 months ago by sgclark.

Got it. I understand now. Oh well. Hopefully something will change amongst all these different pieces of the puzzle and one day it will work as intended!

I also host my site at Siteground. I investigated this item further with them and this was the response they provided.

I referenced this link to them which is where they drew the quote/reference noted in their response below. https://www.ads-software.com/support/topic/not-working-on-siteground-servers/

@pfefferle is there any chance that a different folder name or option could be used as suggested below

Thank you for reaching out to us with your concerns. I’d like to clarify that we did not make any modifications to the setup of the .well-known folder within our hosting environment. This folder is specifically used for custom verification purposes related to our Let’s Encrypt integration, and unfortunately, we do not permit the execution of custom code from it. The issue you’re encountering with the plugin has been acknowledged by the developer, Matthias Pfefferle, as noted in his response:

The plugin generates a rewrite rule for .well-known/webfinger and .well-known/nodeinfo , so there is no “physical” folder, it simply rewrites the requests of these endpoints to the index.php file

It appears that the necessity to add these references and rewrite rules to the .well-known folder could be avoided by choosing an alternative folder name, which would ensure compatibility with our hosting platform. Additionally, it has been mentioned in the support thread that the plugin faces similar issues with other hosting providers as well. It would be beneficial for the developers to reconsider their approach and rename the virtual folder “.well-known” to a different name. By doing so, the custom “webfinger” and “nodeinfo” webhooks should function correctly, allowing the Webfinger plugin to operate seamlessly across various web hosting environments.

SiteGround Customer Support

Thanks

Stephen

Following up on this. Any insight onto what is going on with this translation update? Is there somewhere on the doc tree I need to go to remove bad files or something like that?

Argh! Sorry! The most up to date. 6.3.1

There is one plug in that I am using which is throwing a flag in “Site Health” because an XSS item is not updated. However, this Translation item has been nagging me for several months and I have just ignored it until now. So my point is I don’t think this plug in issue is triggering the issue.

Apart from that, there are no Site Health issues that seem relevant.

Yes, I can confirm that those icons are selected correctly across all the pages that have the “Tabbed Layout” content for the different devices. I have checked and double checked that previously across all those pages.

And thanks for verifying that it works correctly on your end. So it is clearly something local to my site/pages.

That’s good to know re your CSS and how you define the size of Tablet display. I’ll look at the different CSS files that are attached to my site. There must be a conflict happening somewhere. Its not a ‘showstopper’ issue or am I having anyone complain, but something I had noticed and was trying to figure out how to resolve it.

Thanks for your help.

• This reply was modified 1 year, 9 months ago by sgclark.

Ooof! My bad. Thanks for responding!

Awesome! Thanks for the update. And I’ll check out Gutenberg as you suggest.

It is neither. It appears to be a native element of WordPress.

https://www.dropbox.com/s/9dspkuiiw3uuszv/Screen%20Shot%202023-02-04%20at%207.39.20%20PM.png?dl=0

OK. Thank you. You can close this out.

• This reply was modified 1 year, 9 months ago by sgclark.

What I’m talking about are the social icons/links in the footer of my site which I believe use the Social Links block as you refer to it as. I clicked the red + icon in WP Dashboard/Page editor and searched “Social”. Where would I go to find out how to add the rel=me attribute to those links? My site uses GeneratePress premium.

What or where are the social icons that are part of the GeneratePress theme?

This is the response I am getting from Siteground:

If something needs to be placed in the mentioned .well-known folder, you can upload the file that it’s trying to find in it, as per the screenshot above. And in case the people from the webfinger-endpoint plugin have any specific suggestions on any server changes that we may apply, do let us know what they are. We’d be happy to test them out.

And I’m slightly puzzled as well. I’m not understanding what exactly is missing or what functionality that SiteGround needs to enable on the server side? What is throwing that error on my WordPress “Site Health” area?

This is the error I am seeing:

WebFinger endpoint is not accessible
Your WebFinger endpoint https://www.sgclark.com/.well-known/webfinger?resource=acct:[email protected] does not return valid JSON for application/jrd+json.

When I go to the URL noted in the error, I get a Siteground generated 404:

https://www.sgclark.com/.well-known/webfinger?resource=acct:[email protected]

Ah…got it. When I do that, then that URL goes to a 404 page, which then takes us back to talking to Siteground. Which ai will do today. Thanks for your help!