jas8522

Also using Firefox here, so that seems to be where to reproduce the issue ??

Sounds great, thanks so much! Looking forward to seeing this in a future update.

@petere I’d bet either something was cached when you disabled the plugins or (more likely) your theme uses some hooks that integrate with the WordPress editor and they haven’t updated this code to work properly with Gutenberg yet.

Same issue here, only began with 1.32.0. WordPress version 5.0.3

Created bug report here: https://github.com/Automattic/WP-Job-Manager/issues/1667

• This reply was modified 5 years, 10 months ago by jas8522.
• This reply was modified 5 years, 10 months ago by jas8522.

Correction: I found the source of this issue. In my case it was a 7 year old plugin: WP SyntaxHighlighter. I replaced it with a recent fork to fix that up. Autosave continues, but it no longer causes cursor jumping issues ??

Those encountering this problem still should try:
1. Clearing their server-side (if using a caching plugin) and browser cache
2. Updating, Disabling and/or replacing *any* plugins that might hook into the admin text editor

Ditto. Super disappointing. I had high hopes for Gutenberg but how can they expect that people will ever want to use it if it’s totally unusable on their first interaction with it, which for most people will be while using the text editor block.

Perhaps this is only an issue with Firefox?

Ditto, using PHP 7.0. Error in logs is:

AH01071: Got error ‘PHP message: PHP Parse error: syntax error, unexpected end of file in [web_root_path]/wp-content/plugins/dynamic-user-directory/includes/admin.php on line 2370\n’

As a workaround I restored the includes/admin.php file from version 1.4.4 which solves the problem of the site not working, but may very well create other issues.

I completed a *very* fast visual code skim of the 1.4.5 includes/admin.php version, but didn’t immediately spot the issue. Presumably there’s a missing } or opening/closing php tag somewhere in there.

Also, more details on this can be found on this WooCommerce GitHub issue: https://github.com/woocommerce/woocommerce/issues/21772

I’m fairly confident it’s WordPress code — specifically wp_set_object_terms() being used to remove a term from post objects rather than via direct database query, but I haven’t yet done enough testing to say with absolute certainty.

• This reply was modified 6 years, 4 months ago by jas8522.

I noticed a sort of pattern to this:

1. It doesn’t happen on all posts. If I remove all the & amp;& amp repeats and leave it with only a single & (no amp;), the issue does not return. But if I leave any instance of & amp; JavaScript kicks in onblur and adds another amp; to it. (This is a definitely the repeatable bug).

2. I haven’t been able to figure out why the & amp; gets introduced in the first place. My guess is it occurs when converting from old < pre > or < code > blocks that were added prior to this plugin being activated.

Note that spacing in the code above was added to hopefully prevent auto encoding. The spaces aren’t in my actual code blocks.

Same issue here. Lots of &amp;amp; which keeps multiplying every time I save the post ??

Hey there,

It was a cache issue on our end; using WP Rocket, simply had to clear the cache as it was trying to access the old /font/ folder.

Yeah, this is a problem in that it also seems to override many other plugins’ loading of more recent versions of the FontAwesome library.

Would be great to have the option to load the latest version from CDN as well as an option to specify not to load the FontAwesome CSS locally to be used when other plugins are doing so. Or perhaps better yet, simply detect if it’s already loaded and don’t do so.

Hey Tanzil,

Thanks for the response! I definitely am interested ??

Would love it if you could add that in as an option in the widget settings. Totally understandable that some wouldn’t want to enable it though.

-Jordan

Looks good! I reinstalled the plugin and no more errors. Thanks!