Simon Carne

This simply isn’t correct. I have switched back to the “local” version of BLC and, sure enough, the link we have been focussing on is NOT shown as broken. In the list of All links, it is marked as “401 OK”. In the list of Broken links, it is (corrctly) not showing (becaus the link works). I don’t know why you are insisting that the cloud version of BLC is doing its job by reporting this perefectly good link as broken.

It is worth reminding ourselves that, although this exchange has become focussed on one or two examples, my original point was that the cloud version of BLC was giving me a LOT of false negatives. That remains the case.

• This reply was modified 1 month, 3 weeks ago by Simon Carne.

I was trying (unsuccessfully, it seems) to explain how this looks from the perspective of a lay user like myself. There may be a very good reason why your tools cannot access a site that, for example, requires authorisation. It would be a lot more helpful if BLC identified those as needing investigation by the customer (ie me) rather than reporting them as “broken”.

I write news and comment pages with links to primary sources (eg national newspapers), some of which are behind a paywall. Those of my readers who pay to read those other sites can click through. Those who don’t can at least have the satisfaction of knowing that my research is properly sourced and other readers will be able to check up on me.

Kind regards

I think you are confirming that three of the four links are NOT BROKEN (and the fourth one is only broken sometimes). If BLC can’t get through to a Clouflare site or to one which requires “consent”, that means that BLC isn’t doing what it promises to do. It may be reassuring to you and your colleagues to know that there is an explanation for the wrong report, but from the customer’s perspective, it is still a wrong report.

I have followed up your suggestion to open a ticket, in which I gave four examples of links that are wrongly being reported as broken. One of your colleagues messaged me back to say that the reports are “legit” even though they really aren’t. Your colleague has in fact been able to access two of the sites and, even though they say they can’t access the other two sites, I certainly can [to be clear, these aren’t internal links to my own site, they are external links]. It is a mystery to me why your colleagues cannot access sites that are working, but the fact still remains that there is a problem with Broken Link Checker reporting broken links that aren’t broken.
There are many more links that your app is reporting as broken, not just the four I offered in my feedback. Looking at the review age for your site, I am not the only one having this problem.

I have reviewed your response which I find very puzzling indeed. I have looked again and I still find that none of the links are broken.
* 401 Unauthorised: The link is behind a paywall, but it isn’t broken.
* 21 Internal Request Error: This is a technology explanation site. I don’t know why you can’t access it, but I have had no difficulty.
* 500 Internal Server Error: You have acknowledged this one isn’t broken.
* 403 Forbiddeen: This site is not restricted to Germany. In fact, it’s a Brtish political site and I am able to access it from the UK.
It seems that there is a problem with your systems being able to access these sites, not the sites themselves.

That’s great news.

Many thanks. Much appreciated.

Many thanks. That’s very helpful.

I have done some further research. If I change the “Appearance” setting from “Custom” to “Default”, the menu returns, but (of course) that means that I can’t use the customisation options. So I would still welcome some help in fixing this.

Apologies to @darkog. My previous reply failed to recognise that you were answering the question posed by @e4t2x0o (about alternatives). I mistook your comment as a response to the original question. Nevertheless, I hope WordPress will soon address the original issue.

@darkog Thanks, but the real question is why does WordPress > Tools > Import direct users to download a plugin that is (1) labelled in the repository as not having been updated to match the past three versions of WordPress and (2) leads to services like Wordfence warning that the plugin might have been abandoned?

Perhaps it’s just an oversite by www.remarpro.com but hopefully they will address it.

Thanks, @dinhtungdu

@sakanakana, You don’t say what problem you are having, but if it’s the same problem that I had, the following may help.

On my site, the three-line hamburger menu changed to one line. After some searching around, I found the following fairly simple fix.

In the kumle theme is a folder /assets/third-party/meanmenu, which manages the switch to a mobile menu. I made a very minor edit to the file jquery.meanmenu.js (I used standard text editor to open and edit the this .js file). In line 32, there is this code:

meanMenuOpen: "<span /><span /><span />", // text/markup you want when menu is closed

I changed each instance of <span /> to <span></span> and the three lines were back. I’m not sure why, but I think the use of <span /> may be obsolete.

Hopefully, the kumle developer is reading this and, if they agree my solution, they will amend the kumle theme for everyone.

If, like me, you are using a child theme so as not to alter the parent kumle theme, the solution is a bit more complicated. I copied the meanmenu folder (ie /assets/third-party/meanmenu) from kumle to my child theme. Having done that, I found that it was also necessary to enqueue the two files inside my child themes. I did t by adding code to my child theme’s functions.php. I’m not at all proficient in PHP, but I found the following worked for my child theme:

function <strong>[insert a pre-fix]</strong>_scripts() {
	wp_enqueue_style( 'jquery-meanmenu', get_stylesheet_directory_uri() . '/assets/third-party/meanmenu/meanmenu.css' );
	wp_enqueue_script( 'jquery-meanmenu', get_stylesheet_directory_uri() . '/assets/third-party/meanmenu/jquery.meanmenu.js', array('jquery'), '2.0.2', true );
}
add_action( 'wp_enqueue_scripts', '<strong>[repeat the same pre-fix from above]</strong>_scripts' );

I think you can use any “pre-fix” that hasn’t already been used in the theme. (Don’t type the square brackets.)

Good luck

• This reply was modified 3 years, 8 months ago by Simon Carne.
• This reply was modified 3 years, 8 months ago by Simon Carne.
• This reply was modified 3 years, 8 months ago by Simon Carne.

I have found the answer to my own question. The file was inside the inc folder. I should have looked more carefully before posting this.

My apologies. this plugin was not the cause of the problem. If you want to delete this topic from the list, please do so.

Well, curiously, the problem has fixed itself. I tried various things that didn’t work (like restoring a version 5.4.2 and then moving forward again). But, in the past few minutes, I reloaded the Plugins page and the problem was fixed.