semyl

@mirx1 Excellent point.

@mirx1 It is crazy how many solves here are for this one issue. I guess it is down to it being such a vague error message. Thanks for sharing!

@faizacef00 Did you try what I described as a fix, from 10 months ago?

That’s fabulous, thank you @linux4me2! I’ll test it out and get back to you if I have any issues.

To explain in case you are curious – that particular menu is for categories (and subcategories) of a video database. The videos are a custom post type. Users will likely click through a lot of categories/video pages in quick succession, so we want links in this menu to jump below the hero/back to this menu. However, if they are coming in from elsewhere (e.g. the main website menu at the very top of the page, or a direct URL), then it makes sense for them to see the site header and hero first (i.e. no anchor).

• This reply was modified 4 years, 3 months ago by semyl.

Hi @linux4me2,

Yes I want to add #theanchor to the end of ALL links in that menu. I don’t want to use Custom Link as that means my menu won’t update if slugs change. Also, I want this added to the end of all the items of this particular menu. I was hoping there was a way to do it programmatically.

A quick google mentioned something called a walker that could do this. Seeing as this particular menu is one I use with Menu in Post, I was hoping there could be a simple way to extend the plugin so the shortcode could have an option to to append something at the end of every menu link (I could see other use cases for this, e.g. adding language variables to the URL).

@gerard70 Very happy to help! Had only just figured it out myself at the time of posting.

For those who experience this because of a migration that included changing your wp prefix, you also need to update your _usermeta table otherwise it will not work.

If you have access to the database, e.g. in PHPMyAdmin, you can use something like this (update newprefix and oldprefix as applicable):

UPDATE newprefix_options SET option_name = REPLACE(option_name, ‘oldprefix_’, ‘newprefix_’) WHERE option_name LIKE ‘%oldprefix_%’;

UPDATE newprefix_usermeta SET meta_key = REPLACE(meta_key, ‘oldprefix_’, ‘newprefix_’) WHERE meta_key LIKE ‘%oldprefix_%’;

Note that in this case, the wp_user_roles row is in the _options table, but you need to update the prefix otherwise it produces the same error.

• This reply was modified 4 years, 8 months ago by semyl.

You hit the nail on the head there, I updated the MySQL user permissions to be able to create a table, so now that appears in the database. Interestingly, the Custom Contact Forms plugin created tables – and apparently that should not have been possible with the previous permissions. Curious.

Just as an FYI, a reactivation didn’t seem to insert the tables into the database, I had to delete the plugin, reinstall and then activate.

On testing, data posted in the form is now saved in the database – brilliant!

However, despite that success, I am still received the error notification, although now with less characters of unexpected output:

“The plugin generated 1010 characters of unexpected output during activation. If you notice “headers already sent” messages, problems with syndication feeds or other issues, try deactivating or removing this plugin.”

Any suggestions as to what it might be? If not I will just leave it as to all appearances, it seems to be working fine.

It might be more useful if these characters of unexpected output are saved in an error log file, or at least displayed somewhere. But I supposed this might be a WordPress thing rather than something you could do?

Thanks for your help.

I noticed the same problem – I think on a previous version of the plugin which I had installed on another site it went to a page which told you which fields were missed, and you could go back to fill it in. Actually not the most ideal error message – a pop-up like the success but saying it is a failure would be the best thing.

Interesting.. thanks for spotting that!

Found the extra trailing space in my permalink settings.

Incidentally though, as others may make the same mistake and to all appearances their site will work as normal, perhaps AddToAny could strip trailing spaces from the URL before passing it to Facebook?

I had tried to lint the pages with a trailing space, but that didn’t scrape it properly – I guess it was a Facebook thing that needed me to use the plus symbol in the linter. And I only considered that because I noticed one of my pages came up twice on the list of Top Pages, once with a plus and once without.

Thanks for the help micropat!

FYI, I fixed it by linting https://truthquestions.org.uk/is-it-human-to-need-god/+

For some reason the + is added by AddToAny, making the URL different so my previous lints weren’t working.

Maybe it would have been scraped sometime in the next 24 hours, but I didn’t want to wait that long!

To update, I actually discovered that it is the extra %20 after the u attribute and before the t attribute that is causing the old information to appear.

So
https://www.facebook.com/share.php?src=bm&u=https://www.truthquestions.org.uk/is-it-human-to-need-god/&t=Is%20it%20Human%20to%20Need%20God%3F&v=3

works as expected.

Any help will be appreciated, thanks.