Jose Mortellaro
Forum Replies Created
-
Thank you very much @myjosephines !
Could it be that when you updated WordPress to 6.8.3, SiteGround cleared some cache that was causing the issue?
Is it now working with WordPress 6.9?
Honestly, I haven’t completely understood what was causing the issue. However, I suggest that if something similar happens again, you deactivate and delete Essential Form from the Plugins page and then install it again. This will give you a fresh installation of Essential Form.
Best regards
Jose
Many thanks! I’m glad you like the plugin.
This issue is a bit unusual. Could you check if there are any mu-plugins?
You can find them on the Plugins page → Must-Use.
I’m not saying this is necessarily the case, but nowadays, on some hosting environments, a “fresh” installation can sometimes include unexpected bloat without you realizing it.
Have you experienced this issue only on SiteGround, or also on other hosting providers?
Do you know the PHP version that is running on the server?
Best regards
Jose
Hi Nico, perfect. I’m happy that everything is clean now. Thank you for the information.
This explains why FDP wasn’t able to delete the mu-plugin file.
Just in case you need it when you contact the authors of WP Safe Mode, FDP tries to delete that file with this line of code:
wp_delete_file( WPMU_PLUGIN_DIR . '/eos-deactivate-plugins.php' );It uses the WordPress core function
wp_delete_fileand the WordPress constantWPMU_PLUGIN_DIR, without hardcoding the folder name.
Because of this, the conflict with WP Safe Mode can’t be solved by FDP. It has to be addressed by the authors of WP Safe Mode.There is no way for FDP to know that WP Safe Mode changes the folder name and doesn’t use WordPress standards to reference the new mu-plugins directory.
I also believe WP Safe Mode can cause conflicts with many other plugins that use the mu-plugins folder.
Have a great day!
Jose
Again me. Do you maybe have this plugin: https://ww.wp.xz.cn/plugins/wp-safe-mode/ ?
If you confirm this, I will test it and try to reproduce the same issue.
I also suspect it may cause conflicts with FDP because it manipulates the set of active plugins.Hi @gooloode
As I can see in your second screenshot, your mu-plugins folder is called wp-safe-mode.
It looks like you don’t have a standard WordPress installation. Do you perhaps have a plugin or something else that changes the default WordPress folder names?In any case, I suggest checking the wp-content/wp-safe-mode folder via FTP. You may find eos-deactivate-plugins.php in wp-content/wp-safe-mode.
I also see that you have 53 active plugins. You would really benefit from using FDP.
Would you like to try using it again? If you have specific questions about how to use it, feel free to ask me.For an easier FDP setup, I suggest first identifying the heaviest plugins using Code Profiler, and then using FDP to deactivate them where they aren’t needed. There’s no need to try to deactivate all unused plugins at once—focusing on a few heavy plugins will be much easier and still effective.
I hope it helps
Best regards
Jose
Hi @gooloode
Using FDP for the first time can be tricky. Have you tried reading the documentation?
https://freesoul-deactivate-plugins.com/how-deactivate-plugins-on-specific-pages/Anyway, if FDP for any reasons wasn’t able to delete the mu-plugin, you should:
- See a clear notification in your backend.
- Be able to access the file
wp-content/mu-plugins/eos-deactivate-plugins.phpvia FTP.
If you don’t see them, it means there is no FDP mu-plugin left on your site.
The 100% safe way to delete it is to remove the file
wp-content/mu-plugins/eos-deactivate-plugins.phpvia FTP. If you don’t see the file, there’s nothing to delete.If via FTP you don’t see that file, but still see it in the mu-plugins page of your backend, it means the pages of your backend may be served by full-page cache. Be careful. Having cached backend pages would not be safe.
I hope it helps.
Best regards
Jose
Thank you so much for the amazing review Kristi!
We’re glad we could resolve the issue quickly. Feedback like this truly motivates us to keep improving and supporting the plugin.
Thanks again for your support!
Hi @oceanbuddha
The issue has been fixed in version 1.2.7, so please make sure you update the plugin to the latest version. Remember to clear any cache, if applicable.
If everything works fine and you’d like to support the project, please consider leaving a review. It would be really appreciated!
If, for any reason, you still experience issues, don’t hesitate to reply.
Have a great day!
JoseHi @oceanbuddha
Thank you for reporting this issue.
It appears that the problem occurs specifically in Firefox.
We were able to reproduce the same issue on our development installation. We are working on a fix and will publish a new version as soon as it is ready. At the moment, I can’t provide an exact timeline, but we will do our best to release it as soon as possible.
Best regards,
JoseThank you so much, @giangel84. I really appreciate that you took your time to help me.
You really made my day!@binarywc, as he already said, @giangel84 is not part of the FDP team. He simply wanted to help and share his opinion.
This is for everyone: I never provide a MySQL command without performing the necessary tests to be sure it won’t cause irreversible issues.
The procedure used to clean the database when the plugin is deactivated has been tested, and as far as I know, it has never caused any issues.A MySQL command, if incorrect, can be dangerous. Changing something in the database is very different from causing a code issue. A code issue can usually be fixed easily, while fixing a database issue is much harder and often requires restoring a backup.
If I have the time to perform all the required tests, I will add the MySQL command to the documentation.
Now we can really close this thread.
If @binarywc decides not to use FDP, it won’t be the end of the world. When you sell a product or a service, it’s impossible to make 100% of users happy. In this case, he is not happy with our support. That’s fine, he can use another plugin. No problem.
Instead of spending more time on this, I prefer to dedicate my time to helping other users who need it.
Best regards to everyone.
@giangel84, thank you again. That was very kind of you.
Forum: Plugins
In reply to: [Plugin Check (PCP)] Non-global variables seen as global variablesthank you David
Honestly, I don’t have the time to help directly with the development, but I can share an idea.
Right now you have Errors and Warnings. Why not add a third checkbox, like Beta or something similar?
When there are many warnings that may be false positives, it becomes difficult to spot the warnings that are not false positives. Being able to hide the “Beta” warnings would be very helpful.
You are welcome @mcdeth
Do you need to collect the email on every page?
If you need the email field only on a specific page, another option could be to allow a heavier plugin to load only on that page and disable it everywhere else. You could do this with Freesoul Deactivate Plugins.
If you use a newsletter plugin that is connected to an external service such as Mailchimp, for example, any spam issues are related to that platform, not to your website.So you could use FDP to mitigate the performance impact, and an external service to collect the email addresses.
This was just a suggestion. You will surely know better than I do what the best solution is for your case. I simply wanted to make you aware that solutions like Freesoul Deactivate Plugins exist to help with issues caused by heavy plugins.
If, in the future, I add the possibility to show only the email field, I will reply again in this thread. However, I don’t think this will happen soon, and honestly, I can’t say for sure whether it will be implemented.
I hope it helps
Best regards
Jose
Hi @mcdeth
Unfortunately, at the moment this is not planned, and I’m not sure it will be implemented in the future.
May I ask why you want to do this? Usually, the email address is collected via a newsletter opt-in.
I’m asking because I’d like to understand whether other users might also be interested in this feature.
Best regards
Jose
You’re welcome, Adrian!
If the rewrite rules are flushed only when you edit a map, that’s totally fine. In this case, it was a false alarm.
I’ll try to improve this check to avoid this kind of false alarm in the future.Thank you again for reporting this issue.
I would not ask them to reduce the requirement to flush the rewrite rules if you confirm that they flush it only when you edit the map.
Best regards
Jose