When is this very basic bug going to be fixed?

In our testing WPtouch and WPtouch Pro are fully compatible with WordPress single site and multisite installations installed anywhere on a server.

Because every WordPress configuration is unique with its themes, plugins, and customizations, issues that arise need to be tested specifically for that installation. In general, the best place to start is by troubleshooting for conflicts that are contributing to the issue. Conflict testing includes testing themes as well as plugins.

Please be aware that dedicated support is only provided for BraveNewCode’s paid products. Free products are community-supported with our assistance.

Right, so you don’t fix basic bugs unless the user pays. Great!

It does work fine in a subdirectory for everything I’ve tried, except that logging in and posting comments don’t. Try logging in on a site installed in a subdirectory: it goes to login.php in the site root, instead of in the WordPress directory. This is very clear cut: this simple test proves unequivocally that your plug-in assumes login.php is in the site root, even if it is actually in a subdirectory.

What’s more, IlanK’s fix above proves unequivocally that it does the same for comments.php – adding the WordPress subdirectory to your comments.php URL code makes it work, which proves absolutely that your plug-in assumes comments.php is in the site root, even if it is actually in a subdirectory.

This is a very basic bug which must be fixed.

I know that you people don’t want to support the free version, but I must express my feelings about this, because this specific policy is preventing me from purchasing your product.

1) You see, I have a problem and your denial of the problem to at least two other people in your forum (after ignoring them at first), tells me that the problem may exist in the Pro version, but I have no way of finding out without having already spent my money on it.? Then what if it does?? Then what?

2) You stated in the forums that it is “community supported”.? It’s not supported by you there.? That you’re just “present” (your wording).

But what are you present for?? Just to tell people that you’re not going to help them?? What good is your presence if you’re not going to do anything, or even accept bug reports?

While I can understand not providing priority phone/email support to free users, I cannot understand no support there at all.? How is the “community” supposed to fix problems in the WP Touch code, for example?? The “community” can’t fix bugs, yet you absolutely refused to acknowledge one from a free user in the forums.

3) Right in this thread, you said it works.

I’m telling you that it does NOT work!? I am having the exact same problem!? Is it coincidence that mine is also in a sub-directory?? Please!

You said it works with multi-site.? This isn’t a multi-site issue.

This is about a single site, where the blog is in a sub-folder.

Also, my son, who codes and is the one working on my blog, confirmed it before I even saw your forums and he came up with the following on his own;

He told me that my blog is in:

https://reflectiveresonance.com/pdblog

But your plugin is looking for the login.php page here:

https://reflectiveresonance.com/

And he said it’s coded into the plugin and there’s nothing that can be done about it by him.

*** So the bottom line is; Your plugin DOES have this problem and ONLY YOU GUYS can fix it, NOT “the community”!

Also, it is NOT my site’s fault!? It is the plugins fault!? There’s nothing in my site telling it to look there and everything else works, but no one can comment, probably because no one can log in.

Does this problem exist in the Pro version?? I don’t know.? But you won’t admit it if it does and you’ll blame my site.

One thing for sure is, I’m not going to pay to find out that it does!

This is a problem when the Blog is IN A SUB-DIRECTORY.

Support is provided for individual WordPress/WPtouch Pro installations (i.e. your specific installation) for customers who have purchased a support license. Because the issue you’ve reported cannot be reproduced in our test installations, you require individual support for troubleshooting your specific WordPress installation. This is beyond the scope of services for BraveNewCode’s free products.

You can start your search for the source of the issue by reviewing your .htaccess file for conformity to the WordPress recommendations as detailed in the WordPress codex: https://codex.www.ads-software.com/Giving_WordPress_Its_Own_Directory

If that looks as it should, you may move on to testing the components of your WordPress installation. To isolate which plugin(s) may be contributing to the trouble, deactivate all except WPtouch from within the WordPress Plugins area, clear your browser cache and local data then test. If WPtouch functions well, you may then enable the rest of your plugins one at a time, repeating the process, until you can identify which is/are causing the problem. You may choose to replace the conflicting plugin with another or upgrade to WPtouch Pro which has a feature that will allow you to disable the conflicting plugin within your mobile theme but leave your desktop theme intact.

Bug reports are logged and addressed according to severity, regardless of their source. Because the issue you are reporting is not reliably reproducible, it cannot be classified as a bug. It is not uncommon for a handful of users to share one particular plugin in common and for that conflict to arise in those few setups. Conflict testing should reveal the source of the issue if it is not related to the .htaccess file.

Actually, speaking of .htaccess, I tried an experiment: I put in a rule to redirect /wp-login.php to /subdirectory/wp-login.php, and guess what – login works with your plug-in! This proves absolutely that your plug-in assumes wp-login.php is in the site root.

You now have:

1) Three different people with sites in subdirectories experiencing the same problem.

2) I have demonstrated that your plug-in assumes WordPress is in the root in three different ways.

How much proof do you need that your plug-in has this basic bug before you will fix it? Like Zeuszoos, there’s no way I’m going to risk paying for this plug-in with such appalling support.

You proved my point. You just ignored it again.

As for “Pro”, you’ve already ignored a pay user’s bug report about this specific problem:

Look at the link above that the first poster provided.

You have user after user telling you the same thing, after disabling all other plugins.

When the blog is in a sub-directory, the login doesn’t work, because it tries to direct it to a login file in the root. This also means no one can comment.

This has nothing to do with “multi-site”. That’s totally different.

You are simply being stubborn and you don’t care about your users.

@zeuszoos: As per the Forum Welcome, please post your own topic.

Sorry about that. I’ll take care if it next time I’m on.

Just a quick note:

I moved my blog from a sub-directory, to the root and guess what? The plugin works perfectly now, login included!

Further and absolute proof that it is a bug in the plugin that only shows its head when the blog is in a sub-directory!

If it was my blog, then it still wouldn’t work!

YOU HAVE A BUG IN YOUR PLUGIN!!!

Okay, so now this bug has been demonstrated in no less than four different ways! It can’t get much more definitive than that, especially as Zeuszoos has now demonstrated that exactly the same site works in the root, but not in a subfolder.

For goodness sake, how much more proof do you need of this bug before you will fix it?

Hmm, and I was just about to get my wallet out