zkarj

Thank you, that is very informative.

Thank you!

The basic problem is I was freely able to edit the middle of the page but not the header nor footer (in the same way), when it comes to width. I now have more information on how this works.

Like almost all software, not just open source but particularly open source, documentation documents (and in the case of WordPress, just barely) but it does not teach. The more customisation that can be done by non-developers, the better the documentation needs to become.

Your response has given me a bunch of things to dive into, for which I am appreciative.

I have the same issue. As soon as I upgrade a site to 6.6 then Google Fonts already installed disappear and I can no longer install any. I always get an error “There was an error installing fonts.”

This is not a particularly helpful error so I have no idea how to fix. On one site, the button to enable Google Fonts appeared and I clicked it, but I still get the error when trying to install. On another site, there is no button to enable and I always get the error.

Thanks, they now render fully on the viewed page, however I note they still exhibit the issue when editing the page.

This does at least have an easy workaround and it only affects me. I can just open all the map tabs, resize the window a little to force the render, and continue editing.

The main thing is visitors to my site are now seeing what I intend.

Thanks for that info Patrick! I worked out I last updated the site on… 31 December!

I set the always share and it did succeed in sharing my two posts today. If you have anything else you’d like me to try I’ll happily give it a go, but without the debug working I’m not sure there’s much I can add now.

Apart from wanting to understand why this isn’t working (for your benefit and mine) I’m now tempted to go with the always share option. The site was set up purely to do scheduled Mastodon posts, so it is a good match.

I turned all the plugins off one at a time. With each one off, I edited a post, then ran the database query. Still no change — the flag is not written to the database. (And Jetpack is a pig.)

And yes, I can confirm the response shows the _share_on_mastodon value of 1.

Here’s Safari’s Object Tree view of the full response (because it’s easier to pick out the stuff we’re interested in).

So if the response says it’s recorded, but the database doesn’t have it… that suggests something is blocking the database write?

I tried turning on debug but for some reason it does not appear to work. Which is to say WP doesn’t even write a debug.log file for me. Maybe that’s something peculiar to my host, too.

Next step, I guess, is to try turning off other plugins.

It’s PHP 7.4. Last I checked (which was a while ago, admittedly) WordPress did not play nice with 8.x.

Although, I just ‘goosed’ another post that published earlier today and kept an eye on the response for that.

"meta": {
    "footnotes": "",
    "_share_on_mastodon": "1"
},

"share_on_mastodon": {
    "errors": {
        "invalid_id": [
            "Invalid post ID."
        ]
    },
    "error_data": {
        "invalid_id": {
            "status": 400
        }
    }
},

I.e. the same stuff, and yet that one did share successfully. #shrug

I think I found what you were after, and a bit more that is interesting.

This is what you asked about:

"meta": {
    "footnotes": "",
    "_share_on_mastodon": "1"
},

But then it gets interesting, as further down I see this.

"share_on_mastodon": {
    "errors": {
        "invalid_id": [
            "Invalid post ID."
        ]
    },
    "error_data": {
        "invalid_id": {
            "status": 400
        }
    }
},

So the database approach proved interesting…

Descending order of post ID (and time as it happens). Everything below the red line has published. The top two (Cat and Trouble) just minutes ago. No sign of any SoM meta values. All those below those two have been manually ‘goosed’ to share.

I then edited the post titled “Workhorse” which has yet to reach its publish time. The SoM switched showed, and was on, but re-running the SQL shows it still has no meta values.

I guess it can be deduced that the actual publish workflow is not at fault… it’s not getting the right meta for that to work unless I edit it when already published.

• This reply was modified 1 year, 5 months ago by zkarj. Reason: Clarification

Yes, the posts are publishing on their own, I can see them on the site and in the admin interface they show as published.

I will go look in the database, but I assume that field is reflected in the switch visible in the post editor? I’ve got a couple just about to publish now so will look at those after they go live, as well as some future ones.

I can do the debug thing in a day or two. I was hoping you’d come up with some things to check (and you did) before getting to the “disable all plugins” but I guess that won’t be too cumbersome on this site.

To clarify, the switch does indeed get set on automatically. My original thinking was I had to toggle it off and back on to get the share to happen, but in fact with the switch already (automatically) on, any update to the post triggers the share.

I am using a fairly plain setup and the block editor. I do have the Twentig plugin which adds blocks, and have some host-specific caching.

I also still have Jetpack Social installed, but the “Automatically share your posts” switch has been off since before these posts were created.

Oh, and I also have a VERY rudimentary plugin I created to customise the share content, per your blog posts. Here’s the entire thing (apart from comments).

add_filter( 'share_on_mastodon_status', function( $status, $post ) {
  $status  = $post->post_title;
  $status .= "\n\n" . wp_strip_all_tags( $post->post_content );
  return $status;
}, 10, 2 );