shinerweb

It might be the server time. In which case, you might be able to put something in your local php.ini / apache / or similar config file to change the system date locale.
All depends on what type of server / hosting you are using.
That is usually the case of times/dates being different to local time.

Was researching this problem this morning and found this solution.

https://www.ads-software.com/support/topic/causes-cli-errors-because-server_name-is-not-available/

Thorsten,

Yes, I can confirm it works.

Line 370 should read: wp_get_current_user();

The new block (lines 368-374) should now look like:

if ( $this->op( 'wfb_update_notification' ) ) {
			global $user_login;
			wp_get_current_user();
			if ( !current_user_can( 'update_plugins' ) ) {
				remove_action( 'admin_notices', 'update_nag', 3 );
			}
		}

• This reply was modified 8 years ago by shinerweb.

ah, “holds hands up” time… being my offline test server, I had somehow managed to enable both WP Super Cache (the source of the Clear Cache button as you correctly pointed out) and had the Falcon Cache enabled.
It might have been the WP Super Cache confusing Falcon as not being enabled.
I did use the WF_ENABLE_FALCON #define which allowed me to switch off Falcon engine. Just didn’t spot I had WP Cache enabled as well.
Shouldn’t update in the mornings prior to coffee…
apologies for the extra hassle.

btw. Totally agree with your decision to remove the Falcon from WordFence. Best security plugin out there, why muddy the waters with extra bells and whistles. Sometimes it’s not a good idea to be a Jack of all trades, master of none.

@wfsupport / @wfasa

Users that didn’t have Falcon enabled should no longer see “Performance Setup” in the wordfence menu on their sites. Users who came into the update with Falcon enabled should see it. Defining the constant WF_ENABLE_FALCON in your wp-config.php file will cause it to be shown no matter if it was or was not enabled prior to the update.

My original post stated that even though I had Falcon enabled prior to updating to 6.2.1, caching was still enabled and I didn’t receive the “removal notice”.

I did use your define(WF_ENABLE_FALCON, ‘true’); suggestion which allowed me to disable Falcon caching, clear down the cache.
There is a still a “Delete Cache” option in the top Admin bar which is broken, but only a minor issue.

Even after removal of the WF_ENABLE_FALCON #define, the “Delete Cache” option is still visible.
Might be an idea to remove that menu option completely given that (a) the cache feature is disabled/to be removed and (b) it’s a broken link that doesn’t do anything other than possibly confuse the end user.

That behaviour is down to the caching of the pages on your site and not related to this plugins behaviour itself. It would be beyond the scope of this plugin to start interfering with the caching behaviour of your site.

You might have caching being performed by a plugin (such as W3 Total Cache).
In this instance, after creating a new post, you should always clear or rebuild your cache. Whilst you may have created the new post in the category, the category page inside the cache on which you are displaying your calist hasn’t been updated. Clearing the cache will cause it to be rebuilt when the next visitor hits your website. Ideally, your cache plugin should allow you to clear down a specific page rather than delete every object in the cache even if it has nothing to do with your new post and it’s associated category pages. (W3 Total Cache allows you to do this for example)

Or, you may have set up your site to leverage browser caching (this might even be automatically set up by your web host).
This may be performed by a Page Speed plugin for example to help improve your Google Insights Speed test. Either way, it’s good practice to enable browser caching on your site.
Whilst there are ways of forcing/tricking a visitors browser into loading a new version of an object, you can’t really control the visitors browser without adding extra plugins/controls (i.e. You can’t force the user to perform a cache clear via Control F5 but you can make the browser think an object is new).

Works for me.
Did you see any errors in the transcript for the entry that failed to send?

Had another issue today where unable to delete an entry from the firewall table:

/wp-content/themes/mTheme-Unus/css/css.p?-hp
request.queryString[files]
10/05/2016, 21:41:59

Again, had to manually edit the entry to remove the ? and was then able to delete that entry.

Out of interest, do you have your site set to not return 404’s for non-existent pages?

There was a bug in earlier versions that created entries for pages that returned 404’s but a fix was released for that. I’m just wondering if you have your site set to not return a 404 (and perhaps load a search page).

On the WordFence signup page there is a pricing table that breaks it all down for you. Each site will need a unique key, so you’ll need 2 keys for 2 sites.

You can purchase Premium from https://www.wordfence.com/wordfence-signup/

Basically you will get an API key which you enter into your WordFence settings that authenticates your websites to be able to communicate with the WordFence server

API = Application Programming Interface: Think of an API as a translator between your site and an external service. So the Facebook API lets you send and receive information to and from Facebook. The WordFence API lets you send data to WordFence such as IP addresses of visitors, WordFence then sends you back a code to say good/bad/whatever. That’s what an API does).

Have you tried whitelisting your IP address to see if it is something like the firewall interpreting your own actions as attacks? (I suspect it’s detecting your Ajax calls as attacks which stops the editor action from completing leaving the spinning wheel).

Are there any log entries against your IP when this happens?

Was looking up another issue and I spotted this report (Firewall in learning mode learned to whitelist hacking scripts).

https://www.ads-software.com/support/topic/firewall-in-learning-mode-learned-to-whitelist-hacking-scripts?replies=6

Didn’t spot that when submitting my own ticket so hopefully my issue is resolved. I’ll mark this as resolved as I’m fairly certain all of my Whitelist entries were logged prior to the update.

Daft question/observation.
You don’t happen to be using a Firewall type plugin do you?
I had one instance on one particular test site of mine where entering certain admin links would be interpreted as ‘attacks’ on the site by a Firewall Plugin and would direct me to a 404/500 page. I had to set up a whitelist of URL’s to get round it.

Just a thought…

I had the same problem today when I added (or uggraded an existing member) to “Editor”.
He doesn’t see the TinyMCE at all.
I tried all non-Admin roles and the editor just isn’t displayed.
Tried all the usual clearing caches/different browsers with no joy.
Commented on this thread to be kept up to date with any feedback to your post.