Jose
Forum Replies Created
-
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 MobileThe 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
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
Hi @shovonbk
From your comments I didn’t understand you were not able to see anymore the backend settings on an installation where you did use them. This was a bug. It wasn’t done on purpose.
I removed the backend settings on purpose for new installations, but not for those installations where those options were already used. Sorry for this inconvenience.
I suggest you update to v. 2.3.0. You will see again the backend settings pages. If for any reasons you still don’t see them let me know.Hi @jumbo
you can do it with the settings Custom URLs => Plugin By URL. I suggest you read here: https://freesoul-deactivate-plugins.com/how-deactivate-plugiins-on-specific-pages/plugin-by-url/
You will need to write parts of the URLs where you want WooCommerce active.
To match the processes like the checkout process, the “add to cart”…, I suggest you use *wc-ajax*In any case, I strongly suggest you to test all the WooCommerce processes after you use the Plugin By URL settings. Don’t forget also to add the endpoint URLs used by Stripe, PayPal…
Another method would be to disable WooCommerce in all the Post Types, but the products, and in all the archives, and then enable it on the WooCommerce pages. This this last method you would have less risks one of the processes don’t work.
I hope it helps.
Have a great day!
Jose
You don’t know the most used features of the plugin. I know it because I help the users, and most of them use the frontend features. Or do you think you know it better than me?
I don’t force anybody. As said, you can use a different plugin that has the backend features if for you buying a PRO license is too much money.
This is not really a decision. You decide when you can choose between different options. In this case, it’s simply not possible to go ahead with this project without money. You can say whatever you want, other users can cry all day long, but I can’t continue to work only for free.
And if I don’t see more sales, I will remove other features, or eventually remove the free version from the repository. That’s it. I hope it’s clear now.50% of the features? Really?
There are 2 features: Backend Custom URLs and Backend Singles. All the other ones are free, and they are a lot. As said who used the backend settings will still be able to use them. The difference will be ONLY ON NEW INSTALLATIONS.
I heard many times that the free version is enough and you don’t need the PRO one. Well, I need people buy the PRO version, in another case the free version can’t exist. This is why 2 features were removed from the free version, but ONLY FOR NEW INSTALLATIONS.
If this means that people give a bad review instead of buying the PRO version, the free version will totally disappear because it’s impossible to work on the free version if there are not enough sales of the PRO version. I hope this is clear for all the other users.
If FDP free without the backend settings is not enough for you, use a different plugin that gives those options.
You can install Plugin Organizer for example. It’s a very good plugin with a lot of features. There are also other very good alternatives like Plugin Load Filter.
Nobody is saying you have to use FDP. If it’s active on your site, better if you deactivate it.I suppose you are speaking about the deactivation of the plugins in the backend.
Of course, all those users who used those features still have them, even if they aren’t PRO users.
They are hidden only for new installations or if they were not used.“This is not right way do business…”. What’s your idea to do business? That other people work only for free and you use their work to earn money with your website?
Sorry, you were never a fan of FDP. I’ve never seen a nice review from you, and it doesn’t look like you were a PRO users. You have never contributed to this project.
Remember that people need to earn money for living.I will be honest. If I see other reviews like this one, FDP free will completely disappear, and only the PRO version will exist. For me, your review is totally inappropriate.
thank you for reporting this issue.
This PHP warning will dirty your debug.log file, but it has no impact on the functionality.
It will be fixed with the next version that will be published soon. I hope before 2-3 days.Until then, if your site is live, I suggest you disable the debug in wp-config.php.
Have a great day!
JoseHi @joefryfoto
you are welcome! I’m happy it worked.
About the WordFence alarm, I can only say that Freesoul Deactivate Plugins doesn’t write any .tmb directory outside the WordPress installation.
It writes the file wp-content/mu-plugins/eos-deactivate-plugins.php, and the folder wp-content/uploads/FDP. Inside the FDP folder, it stores its cache and writes its settings. Nothing else.Are you sure the .tmb is not written by something else?
Have a great day!
Jose