herrvigg

> The issue seems to be that:
> wp.oldEditor.initialize() is no longer firing and many plugins/blocks looking for this > event are no longer functioning.

Could this be related to what I observed with window.load not firing properly in some event listener?

> Uhh, I just reverted to an older jquery via a plugin – and that fixed it. :/

That seems to confirm something is going wrong with some event.

Not sure why the issue is marked with “Status: resolved”…

It is definitely NOT resolved. It is a critical bug blocking the normal functionality.

hello,
I’m the maintainer of qTranslate on github and we are also encountering this problem with WP5.6, Firefox and the Classic Editor (that many, many people still use): https://github.com/qtranslate/qtranslate-xt/issues/931.

The problem seems to occur quite randomly, but so far i only observed it in combination with WP5.6, Firefox, and the Visual Editor (with Classic Editor). Sometimes the problem disappears just by reloading exactly the same page in a different tab…

I observed one interesting event: for some reason (due to WP 5.6 + Firefox?), a listener i have on window.load even does not trigger all the time as it should, though i’m sure the addEventListener is called. If i add another dummy window.load, this one is called all the time, which looks quite insane. Why would a window.load not be triggered?

• This reply was modified 3 years, 11 months ago by herrvigg.
• This reply was modified 3 years, 11 months ago by herrvigg.
• This reply was modified 3 years, 11 months ago by herrvigg.

I have the same problem, it’s something inconsistent in WordPress because get_category_link calls get_term_link which calls the filter category_link internally for the category taxonomy. So the deprecated message does not make any sense at all.

The good news is that this has been reported and it seems a fix is on the way to un-deprecate category_link: https://core.trac.www.ads-software.com/ticket/49759.

It seems i solved the problem which is related to cloudflare (proxy/cache). The cloudflare WP plugin is necessary for the sitemaps to work properly. The sitemaps look correctly generated when requested separately from the browser. But the request from Google search engine fails if the cloudflare plugin is OFF which i can’t really explain at this point.

hello,
great this is fixed. I removed the “reCAPTCHA field” workaround and now it works fine.
Many thanks!

hello,
that’s great!
Many thanks ??

Hello,
I found these warnings when checking compatilibity with PHP 7.1 and PHP 7.2. Could be external dependencies but how to be sure it’s not used? Would be nice to get rid of those.

FILE: /var/www/html/wp-content/plugins/goodbye-captcha/includes/vendor/MchCrypt/Core/Generator.php
——————————————————————————————————————————————————-
FOUND 3 ERRORS AFFECTING 1 LINE
——————————————————————————————————————————————————-
272 | ERROR | Extension ‘mcrypt’ is deprecated since PHP 7.1 and removed since PHP 7.2; Use openssl (preferred) or pecl/mcrypt once available instead
272 | ERROR | Function mcrypt_create_iv() is deprecated since PHP 7.1 and removed since PHP 7.2; Use random_bytes() or OpenSSL instead
272 | ERROR | The constant “MCRYPT_DEV_URANDOM” is deprecated since PHP 7.1 and removed since PHP 7.2
——————————————————————————————————————————————————-

FILE: /var/www/html/wp-content/plugins/goodbye-captcha/includes/vendor/MchCrypt/Core/Crypter.php
——————————————————————————————————————————————————-
FOUND 6 ERRORS AFFECTING 3 LINES
——————————————————————————————————————————————————-
136 | ERROR | Extension ‘mcrypt’ is deprecated since PHP 7.1 and removed since PHP 7.2; Use openssl (preferred) or pecl/mcrypt once available instead
136 | ERROR | Function mcrypt_module_get_supported_key_sizes() is deprecated since PHP 7.1 and removed since PHP 7.2; Use OpenSSL instead
201 | ERROR | Extension ‘mcrypt’ is deprecated since PHP 7.1 and removed since PHP 7.2; Use openssl (preferred) or pecl/mcrypt once available instead
201 | ERROR | Function mcrypt_encrypt() is deprecated since PHP 7.1 and removed since PHP 7.2; Use OpenSSL instead
219 | ERROR | Extension ‘mcrypt’ is deprecated since PHP 7.1 and removed since PHP 7.2; Use openssl (preferred) or pecl/mcrypt once available instead
219 | ERROR | Function mcrypt_decrypt() is deprecated since PHP 7.1 and removed since PHP 7.2; Use OpenSSL instead
——————————————————————————————————————————————————-

FILE: /var/www/html/wp-content/plugins/goodbye-captcha/engine/modules/reports/partials/modal-dialog.php
———————————————————————————————————————————————————————————-
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
———————————————————————————————————————————————————————————-
1 | WARNING | No PHP code was found in this file and short open tags are not allowed by this install of PHP. This file may be using short open tags but PHP does not allow them.
———————————————————————————————————————————————————————————-

FILE: /var/www/html/wp-content/plugins/goodbye-captcha/engine/modules/reports/partials/latest-attempts-table.php
———————————————————————————————————————————————————————————-
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
———————————————————————————————————————————————————————————-
1 | WARNING | No PHP code was found in this file and short open tags are not allowed by this install of PHP. This file may be using short open tags but PHP does not allow them.
———————————————————————————————————————————————————————————-

FILE: /var/www/html/wp-content/plugins/goodbye-captcha/engine/modules/reports/partials/percentage-chart.php
———————————————————————————————————————————————————————————-
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
———————————————————————————————————————————————————————————-
1 | WARNING | No PHP code was found in this file and short open tags are not allowed by this install of PHP. This file may be using short open tags but PHP does not allow them.
———————————————————————————————————————————————————————————-

Hello Cloudflare, any news about this?

In my case i uninstalled regularly from the plugin menu in WP. This deleted also the gdbc (Goodbye catcha) from the options. Then reinstall it and it should re-create everything properly.

The residual options may create some problems when reinstalling. If you need to remove by hand just do first :

select * from wp_options like 'gdbc%'

Check you can delete this stuff and then do it:

delete from wp_options like 'gdbc%'

hi,
you lost the main DB table used by WP Bruiser. I also had a similar issue but it was probably due to a mistake when i cleaned a lot of stuff in my DB. The problem is i couldn’t upgrade any other plugin because of this error.

I solved it by uninstalling WP Bruiser completely so it cancels all the options and then make a clean reinstall from scratch, restore your options by setting them manually again. Make some screenshots of every panel, it’s the safest way imo. The table will be created again if your options are empty. At least it worked for me!

If you are really sure about what you are doing you can dump the options and restore them after reinstall, by default they are in wp_options prefixed by ‘gdbc’. You can check them with `select * from wp_options like ‘gdbc%’. I did an extra backup like that but i preferred to enter the options by hand again so i’m sure i will not have any problem of version compatibility.

Hope it helps.

the translation lookup will fail if this setting has been changed.

Yes but it doesn’t matter and it’s actually what we want! It’s the gettext filter that allows you to some stuff behind. Forget about the .po/.mo files, i know they are for static content but it’s not the key point here. Custom string values in settings can be handled.

Please can you try the code i sent?! It should give the same result as the solution you proposed, but this solution is more generic.

Great! ??

Just to conclude, here is an example of what you can do with gettext by plugging in a particular translator. I haven’t tried it but it is to illustrate the forementioned case so Jonathan may try this directly.

if ( function_exists( ‘qtrans_useCurrentLanguageIfNotFoundUseDefaultLanguage’ ) ) {
  add_filter( 'gettext', 'translate_with_qtranslate', 20, 3 );
}
function translate_with_qtranslate( $translated_text, $text, $domain ) {
  // might be called more specifically given domain
  $translated_text = qtrans_useCurrentLanguageIfNotFoundUseDefaultLanguage( $text );
  return $translated_text;
}

This supposes the input string, here the login options we are talking about, are encapsulated with __(xxx, domain) even if they come from the options table after being changed by the admin. You could also call apply_filters('gettext', xxx, domain) only but it is more restrictive and verbose. The nice thing is that is doesn’t make any assumption about the plugins you use, up to you to call whatever you want in your hooks.

Note well the comment given in https://codex.www.ads-software.com/Plugin_API/Filter_Reference/gettext

“This filter hook is applied to the translated text by the internationalization functions (__(), _e(), etc.). IMPORTANT: This filter is always applied even if internationalization is not in effect, and if the text domain has not been loaded. If there are functions hooked to this filter, they will always run. This could lead to a performance problem.”

Actually the performance is only an issue depending of what you do in the filters, not by the call of the filters themselves or the lookup hit miss.

glhf

• This reply was modified 7 years, 3 months ago by herrvigg. Reason: code formatting
• This reply was modified 7 years, 3 months ago by herrvigg. Reason: clarified example

I really don’t understand why you insist so much to argue about something that i have tried and that works! “That’s for static translation” if you use it only with constants and restrict yourself to the static MO configuration files. You can also use it for dynamic translation because the gettextfilter is called behind this. It doesn’t matter if the source value comes from a constant or a variable, the lookup is anyway interpreted at runtime, it’s just a hash table and in my particular case i expect it not to be found but someone else could have a different usage. It will also work if you change configuration because the new value will not be found.

The fix i propose is done by adding 4 characters by item and allows for dynamic translation in a generic manner with the underlying filter. Problem solved. Your suggestion is way more complicated and limited to qTranslate only. It won’t work with qTranslate-X unless you use a legacy mode which is not the general case.

• This reply was modified 7 years, 3 months ago by herrvigg. Reason: precisions
• This reply was modified 7 years, 3 months ago by herrvigg. Reason: configuration

For any static translation, you would call __() or _e() which reads the content at runtime, so it would not make any big change regardless if the content is found or not in your resource files. Here a custom content is expected not to be found but it’s fine.
(precision: here i don’t mention the extraction of the source files for the PO/MO editor but the lookup source string -> target string, which is done at runtime even for a purely static content.)

Clearly, there are big limitations in the WP architecture about translations and performance, but this is the best way to do so far because of the core WP stuff. If you don’t like these functions, you would need anyway a filter at certain point, so why not call gettext filter which already exists? Many international websites already work thanks to this, so imo it’s not a good idea trying to re-invent something new as long as WP doesn’t provide a better API.

• This reply was modified 7 years, 3 months ago by herrvigg. Reason: typo and precision