Jose

Hi Tiffany,

thank you for the information. This is helpful to understand the situation.

Freesoul Deactivate Plugins doesn’t disable any plugin for a post that has the “draft” status.

This is because a draft can’t have a pretty URL. You can reach it only if you are logged in with a URL that looks like https://yoursite.com/?p=324, where in this example 324 is the ID of the post.

FDP needs an URL like https://yoursite.com/sample-post-name/. It’s so because FDP saves the settings considering the parts of the URL you have after https://yoursite.com/.
As written in the plugin page at the section “Requirements”:

Only the permalink structures “Day and name”, “Month and name”, “Post name” and the custom ones ending with “%postname%” are supported for permanently deactivating plugins (they are also better for SEO).

However, you can still have a preview of the page to see how will be when it’s published.
On the preview, you will see the plugins that will be disabled when you publish the post.
You need to click on the lens icon that is after “Current Theme” in the action buttons bar.
See the following picture for clarification.

The FDP popup says

… It was not possible to get the disabled plugins. Maybe this page redirects to another page or something went wrong.

this is because for getting the information, FDP tries to go to an URL that looks like https://yoursite.com/sample-page-name but that page redirects to a error page 404. The only URL that can be visible would be an URL that looks like https://yoursite.com/?p=324, where in this example 324 is the ID of the post.

I agree that this is something not clear that the user can’t know. However, this is how it works.
I will try to warn the user in the backend when you have a draft post.

I suggest you check the post with the lens as suggested above. When the post is ready, check it again after it’s published. It should work then.

The only thing that should not be as you described is that when you have a privately published post, contrary to what you said, it should work. I’ve right now tested again a privately published post, and it works without problems for me.

I also suggest you to create a new post that is totally published, and check if FDP disables the right plugins. If not so, may be there are other settings of FDP that are overriding the Singles settings, like the Custom URLs.

I hope it helps.

Have a great day!
Jose

@tiffany-clark

Hi Tiffany,

thank you for the update. You are welcome!

Have a great day!

Jose

@tiffany-clark

Hi Tifffany,

I suggest you:

• Check the FDP notifications that you find on the top right of the FDP settings page.
  See the following picture for clarification: https://freesoul-deactivate-plugins.com/wp-content/uploads/2023/01/freesoul-deactivate-plugins-notifications-center.png
  In some conditions, FDP doesn’t disable any plugin to avoid serious issues. If one of those conditions were triggered you will find a notification. If you find it, please let me know what it says.
• Clear any cache. Maybe you are seeing an old cached version of the page. Or visit the page after adding a unique query argument to the URL. Let’s suppose your page is reachable at https://yoursite.com/sample-page/. Visit it at https://yoursite.com/sample-page/?sdfsdf=1. By doing this you will probably bypass the cache.
• Check if Embedly added any mu-plugin. FDP can disable standard plugins, but not mu-plugins. You can check it by going to Plugins => Installed Plugins => Must-Use.
  There you will see at least freesoul deactivate plugins [fdp] which is the mu-plugin installed by FDP. If you see another mu-plugin that looks like be installed by Embedly, then that mu-plugin can’t be deactivated by FDP.
• Go to the FDP Singles settings page. Open the action buttons bar on the row related to the page where you have issues. Then click on the question mark, and tell me what you see on the popup. See this picture for clarification: https://freesoul-deactivate-plugins.com/wp-content/uploads/2021/12/fdp-action-buttons.png. I mean the question mark that you see before “Current Theme”.
• Use FDP to disable a different plugin, and check if with the other plugins it works.
• If you can do it, temporarily publish the website. Save the FDP settings again, and check again to see if it works. Then you can again make the website private. This is to check if the private status of your website has somehow something to do with the issue.
  
  
  
  
  I hope it helps.
  
  Have a great day!
  Jose
  @tiffany-clark

You are welcome @ozguy

Have a great day!

Hi @ozguy

the plugin considers the privacy policy page that you set in WordPress.
From the backend admin navigation => Settings => Privacy.

Let me know if you still need help.

Have a great day!

Jose

You are welcome @sandyrig

I’m happy that it works.

Have a great day!
Jose

Hi @sandyrig

this is because FDP doesn’t disable any plugin if there is a Post request and you don’t set anything in Actions => Post Actions Recorder
You can disable plugins depending on the Post requests only with the PRO version. You can read more details here: https://freesoul-deactivate-plugins.com/how-deactivate-plugiins-on-specific-pages/cleaning-ajax-post-actions/

However, already the free version gives you the possibility to ignore the Post requests by adding this line of code in wp-config.php:

define( 'EOS_DP_ALLOW_POST', true );

Add it before the comment /* That’s all, stop editing! Happy publishing. */

Then I suggest you to check everything on your website. Check any kind of process like form submissions, checkouts…
This is not the default because many plugins call the homepage with a Post request during their processes.
If for example you have disabled plugin A on the homepage, and plugin A manages the submission of a form that you have on the contact page, then when you submit the form the process will fail because plugin A will call the homepage, but the same plugin is disabled on the homepage.
This is why FDP doesn’t disable any plugin if there is a Post request.

The policy behind FDP is precautionary when possible.
If there is a doubt between having something that does not work and a slower page, the solution that guarantees the functioning is always chosen.

I hope it helps. If something is not clear or it doesn’t work after allowing the post requests, let me know.

Have a great day!

Jose

Hi @debh89rug

I see in the page that you have duplicated elements. For example, you have two navigations and footers…
If you mean that for “lost the layout”, I’m almost sure this is not caused by Specific Content For Mobile.
Probably, you already had that problem but the server was serving old version of the cached pages, and those pages were ok. When you saved the mobile version, the cache was probably deleted, and now you see the problem.

First, I would confirm if Specific Content For Mobile is really the cause of this issue.
To do that, I suggest you deactivate Specific Content For Mobile. Clear the cache, and check again the pages were you have the issue.

As a side note, I see that on Firefox the HTML has different CSS classes. For example, the body has a lot less classes than on Chrome. Did you know that? This can’t be caused by SCFM. I can ensure it 100%.

Let me know if after disabling SCFM, and clearing the cache you still have the same issue.

Have a great day!
Jose

Hi @bufisys

thank you for the information and for your solution.

Theoretically, you don’t need that script. You should find this in your .htaccess file:

# BEGIN Specific Content For Mobile
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} Mobile|Android|Silk/|Kindle|BlackBerry|Opera\ Mini|Opera\ Mobi [NC]
RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} !scfm-mobile
RewriteCond %{QUERY_STRING} !wc-ajax
RewriteCond %{QUERY_STRING} !^$
RewriteCond %{REQUEST_URI} !\.
RewriteRule ^(.*)$ %{REQUEST_SCHEME}://%{HTTP_HOST}%{REQUEST_URI}\?%{QUERY_STRING}\&scfm-mobile=1 [L,NS,R=301]
RewriteCond %{HTTP_USER_AGENT} Mobile|Android|Silk/|Kindle|BlackBerry|Opera\ Mini|Opera\ Mobi [NC]
RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} !scfm-mobile
RewriteCond %{QUERY_STRING} !wc-ajax
RewriteCond %{QUERY_STRING} ^$
RewriteCond %{REQUEST_URI} !\.
RewriteRule ^(.*)$ %{REQUEST_SCHEME}://%{HTTP_HOST}%{REQUEST_URI}\?scfm-mobile=1 [L,NS,R=301]
</IfModule>
# END Specific Content For Mobile

The code above is added by SCFM to add exactly the query string you are adding via JavaScript.

If the redirect is done from the .htaccess file, it will consume practically zero. On the contrary, if you do it via JavaScript, PHP + MySql have to run before building the page, then the page is sent to the browser, and only when the browser parses your script you have the redirect. This is bad for performance.

You should check your .htaccess file, and if you don’t find the code described above, we should try to understand why you don’t have it.
If you don’t find that code, I suggest you:

• Be sure you have the latest version of Specific Content For Mobile
• Disable and enable again (without removing it because you would lose the settings) Specific Content For Mobile
• Visit the backend page Settings => Permalinks
• Check again the file .htaccess
• Delete the browser cache
• Delete the FlyingPress and FlyingCDN cache

Please, let me know if you can see that code in your .htaccess file.

Have a great day!

Jose

Hi @bufisys

thank you for reporting this issue. Let me know if they have any questions about the plugin.
Have a great day!

Jose

You are welcome @jumbo !

Have a great day!

Jose

Hi @midihead

you don’t have to apologize. I’m happy that you reported this issue. I think it may not be clear also to many other users.
Thank you very much for your opinion. I also think that making it unclickable makes more sense. However, I will also ask some other people to provide a little statistic on what users prefer the most.

Have a great day!

Jose

Hi @ckov1
I corrected the code for the .htaccess file.
Here a new version of the code:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} Mobile|Android|Silk/|Kindle|BlackBerry|Opera\ Mini|Opera\ Mobi [NC]
RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} !scfm-mobile
RewriteCond %{QUERY_STRING} !wc-ajax
RewriteCond %{QUERY_STRING} !^$
RewriteCond %{REQUEST_URI} !\.
RewriteRule ^(.*)$ %{REQUEST_SCHEME}://%{HTTP_HOST}%{REQUEST_URI}\?%{QUERY_STRING}\&scfm-mobile=1 [L,NS,R=301]
RewriteCond %{HTTP_USER_AGENT} Mobile|Android|Silk/|Kindle|BlackBerry|Opera\ Mini|Opera\ Mobi [NC]
RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} !scfm-mobile
RewriteCond %{QUERY_STRING} !wc-ajax
RewriteCond %{QUERY_STRING} ^$
RewriteCond %{REQUEST_URI} !\.
RewriteRule ^(.*)$ %{REQUEST_SCHEME}://%{HTTP_HOST}%{REQUEST_URI}\?scfm-mobile=1 [L,NS,R=301]

this is to remove a redirection when the URL has no query strings.
The code above will be added by the new version of SCFM.

Have a great day!

Jose

Hi @ckov1

thank you for reporting this issue.
The rewrite conditions and rules are added by Specific Content For Mobile to prevent the issue with the cache. When you have a caching system that doesn’t distinguish between mobile and desktop, you have issues.
By adding ?scfm-mobile=1 to the URL when the page is visited by a mobile device, you avoid that issue, because the cache for https://samplewebsite.com?scfm-mobile=1 will be different by the cache served fro https://samplewebsite.com.

The intention was good, but honestly I didn’t realise you can have issues with Post requests.

I suggest you try with this rules in .htaccess:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} Mobile|Android|Silk/|Kindle|BlackBerry|Opera\ Mini|Opera\ Mobi [NC]
RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} !scfm-mobile
RewriteCond %{QUERY_STRING} !wc-ajax
RewriteCond %{REQUEST_URI} !\.
RewriteRule ^(.*)$ %{REQUEST_SCHEME}://%{HTTP_HOST}%{REQUEST_URI}\?%{QUERY_STRING}\&scfm-mobile=1 [L,NS,R=301]
</IfModule>

I tested the WooCommerce checkout after adding RewriteCond %{REQUEST_METHOD} !=POST and it works for me.
That line is saying that ?scfm-mobile should be added only if there are no Post data.

This is the code that the next version of SCFM will add to the .htaccess file.
We need those rules because 99.9% of the support requests are because many websites have a caching system that doesn’t distinguish between desktop and mobile and they don’t know ho to fix it.

If you still have issues, please let me know.

Have a great day!

Jose

Hi @midihead

thank you for reporting this issue.
Those links have no URL. This is why if you click on them you refresh the page.
They have no URL because they are related to the editing page of whatever single post or single post type.
Let’s do an example. Let’s consider “Edit Single Post”.
Imagine you have the blog posts “Hello World!”, “Hello WordPress”, “Hello Something Else”.
When from the main admin navigation you go to Posts, and you click on “Edit” on one of those blog posts, then you are in the editing page of that post.
“Edit Single Post” is valid for the editing page of whatever blog post.
Maybe we could link it to the editing page of the last blog post. Do you think it would be better?
At the moment it links to anywhere, and it was better to make it unclickable. The fact that it is clickable even without linking to anywhere is a bug, but for me, it’s not true that in the editing page of the post, the plugins are not disabled. I’ve right now tested it again, and it works for me.
You can check the disabled plugins on the editing page of a post by doing as follows:

• Go to the editing page of the post
• Right-click with your mouse
• Click on Inspect
• Click on Console
• Check the list of plugins written after “*** PLUGINS DISABLED BY FREESOUL DEACTIVATE PLUGINS ***”

If you are an administrator that have the rights to activate a plugin, you will see that information.
Please, let me know if you still think that it doesn’t work.
I’m also interested to know if you prefer to link “Edit Single Post” to the last post, or let it unlinked.

If something is not clear let me know.

Have a great day!

Jose