isarisar

Thanks, for the desktop menu that indeed resolved the problem. The z-index was (now apparently no longer) required for a cookie banner issue.

Unfortunately, the issue remains for the mobile menu (ie. narrow window widths): The menu was opening upwards, now it does nothing. Incl. not toggling the little arrow, as if the plugin’s JavaScript was having issues. Every click now will also create a separate script element that calls some googleads.g.doubleclick script? (That’s not ours?)

Hi Bruce,

looking at it again a few hours later, there’s indeed some 400MB more free, and all but one of the files gone.

However, there were still some thumbnail corpses of them lying around, all with a -200x### or -300x### name suffix. I deleted those manually.

Also, is it possible to…

2. … have checkbox values as grid/multiple per line? (Example: 2/3 rather than 1 per line)

3. … overwrite the text values displayed for these checkbox values? (Example: “0 11mm” instead of “11mm”)

4. … combine multiple values into one shown option? (Example: 3 ‘color’ attributes “orange/red”, “orange/yellow”, “orange/green”. Goal: Have them three shown as a single “orange”)

• This reply was modified 2 years, 5 months ago by isarisar.

Ah, that makes sense then. Thanks!

Happened 6 times in less than 40 minutes now.

For now I’ve shuffled the SET parameters (while retaining the placeholder order, ofc) in the hopes of at least getting to know whether it’s a bug particular to one of the three plugins.

edit: It’s with Woocommerce itself. Though I guess the other two don’t actually run their own ActionScheduler anyway if WC is running.

• This reply was modified 2 years, 6 months ago by isarisar.
• This reply was modified 2 years, 6 months ago by isarisar.

Though looking at the code, the bugged check of the erroneous pathinfo call is still there, just “hidden” as second check in a new && evaluation:

$base_url = str_replace('.' . pathinfo($base_url, PATHINFO_EXTENSION), '', $base_url);
…
if (strpos($abspath, $base_url) === 0 && is_dir($base_url))

IDK if your dev knows more about how the function is called, but that means this check still could never work. Since that 2nd check would continue to fail with the original warning even if the 1st check comes true, the overall intended protection will never be effective.

Can’t. Post SMTP is 2.1.7, PHP 8.1.8.

PHP Fatal error:  Uncaught TypeError: get_class(): Argument #1 ($object) must be of type object, string given in /srv/wp-content/plugins/post-smtp/Postman/Postman-Diagnostic-Test/PostmanDiagnosticTestController.php:207
Stack trace:
#0 /srv/wp-content/plugins/post-smtp/Postman/Postman-Diagnostic-Test/PostmanDiagnosticTestController.php(256): PostmanGetDiagnosticsViaAjax->getFilters('wp_mail')
#1 /srv/wp-includes/class-wp-hook.php(307): PostmanGetDiagnosticsViaAjax->getDiagnostics('')
#2 /srv/wp-includes/class-wp-hook.php(331): WP_Hook->apply_filters('', Array)
#3 /srv/wp-includes/plugin.php(476): WP_Hook->do_action(Array)
#4 /srv/wp-admin/admin-ajax.php(187): do_action('wp_ajax_postman...')
#5 {main}
  thrown in /srv/wp-content/plugins/post-smtp/Postman/Postman-Diagnostic-Test/PostmanDiagnosticTestController.php on line 207

I recall reporting that exact same Diagnostics error some months ago and it getting fixed?

edit: yes, 3 months ago here

• This reply was modified 2 years, 6 months ago by isarisar.

grep‘ing for the SQL query, other than WC there are two plugins containing the same code:

• WP Rocket 3.12.0.4
• WPForms Lite 1.7.6

Though there might be more warnings in the file as the linter aborts on the first.

I suppose this will become a deprecation with 8.2 and error in 9.

Hi @petredobrescu,

thanks for the fix!

Based on a straightforward replacement (no other options selected), the warning is now indeed gone.

[Unrelated: There’s a “Remove after replace!” option at the bottom of the “Select Replacement Media” form. I’m afraid that option isn’t self-explanatory and so doesn’t tell the user what it will actually remove.]

Hi @haseeb0001,

it’s not an internal diagnostic, I just ran php -l (with 8.1) on our plugin directory. It’ll give you that error.

That linter aborts on the first error, so there might be others.

I forgot: Since it’s $_GET the right filter method would probably be filter_input{_array}, not filter_var{_array}.

Anyway, as of now, the functions calling sanitize_text_field($_GET) are obviously broken.

The updated lines are for search_join…

$join .= ' LEFT OUTER JOIN ' . $wpdb->postmeta .' AS post_metas ON ' . $wpdb->posts . '.ID = post_metas.post_id AND post_metas.meta_key = "yikes_woo_products_tabs"';

… and for search_where:

'('.$wpdb->posts.'.post_title LIKE $1) OR (post_metas.meta_value LIKE $1)', $where

No such errors since.

Hi @wfpeter,

thanks for the status. I’ve also asked the Loco Translate dev:

• They wrote that WordFence’s POT file is misnamed (.po instead of .pot), meaning translation plugins don’t find it by default.
• I tend checked the file manually: There is an “incorrect password” string in it, but it’s the wrong one. Supposedly, the second proper one needs to be added to that POT file. There are perhaps 200 other strings missing.
• Without that way, I had to resort to RupertH2O’s login_errors filter.

Thank you. Unfortunately the relevant line indeed isn’t in that POT file.

I’ll have to go with RupertH2O’s login_errors filter until WordFence fixes this.