dannyletham

Sorry but could I ask you to look at this again? While I concede I hadn’t operated the admin bar’s language filter, the only effect of doing that is to limit the pages / posts available with the visible menu item types; it makes no difference to which types appear in the first place. In every other respect I have followed the procedure that you outline. Might WP have introduced a bug of which you were previously unaware? I can reproduce or eliminate the fault reliably by using either 5.5.3 or 5.5.1, but clearly that is not a sane longterm strategy for creating a useful menu!

I am inclined to think that WordPress itself and not the plugin may well be the source of the problem. in which cases your assistance might be useful: indeed it may be in both our interests for you to share this finding with WordPress:

After setting to “on” the Language Switcher via Appearance->Customiser->Menus I have established by opening wp-admin a second concurrent tab that, as you’d expect in the absence of an enabled “Publish” button, there is no write-back. Accordingly the option to add the switcher to a menu is not presently made available. This applies across the 3 themes I have tried, which FYI are Cyberchimps Responsive, Attesa, and Lovecraft. In all three cases this problem arises in 5.5.3 but not in 5.5.1

Thanks

• This reply was modified 4 years ago by dannyletham. Reason: typos

You said that already.

My question is how do I do that without a paid account? Your support page assumes I have a login already and gives no option that I see do create one. My people are using the free version. Do they have to buy something?

Can I do that for free theme and without a premium account? If so, how?

Okay, so today I see there is a 4.1.8, last updated 26 February, despite your having encouraged me to downoad the “latest” 4.1.6 on 11 March. I am confused!

I’ll not update to 4.1.8 until I hear your views on my 4.1.6 findings, in case you need to look at the page as indicated under 4.1.6.

(marking this resolved)

Thank you @manishverma

Version 4.1.6 has indeed resolved those issues but seems to have lost some other options regarding text colors on sidebar and introduced a typography related issue also on sidebar. I shall raise a new ticket regarding that presently, and another about a separate query.

Kind regards

I found this too, but a lateral think fixed the issue. Setting Header Layout to “Logo Center” does it right, while reverting to Logo Left will reintroduce the problem. Since it’s full width the alignment L vs R vs Center doesn’t matter.

My concern is … if the design team thinks the small size is in some way “right”, might a future release break our sites? Please Mr/Ms Cyberchimp let it not be so!

Well, fair play to you @dvankooten for having the good grace to come tell us in person. That matters!

Meanwhile, regarding reverting to 2.0.13, I had anticipated that the fix would be temporary, and indeed after a few days it also perished.

There are alternatives out there but so far I haven’t summoned the mental energy to look at them. Real life gets in the way, you know??

Well it doesn’t look like the plugin is abandoned as-such, given an update to 2.0.14 late September. I have found that deploying that update invalidates the credentials in some way, but happily rolling back to 2.0.13 AND restoring the database – which may be the bad news if you’ve added much other content to your site in the meantime – did get it working again.

So, can I please add my voice to the chorus, Danny can you help please??

That appears to have worked, but not before throwing this at me:

Update Failed: .addon-count { display: inline-block; z-index: 26; margin: 1px 0 0 2px; margin-top: 1px; margin-left: 5px; padding: 0 6px; border-radius: 10px; color: #fff; background-color: #d54e21; font-size: 9px; font-weight: 600; line-height: 17px; vertical-align: top; } {“success”:true,”data”:{“update”:”theme”,”slug”:”responsive”,”newVersion”:”2.7.2″}}

I took no remedial action, but the sane appearance is restored

What are the implications of this, if any?

Regarding the page https://docs.wordfence.com/en/My_scans_don’t_finish._What_would_cause_that%3F
O finding hangup today I set the max execution time to 15 s suggested and found that after the said 15 seconds (well 13 actually) the scan was terminated with an error bearing the legend “scan interrupted”. Setting 40 seconds had a similar result after 31 seconds/ So I cranked it up (arbitrariliy just guessing) to 300 (ie 5 minutes) and got a good result.

I don’t have problem with any particular numeric setting but FYI:-

Two issues here, one quite serious the other less so but still wrong:
(1)Your page suggests that the scan resumes. It doesn’t; it dies. And if you meant “after the user or cron job resumes” then I have to query then the statement “we pause the scan and launch another process and pick up where we left off” appears to be untrue.
(2) Might it be worth your adding the rider “timings are approximate”?

First – thank you once more for attention, clues and pointers.

There is a long version below of my latest outcome in which you may find some of the asides to be noteworthy, but the punchline is this:
Following an update of the PHP version which was at end-of-life and an update to the calendar plugin (not in that order unfortunately which would have been better diagnostic path) there are no differences for WordFence to fail to find. So I guess that’s the end of that.

While I don’t know for a fact that it didn’t contribute, I can say that it wasn’t MULTISITE alone. I removed the MULTISITE statement from wp-config.php first of all, because as you quite rightly detected I wasn’t seeking to create a WP network. It seems that the WP install inserted that code because it was going into a subdomain. When that didn’t make any difference and I logged into my ISP account to remove the code for that its dashboard flagged the PHP issue, and so after checking that the WP/WF problem persisted I pursued that. And then – there was the curveball of Calendar 2.5.19 which I will own up to having mismanaged as regards diagnostic purposes in my fatigue/haste.

The long version:-

Re. Multisite: I presume that because I set the thing up in a conventionally externally hosted subdomain, WordPress set that parameter to true. It wasn’t ever my intention to be multisite. In fact I have an old and curently inactive Joomla implementation of something entirely different as the main domain’s site content which I opted to leave in place for the time being. By way of proving the assumption about the subdomain, I had a look at the wp-config.php on a copy of the site running locally under wampserver but in a main domain setting, and sure enough the code for that parameter was absent, and so (I presume!) false.

However, I couldn’t activate Wordfence in the virtual server environment to test the change locally, as my attempt to do so broke the copy site (“connection reset”) This was fixed easily enough by renaming the wordfence folder. I thought you might like some intelligence of that if you don’t have it already.

So, next I edited the wp-config.php on the externally hosted subdomain and ran a scan. The error persisted.

Now, I mentioned that old Joomla site not for the fun of it but because my main hosting was still on PHP 5.3 and I see that WordPress recommends PHP7.0. The Joomla release o n that site is out of date and not compatible with that; it can’t go beyond 5.6. I need to update the Joomla version – but not right now! Like I say it’s inactive anyway and the subject of a business related rethink.

So, was PHP5.3 the source of the problem? Well, I updated to 5.6 and no it wasn’t. What then of 5.6? I went to 7.0 temporarily, but before scanning again I was surprised by an update to the calendar plugin from 2.5.18 to 2.5.19 which inadvertently I agreed to before re-test – and when I did run the scan again there were no issues raised at all about the calendar plugin, and thus no changes to look for! Apologies for failing to have a cast-iron iterative process here.

You asked for a list of problems detected. Prior to this there were 66, of which 63 related to the calendar and of those 63 most were related to language files – and as it happens not the one in which I have an interest! After the 2.5.19 / PHP7.0 update there were only the other 3 “issues” and those related to:
wp-admin/includes/upgrade.php
wp-includes/functions.php
wp-includes/load.php
I can see the differences in those cases and there is nothing dramatic or scary – just some changes to exit logic in error handling e.g. die→ exit. So, I’m okay with that.

I have since reverted to PHP5.6. And the issues didn’t come back. I intend to stay on 5.6 for the time being, until either I can address that Joomla update or WordPress stops recommending 7.0 and starts to insist on it.

The ISP self service console won’t take me back any earlier than PHP5.6 since 5.3 thru 5.5 are at end of life. Accordingly, it seems likely there was some conflict between Calendar 2.5.18 and WordFence, but there is a chance too that PHP5.3 was all or part of the annoyance. My money would be on the calendar plugin, but I guess we may never know!

No point in reinstating the MULTISITE parameter given the final outcome – at this point I’ll gamble on our not needing to know.

Thanks for everything w
Kind regards
Danny L.

Have done that now Sorry for delay.
In fact I did it twice because no sooner had I turned my back than a polylang update appeared! Since I’m not party to exactly where you are looking or what for (or whether it’s for my specific benefit or the community as a whole) I thought I’d send you a before and an after just in case – unlikely though it might be – the polylang update provided a fix. Of course the polylang update made no difference, and the issue persists. Accordingly the first one timed around 2151BST I guess you can disregard, and the one timed around 2157BST is the one currently of interest.

Updates? Oh yes. It was up to date yesterday at the time of reporting, and after the Tuesday Morning Edition of that theme (2.5) it s up to date again. Every Plugin, the transations, the theme, and WordPress itself. The issue persists.

Re the diagnostis:
http and https connecting both report “OK”, and indeed I do get the daily email, which rather suggests that the site is indeed in touch.

Eerything else presents a catalogue of OKs too, however a couple of things did catch my eye which don’t strke me as germaine to the matter in hand. Even so, I ought to give you the chance to say “that’s it!” if indeed it is.

1. “Warning: posix_getpwuid() has been disabled for security reasons in […]/wp-content/plugins/wordfence/lib/wfDiagnostic.php on line 196” But I don’t imagine that user IDs or passwords are part of the problem?
2. “Enable SSL connectivity” is checked as per default. Since this will be running in a non-SSL environment (yes – I know!!) I mention it for completeness.

Yes wfalaa, it’s still there. Today’s WF scan altered me to a couple of other uodates – jetpack and the CyberChimps response theme, plus the alleged issue on calendar.js. As before the link to show differences failed to find the WordPress core API file. So in order to be as up to date as possible I have updated the other two and the problem persists.

I am quite relaxed about it btw, and don’t perceive the problem as a real one.Thank you for having the patience to stay in touch over this; I hope that you are at least gaining some info about what’s going on elsewhere in the eco-system. I think that while WordFence is a desirable enough product for what it DOES in fact do, I don’t feel knowledgable enough to scold it for crying wolf which every instinct I possess is telling me is the case.
Thak *you*