Forum Replies Created

Viewing 15 replies - 1 through 15 (of 16 total)
  • Hi, as Brandon says, the bug was fixed for me and others at the time (or shortly after) with a patch.

    It was a strange one, sort of a quasi Chrome/Wordpress bug/non-bug!

    It was reported on my behalf to Chrome whose tech guys (I believe) recognised the ‘issue’ but said it’s not a bug with Chrome but admitted that it was only specific to their browser because of some formation/order of coding they use which processes typed text differently to other browsers.

    Via its patch, WordPress changed the way some text was handled or something like that, which eradicated the problem.

    So in layman’s terms I believe a change to WP or Chrome could have sorted it, I’m not sure if Chrome ever made any changes to ameliorate this ‘issue’ but WP did with its patch relatively quickly.

    So, sorry for your problem but this one is resolved!

    Thread Starter rowd1951

    (@rowd1951)

    Ok thanks, I have done that now and the error reports have stopped. (Obviously!)

    Thread Starter rowd1951

    (@rowd1951)

    Hi, my MySQL version is as follows:

    Server: Localhost via UNIX socket
    Server type: MySQL
    Server version: 5.5.41-cll-lve – MySQL Community Server (GPL)
    Protocol version: 10

    The Spam Captcha table in the database is empty because it is a fresh install (I’ve checked it in PHPMyAdmin just to be sure and yes, it is empty) yet the error log still shows this every time a comment (real or spam) is submitted.

    Ok, thanks.

    Following a look at comments made by others among the submitted tickets, I note that this problem isn’t restricted solely to Chrome, either.

    It’s nice to know that it is indeed a bug, as I claimed yesterday to a sceptical reception – which included outright denials that it was not a bug!

    Thanks both for your suggestions.

    James, I have submitted the following ticket:

    https://core.trac.wordpress.org/ticket/32196#ticket

    Samuel, the problem only manifests itself in text editor mode. I exclusively use text mode which is why it is a problem for me, whereas I suspect most users probably only use the visual mode, or rarely use the text mode.

    If it doesn’t relate to the introduction of emoji support, what is the explanation for the problem going away when emoji is disabled?

    Surely there must be a conflict there to do with the emoji support?

    Please feel free either of you if you have any influence over on the ticket I have submitted, to make comments of your own!

    Hi James,

    Like uitdragerij, my version of Chrome is 42.0.2311.135

    I’ve disabled everything and it doesn’t go away.

    I’ve also tried IE 11 on the same computer and cannot replicate the problem.

    Interesting that, like uitdragerij said, in shorter posts with fewer words if you enter these offending characters you’re unlikely to notice a lag.

    Only when it gets longer is the lag/latency noticeable, which is what makes me think it’s to do with the whole amount of text being processed or run through some form of filter with each key stroke, which gets thrown off with non-standard characters.

    My point being, this problem probably affects a short amount of text as it does a large amount of text, but the lag wouldn’t be noticeable.

    Samuel, I was typing my response before I saw your comment.

    MY OS is Windows 7 Home Premium, Intel i7 2.0 GHz, 64 bit with 8GB of RAM.

    It’s a Toshiba Qosmio, so it’s a powerful machine.

    Chrome is latest version as it’s just installed.

    I’ve just (for the first time) logged in to IE11 and cannot replicate the problem, so it’s specific to Chrome, for me, at least.

    I have completely uninstalled chrome and deleted all files remaining from the uninstallation. Then I cleared the cache using CCleaner, restarted computer, and reinstalled Chrome, the latest version, with all plugins disabled.

    And the problem persists.

    Could it have something to do with the character set change in WP 4.2?

    But then why would the problem go away if I disable emoji?

    The imstant a non-standard character appears in the text editor mode, the problem arises. It’s as if the character blocks something and yet as soon as the character is deleted, it works fine.

    All of the other symbols work ok !ӣ$%^&*()_+[]{}

    It’s a non-standard character like for instance, a bullet point: • or this: ❏ or these speech marks: “ ” ‘ ’ which, when entered, ruin the text editor’s functionality.

    Very frustrating – and I have tested it on two different sites, one hosted by JustHost in USA as well as another smaller host based in Europe, and both show this problem with the non-standard characters in text mode.

    Ok, I have a draft post using TwentyFifteen theme, it consists of nothing more than 12,000 words of Lipsum. It works a treat, no problems.

    Then I copied and pasted this phrase into the middle of that Lipsum:

    “The Cat” sat on ‘the mat’

    Firstly, it will take about 15 seconds to paste that sentence.

    During those fifteen seconds you cannot do anything.

    Then, after it appears, it will take absolutely AGES for any word I type to appear after that or before that, or anywhere in the post.

    If I delete that sentence -literally the instant the last offending quote mark is deleted – then I can carry on typing anywhere within that text normally as if there was no problem.

    If I then try and paste the following sentence in:

    “The Cat” sat on ‘the mat’

    (Please note this is not the same sentence as different speech marks are used)

    It pastes absolutely instantly, and I can edit around it 100% as normal.

    I think I have established.

    Whenever any single one of these appears in text:

    “ or ” or ‘ or ’

    then the latency kicks in.

    These are the curved variants of speech marks known as curly/typographic/or book quotes, and are commonly used, hence they showed up in all test posts.

    Seems strange to me that these symbols would cause an issue?

    Please note that the uncurved/straight quote marks (” or ‘) sometimes known as ‘dumb’ or typewriter quote-marks, did not cause any issue.

    I suspect the reason I could only notice the problem in longer articles is because in a small amount of test the amount of text in terms of data size is also smaller so the latency is, to all intents and purposes, not noticeable, but as the post gets longer, the latency becomes noticeable, i,e, it becomes an issue!

    I forgot to include in my post, but edited it just before you responded, that I tried testing it on TwentyFifteen and the problem still persisted.

    I have done what you suggest, and used Lipsum text, and cannot replicate the problem in either TwentyFifteen or my own theme.

    I tried up to 16,000 (yes, sixteen thousand) words of Lipsum and cannot replicate the problem.

    Yet as soon as I pasted the 2,665 words of my draft post onto the end of those 16,000 LipSum words, the problem arose – without me even having to ‘save draft’ and refresh the page.

    Then I re-deleted that draft post text I had pasted, and the problem went away – again, without having to press ‘save draft’.

    I think we’re getting closer to identifying the problem, but I’ll be darned if I can work it out myself!

    Well, thank you James. I have done what you have suggested – deleted this workaround code from my functions.php

    …I have then disabled all plugins…

    ..then I deleted everything else in my functions.php that may have affected the issue (including javascript calls)…

    …then I removed everything I had added to my site’s .htaccess other than the WP standard code…

    …and several permutations of the above steps, and the latency in text editor mode still remained.

    However, every time I tested this (after hard refreshing in Chrome developer mode) the (unpublished) blog article I was testing it on was in a pretty long post I had been drafting – over 2,600 words.

    I don’t know why, but I thought I would test editing a shorter blog post I had published some time ago – one with only 380 words – and, would you believe, it did not have this problem.

    So I went through various old posts, and this is what I found:

    Post which had 3,673 words – problem persisted

    Post which had 4,491 words – problem persisted

    Post which had 639 words – no problem

    Post which has 932 words – problem persisted

    Post which has 264 words – no problem

    So, this is somewhat scientific but in some ways not, but there seems to me to be a link between the amount of words in a post and this latency in the text editor.

    Please be aware that I always, without fail, compose my posts in text mode, and not everybody does. Not everybody writes long articles either, so it may be more widespread than people realise.

    To be sure, I have also switched to visual editor mode in long articles and short ones and have never experienced the latency.

    I have also installed and activated the latest version of TwentyFifteen and the problem persisted.

    So, from my investigation, I can conclude: I am experiencing severe latency in text editor mode (and text editor mode only, not visual mode) which only affects longer articles, and this problem only manifested itself after WordPress introduced emoji/Asian character support, and goes away if emoji is disabled via plugin.

    Now that sounds like a bug to me, but I am prepared to accept that it isn’t! Please could you give me your thoughts?

    Oh, and I will install the plugin and not keep that code in my functions.php file, if it will make you happy! 🙂

    James Huff, I’m not sure what you mean by this:

    It’s not a bug, the editor shouldn’t be operating slowly

    The fact that the editor is operating slowly is, surely, a bug. No? Not just for me but for others too.

    What else can we do to “troubleshoot to isolate the problem”?

    I would be quite willing to help, but as far as troubleshooting goes, I’ve disabled Emoji – sorry – “support for native Chinese, Japanese, and Korean characters” and the bug – yes, bug – has now gone away.

    Samuel Wood, I never suggested it was anything to do with my or salromano’s theme.

    The functions.php file doesn’t just affect theme issues, it is a way of disabling this new facility which has caused the text editor to be too slow to be used. It was a trade-off which was worth it because out blogs were unworkable without it.

    And although it may not have sorted the issue, it has allowed the text editor to work again.

    Oh, and this new functionality does add extra load – unnecessary load in many cases – with the extra scripts.

    Oh, and @JamesHuff, I found your comments to be premature.

    You were the only person to have responded to the OP before I posted my comment, following which you – in couched terms – suggested that it wasn’t really appropriate for me to have commented.

    All I can say is, your comment offered absolutely no help whatsoever. Mine, however, I hope, has done.

    I have now worked out the culprit. It is the stupid introduction by WordPress of Emoji support which loads scripts and who knows what else.

    I copied and pasted the code at the following link into my WordPress theme’s functions.php file and the text editor now works a treat, just like it used to:

    http://wordpress.stackexchange.com/questions/185577/disable-emojicons-introduced-with-wp-4-2

    Those with less technical ability, the code at that page disables Emoji support – and stops the scripts etc loading, it is not harmful to your site in any way whatsoever.

    If you’re not able or condfident to edit your functions.php file, I suggest you install a plugin to disable Emoji which will do exactly the same thing as copying and pasting that code into your theme’s functions.php file.

    Here is one you may wish to install: https://wordpress.org/plugins/disable-emojis/

    I’m confident you will be able to use the text editor without any latency after that.

    It’s a shame WP released this version with a bug (it’s a shame they introduced Emoji support in the first place in my opinion) but even if they don’t come up with a fix for it, disabling Emoji support is no bad thing – it slows down page loading times among other things.

    Good riddance to it I say! I hope my post helps somebody!

Viewing 15 replies - 1 through 15 (of 16 total)