danielspain

Hi, should we manually delete this files or it would be perjudicial? thanks!

that will be great! thanks in advance!

I understand that it is a problem of how wordfence proceeds and not yours, anyway I think it would be a good idea to change the release to 3.5.3 (if it does not represent a big effort for you), since wordfence is used for integrity check of plugins by many people who do not know how to proceed in front of the problem (especially because wordfence labels the problem as serious in mails etc…). There may also be people who updated to 3.5.2 before the fix…anyway whatever you want to do, thanks for the excellent plugin!

• This reply was modified 6 months ago by danielspain.

Hi, i’ve see the culprit was modified from(in trait-woe-core-extractor-ui.php):

? ? ? ?return apply_filters(“woe_get_product_custom_fields_values”, $values, $field);

to:

? ? ?return apply_filters(“woe_get_product_custom_fields_values”, $values, $key);

and that fixed the issue, i’ve updated the plugin in many sites using wordpress, and the patch is present and the log error doesnt appears anymore. But wordfence analysis complains that the plugin is modified from original…i’m confused because if i download the plugin from plugin page, it’s the modified and patched version…but wordfence insists that the unpatched line is the original from plugin and marks a security problem fo using a modified version…could you help doing something in the wordpress repo of the plugin?

thanks for the fast fix!

thanks, it’s working now without the log, is it now safe to update other sites via wordpress plugins updates, it it patched now in the official wordpress repo?

thanks for the fix!!, 2.6.9 no longer write any log!

thanks, but how could i patch the plugin to avoid all the debug logs in the meantime until you could make it optional?…or how can i add custom code in my functions.php to avoid the logging with the filter? It would be very helpful to make all this logs optional…thakns again

yes, this would be very helpful!!!!!! please make it optional, it causes debugging of other problems non related to loco very very hard cause the log is huge. Some hostings force the writing of log files in production sites, even when wp debug is off, so it would be really really awesome to make this optional, i hope you could come with a patch or new version soon, thanks a lot!

Thanks a lot for the update. will you address the -Fix vulnerability (Thanks @petitphp) : Login Page Disclosure- that 1.9.15 supposed to fix soon(this time without the login/logout problem of 1.9.15 )?

I can online update to 1.9.15.1 manually by download, but this is a problem for some sites that only can update to the latest version that can be pulled from wordpress, could you fix the tag to do automatic updates to the fixed version? thx

Now it’s resolved, wp-toolkit no longer reports the problems. Thanks to the plugin maintainer fo the fix!

Patchstack now shows that the issue is fixed in 1.9.12 but wp-toolkit stills reports the problem…

Hello, perhaps the best thing to do is to have the maintainer of the plugin do it to report the correction correctly. What I don’t know is how to make wp-toolkit aware of the patch and version that is not affected (the current one) and not report it, because otherwise it will continue to mark the problem. I upgraded the plugin and rescanned the site with wp-toolkit and it keeps reporting it as unfixed even though it says it affects the previous version 1.9.11. It will be an ongoing problem if not’s fixed by wp-toolkit.

thx! the WPAL for woocommerce patched that i’ve downloaded worked like a charm. Do I need to do anything else with the main WPAL plugin? Was it safe to upload the patched WPAL for woo as it is? (it contained additional files/dirs different from the official release i.e. github dirs .gitignore etc.). thanks for always providing a solution!