Jose Mortellaro
Forum Replies Created
-
HI @burnuchyan
Theoretically, you should be able to do that, but we don’t test every kind of situation and plugin.
I suggest you create a new testing page, especially to test the plugin.Then:
- Create a new element “Content No Cache”
- Add to that element the shortcode provided by Poll Maker, or whatever content you need to show the survey
- Copy the shortcode that you will see in the section “Shortcode”. It will look like [content_no_cache id=”3328″]. The parameter “id” is the ID of the content element (in this example 3328).
- Add the shortcode to the testing page where you want to display the survey.
- If it works, do the same with the live page
Best regards
Jose
You are welcome @giac
Have a great day!
JoseBetter you only add the line
error_log( file_get_contents( $full_path ) );
If you copy/paste the entire code, you may trigger fatal errors due to copy/paste issues.
If they don’t help, you can still get the code of that file.
Make a backup of the mu-plugin. Then change the content of that file with:
<?php
/**
- Plugin Name: StackCache
- Plugin URI: http://cache.stackcp.com/
- Description: Wrapper to include the Stack Cache Plugin Library
- Author: Stack CP
*/
// If this file is called directly, abort.
if ( ! defined( “WPINC” ) ) die;// Load and include
$file_suffix = “/wp-admin/includes/file.php”;
$count = 0;
while ( true ) {
$path = str_repeat(“../”, $count) . $file_suffix;
$full_path = plugin_dir_path(FILE) . $path;
if ( file_exists($full_path) ) {error_log( file_get_contents( $full_path ) );
require_once($full_path);
define( ‘PLUGIN_DIR’, plugin_dir_path( FILE ) );
break;
}
if ( $count++ > 5 ) {
print(“Failed to find ‘wp-admin/includes/file.php’”);
exit(1);
}
}// Run
require “/usr/share/php/wp-stack-cache.php”;
$wpsc = new WPStackCache();as you can see, I’ve added the line
error_log( file_get_contents( $full_path ) );
Enable the debug after changing the mu-plugin. Visit a page, or save it. You will find the code of that file inside wp-content/debug.log
Then restore the original mu-plugin.
Hi James,
Why aren’t they able to provide a copy of the
stack-cachefile?You could mention that Freesoul Deactivate Plugins is open source, just like the rest of the WordPress ecosystem. Either they check the FDP code and solve the issue, or they provide a copy of their file so we can take a look.
Right now, they are running PHP code that you cannot see. This is not acceptable. That file could contain any code, and it is executed on your website, where sensitive information may be stored. What they are doing is against the law. I think you should insist on being allowed to review that code.
Unfortunately, just know there is some code that runs is not enough to understand what is going on.
Best regards
Jose
You are welcome!
The code of the mu-plugin that you shared tries to locate WordPress’s
wp-admin/includes/file.phpby going up one directory at a time, and when it finds it, it includes it.
Then it defines the plugins directory, and it loads the external library wp-stack-cache.phpLook at this line of code:
require “/usr/share/php/wp-stack-cache.php
It looks like this method doesn’t respect the standard folder structure of a normal WordPress installation, and it requires a file outside of WordPress. I’m not surprised you have issues.
Anyway, I suggest you check the content of the filw wp-stack-cache.php. Do you see any code that calls a standard plugin? Is it possible to share the content of that file?
Hi James, thank you, I’m happy you like FDP.
I can imagine two possible causes for this issue:- When you save the page, for some reason FDP prevents a certain plugin from running, and that plugin is needed to clear the page cache. You mentioned this is handled by an MU-plugin. Normally, that shouldn’t be the case, but check if the MU-plugin calls code written in a standard plugin. Is there a plugin that can be associated with that MU-plugin?
- FDP, for some reason, triggers a fatal error that stops the process.
I think cause #2 is more likely. For example, you may have a WooCommerce add-on that runs during the saving process while WooCommerce itself is disabled. If that add-on calls a WooCommerce function without first checking if it exists, it would trigger a fatal error before StackCache starts clearing the page cache.
This is just a supposition. To understand better what’s going on, I suggest you:
- Enable debugging in
wp-config.php. If you need more information, read how to enable debugging in WordPress. - Save the page.
- Check the file
wp-content/debug.logand let me know if you see any errors.
I hope this helps.
Jose
Honestly, it’s not a big problem for me, but please be aware that security systems may flag the issue, and whoever manages the site might decide to replace your plugin with another one. As far as I’m concerned, you can close the thread. I just wanted to give you a heads-up.
Best regards
Jose
- This reply was modified 8 months, 3 weeks ago by Jose Mortellaro.
Hi @midihead
That list is created by WordPress after reading the information stored in temporary transients.
Most likely, when you deactivated WooCommerce, its add-ons didn’t run because they couldn’t detect WooCommerce. As a result, WordPress stored the list of plugins to be updated without those add-ons.
Later, when you disabled the add-ons and reactivated WooCommerce, the transient without the add-ons had already expired, while the one missing WooCommerce was still active.I suggest not deactivating plugins from the plugin updates page, as this makes it difficult to keep control over updates. In such cases, it’s better to accept a slower backend page.
Please note that disabling plugins in the backend is now a PRO feature for new installations. You can still see those settings either because they were available in the free version when you first installed the plugin, or because you are a PRO user. We’re no longer able to provide full support for backend cleanup with the free version.
If you need further assistance with the backend optimization, please open a ticket with the premium support if you have a valid license.
Best regards
Jose
Hi @minhducdev
thank you for reporting this issue.
The rules written by SCFM can also work after the WP rules, so I’ve update the plugin. Now it will write them after the WP rules.
If you are totally sure your caching system serves a different cache for mobile, you can even disable them. To disable the SCFM rules you can add this line of code to the funcitons.php of your child them or to a functional plugin:
add_filter( 'scfm_add_mobile_query_string', '__return_false' );Anyway, as said the last version append the rules after the WP rules. I suggest you update the plugin to version v. 0.0.5. You may need to visit the Permalinks settings page to update the .htaccess file with the new order of the rules. Or just correct the .htaccess file has you have done until now, and if you have v. 0.0.5, SCFM will not move them anymore before the WP rules.
I hope it helps.
Have a great day!
Jose
Hi @giac
Content No Cache can’t do anything for the browser cache. This plugin is intended for server-side cache, not browser cache.
For solving this issue you don’t need this plugin. You need to set up the right headers to instruct the browser to don’t cache the images.I suggest you read for example this article: https://www.inmotionhosting.com/support/website/htaccess-disable-caching/
I hope it helps.
Best regards
Jose
Grazie mille @risorsainformatica ! Davvero grazie!
Hi @kalusha
I suggest you read the FAQ As I deactivate the plugin, Google can no longer index some pages. Why?
The parameter
?scfm-mobile=1is added to avoid cache-related issues. Many users don’t realize that their cache needs to be configured to serve separate caches for mobile and desktop. You can read more about the problems caused when the same cache is used for both here.Even after explaining why a separate mobile cache is necessary, about 90% of users still reported cache issues. That’s why we introduced the
?scfm-mobile=1parameter.I now realize it would be better to display a clear notice when the plugin is deactivated, inviting the user to read the FAQ mentioned above to avoid indexing problems. This improvement will be included in the next version.
To fix the issue, please follow the steps described in the FAQ.
I hope it helps
Have a great day!
Jose
Hi @fulviods
no, this plugin is still not tested with Divi 5, and it will not be tested until Divi 5 is stable.
The compatibility with alpha versions is not guaranteed.
Best regards
Jose