catnaveo
Forum Replies Created
-
I understand your mention and reference to the warning, and I was able to identify and correct the problem, though it took slightly longer than I’d have hoped because of the change being in two files instead of only one. The average user likely could not have done this.
However, fundamentally, deactivated plugins should not be running, and thus the viewpoint that leaving the auto_prepend_file in place on deactivation is not proper, irrespective of whether the installation is being moved. It should be handled differently than the removal of all configuration settings on deactivation.
If you’re moving to a new host or a new installation location, you may need to temporarily disable extended protection to avoid any file not found errors. Use this action to remove the configuration changes that enable extended protection mode or you can remove them manually.
What the above does not say is that even if you disable the plugin, that code will continue to be loaded and run from the plugin despite being turned off. It should be simple enough to keep one’s settings, but have the WAF properly deactivated when the plugin is deactivated, and re-enabled when the plugin is.
If you do not agree that deactivated plugins should avoid loading and executing code, then there is a problem with our fundamental understandings of the ecosystem in which the plugin exists. However, I am reporting this as I deem it to be a bug that a plugin, which is not active, is configured in such a way as to load and execute code despite not being active.
However, simply deactivating the plugin means it should be doing no work until reactivated, correct? Should it not then remove configuration changes that load WordFence before core WP? If the plugin isn’t active, it should not be getting run on every request.
I see there are checks for whether the WAF is disabled before it runs, but it’s only after bootstrapping and loading pretty much all of WF on every request. Is that not excessive if it’s just going to drop out because it is deactivated?
No deactivated plugin should impact the functioning of a site. Even basic troubleshooting has users disable all plugins and switch to a default theme to check for conflicts. If this were the case, it would appear to them that there was something wrong with WordPress itself.
Most users wouldn’t read the warnings, or think to check these things. I had already changed the paths in the .htaccess file, and neglected the .user.ini, which I seem to rarely even encounter on optimized sites for some reason. However, the warnings being on the options page also doesn’t help anyone whose site has turned into something that won’t load.
I’ve talked to the person who was responsible for the change, and things have been dealt with as a practice on our end, where it is only supposed to have been getting optimized during final steps. But it does still seem like a lot more code is being loaded and run for WF than should be when the plugin is deactivated. Something that many users would not know is happening.
We found that Redirection for Contact Form 7 was causing the problem, through dumb luck. Though it seems to depend on the version of the Redirection plugin.
Forum: Plugins
In reply to: [Conditional Fields for Contact Form 7] required fields block validationI’m currently experiencing this issue, and all reports seem to indicate a conflict with smart grid, which is not installed on our particular site.
Forum: Plugins
In reply to: [Contact Form 7] Behavior Change in Select Value Submitted DataIt is the RFQ page. And, as indicated in the last paragraph, it is a hooked function. I’ve included the majority of the relevant code (via gist), both as 7.5.1.7 where it worked one way, and after where it has new requirements.
It is using pipes to have different values than what is displayed in the form, which after some digging, I finally found a comment online about the front-end of the form not being where that was broken, as it uses the label as the value on the front, but uses the defined value by pipes on the back via posted_data. Since the label value is not the one we need, nor using, I cannot use
$_POST.It just seems an odd change to happen suddenly between minor versions. I’m trying to understand the change, and why it doesn’t appear to have been part of the changelog, since it is affecting a rather simple accessor of single value variables.
Forum: Plugins
In reply to: [Contact Form 7] Behavior Change in Select Value Submitted DataThe website is xactedm.com, but the impacted functionality is purely on the sending side, through hooked functions.