SOLVED WITH PATCH S2 assumes css file is in root dir (result: pro forms are messed up)

#1

hello! Just updated to the new version and realized that the checkout form is incorrect for our business now since we only use PayPal.

I rolled my site back to the former version of S2member, but see that those fields are all there as well. I’m not sure what version changed the checkout form process.

I’d like to remove the credit card entry fields for the customer, and the coupons field (accept_coupons=0 already), along with the address fields.

I’ve already tried display:“none” for the id’s and classes but that’s a little unwieldy. Although I’ll gladly accept help with that if that’s the only way to do this!

I also noticed that the password strength indicator isn’t showing - only the words saying “password strength indicator”.

Any help with this would be appreciated! THANKS!

#2

The latest release doesn’t change anything to the PayPal pro-form.

I also noticed that the password strength indicator isn’t showing - only the words saying “password strength indicator”.

That sounds like you have a javascript problem, which would explain the weird display and behavior of the form.

In your browser, open the console and see if there are any errors mentioned, please.

:slight_smile:

1 Like
#3

Ah that makes sense. Here is the error given:
(index):1 Refused to apply style from ‘https://cognitiveresults.com/wp-content/plugins/s2member/s2member-o.php?ws_plugin__s2member_css=1&qcABC=1&ver=190822-190822-2953196720’ because its MIME type (‘text/plain’) is not a supported stylesheet MIME type, and strict MIME checking is enabled.

#7

Just tried disabling all plugins except S2member and the pro-form still had both stripe and paypal fields present.

I’ve taken down the shortcode on my payment pages for now but I really would appreciate your help in getting this resolved.

Also I updated to the latest version of S2 as well.

More info: my hosting provider said that with the latest version of WordPress there are more strict rules for the files and recommended a rollback to check if that would help. It did not.

It may be something to do with the MIME types and the WP rules - there is a plugin MIME plus or something but I don’t know how to use it.

#8

Update!! Here is the response from my host:

“That is an interesting error for sure. The MIME type message is a bit of a misdirection though. When we go to the path that is giving the MIME type error (https://cognitiveresults.com/wp-content/plugins/s2member/s2member-o.php?ws_plugin__s2member_css=1&qcABC=1&ver=191022-191022-987629129) we get the following message:

ERROR: s2Member unable to locate WordPress directory.

This seems to point to the plugin having a problem resolving the location of WordPress on the server. We recommend reaching out to the plugin developer to see if they have an update or workaround available.

We did some research and found this post - https://www.primothemes.com/forums/viewtopic.php%3Fp=59099.html - which is a bit older but does seem to point to a relevant topic. On our Cloud platform, the WordPress core files are not in the root of the site, so if s2Member is using a relative pathing to find it from where it might be in a vanilla WordPress installation, it will not find it there. We have chosen a more secure path by placing the WordPress directory in a more secure location but it can easily be found with WordPress/PHP constants and functions (https://codex.wordpress.org/Determining_Plugin_and_Content_Directories).

If S2Member has any questions, we are more than happy to help!”

So it looks like when I migrated my site into a cloud server, the path changed.

Is there anyway to fix this easily? Cloud servers seem pretty common these days.

Thanks,
Gillian

#9

Also from my host:

It looks like this issue has more to do with the s2member-o.php PHP file not being able to locate the WordPress core files. As Brandon has mentioned, we don’t keep these files in the root of the site as the plugin is expecting. Our decision to do so ensures that the WordPress core stays secure and is in line with WordPress security best practice.

Looking through the article linked below, you should be able to disable the use of this s2member-o.php file by adding a snippet of code. See bottom of article.

The gist of what they are recommending is creating an /mu-plugins directory within the /wp-content and then creating a php file named s2-hacks.php . Within that php file the following code can be added:

<?php
add_action("ws_plugin__s2member_after_loaded", "s2_hacks"); function s2_hacks()
    {
        $GLOBALS["WS_PLUGIN__"]["s2member"]["c"]["s2o_url"] = site_url("/");
    }
?>

You should be able to add this bit via SFTP. Would you mind attempting this fix and let us know if it works for you?

Additionally, it looks like the lead developer had intentions of fixing this functionality. It may be worth reaching out to their support team and referencing the article linked, to see if they have a more recent fix to implement."

THIS SOLVED IT!

1 Like
#10

Any chance of getting this fixed permanently? The original help article was from 2011 and the intention was to fix it back then. :slight_smile:

#11

Thanks for the updates! And I’m glad you sorted it out. Nice support from your hosting service.

I’m adding this to the to-do with your vote for it.

:slight_smile:

#12

@clavaque Looks like the same issue as this fix for another non-standard location.

1 Like
#13

Maybe I’ll eventually look at the commits to see when the server variable logic was introduced, but I finally just read Jason’s post from above and what he said was what I found without even knowing about that post (great job finding it, @Starbucksamore, and your hosting company rocks–I’ve never had that much support).

Maybe adding the server variable logic was the fix?

Since I’m not certain what changed since that post, all I can say was what I think I remember that I found was that it was mostly all happening with client-side JS. As Jason noted there had to be some way to find things.

The current version looks like it loads WP, etc. when called.

If I recall correctly, the traversal code was actually quite good. It kept going up directories looking for standard WP ones to go back down, but in my case Trellis (and in the case of the OP’s host), it’s in a random place and writing code to search the entire server would be very inefficient.

I didn’t see an easy pull request to make so I used the server variable.

JS has come a long way since this was written, though, but I’d vote to spend resources elsewhere for now, especially since there is a current workaround.

I’m actually confused as to why Raam would have said to disable it since it loads lots of (possibly) required stuff (db connections for ajax, etc.). If that wasn’t required, why have it?

#14

@Starbucksamore IDK if you can set server variables via .htaccess, but if your host is using NGINX the post I linked to above should be a good start for your host (even though it’s written for Ansible).

What’s basically happening is you’re on a page where full WordPress hasn’t loaded yet. There’s some JavaScript code to try to find WordPress, but the existing (well-written) code can’t do that because there are literally infinity non-standard locations for it. So, there’s a way to set the webserver to tell the browser (and JavaScript) where to find it.

Still not sure why Jason and Raam went this way when other WP plugins don’t seem to have the concern.

Your host may be able to set a server variable called WP_DIR that points to the path of your WP installation.

The instructions I wrote above set it for Trellis, but you’re probably not using that and it needs modification.