TJ
My Latest Replies (From Various Topics)
Author | Replies |
---|---|
Author | Replies |
Posted: Sunday Nov 10th, 2013 at 11:27 pm #60989 | |
|
|
They’re both written in PHP. |
|
Posted: Saturday Nov 9th, 2013 at 3:44 pm #60971 | |
|
|
You can copy the pertinent payment gateway template to your theme folder, then edit it there. This way you’ll avoid editing the s2member core files. But you’ll have to update the files every time s2member is upgraded as the file in your themes folder will take precedence over the default. Instructions for copying it over are here: In your template, look for the line that says:
then change “Create Profile” to whatever you want. The “Your Profile” text is only shown to logged in users. s2Member’s JavaScript changes this on-the-fly via JavaScript, and not within the actual HTML source-code. If you want to change “Your Profile” as well, then you’ll have to do so via JavaScript which needs to load after s2member’s own JavaScript in order to override its own override. Just target the ID of the div tag that holds the text you want to change. You can use jQuery’s text() function to accomplish this: Someone asked a similar question about changing button text a while back and I suggested a similar fix: By the way, the JavaScript .text() function can be used for both the “Create Profile” and “Your Profile” scenarios. This way you can avoid copying over the templates. It’s probably safer to do it with just JavaScript anyway. You can either put this in your own script file, or load it as a separate JavaScript snippet by sticking something such as the below in your functions.php file:
|
|
Posted: Saturday Nov 9th, 2013 at 3:29 pm #60970 | |
|
|
The newest version (131109) now lazyloads the s2member JavaScript in the footer instead of in the head of the document. It sounds like your JavaScript app is loading before s2member’s JavaScript downloads and/or initializes. You’ll have to configure you script to load after s2member. If you’re using “wp_enqueue_script” to load your javascript app, try loading it in the footer. See the WordPress codex which explains the $in_footer variable: |
|
Posted: Saturday Nov 9th, 2013 at 12:40 pm #60967 | |
|
|
That error text doesn’t appear in the s2member source code. However, it does appear verbatim in the “WP No-Bot Question” plugin on line 137:
If you have the “WP No-Bot Question” plugin installed, it looks like it’s interfering with s2member’s form. If you need an alternative spam fighting WordPress plugin, might I suggest: If you don’t have the “WP No-Bot Question” installed, then you should do a text search throughout your entire “wp-content” folder and subfolders for that exact error text to determine where it’s coming from. |
|
Posted: Monday Oct 28th, 2013 at 10:27 pm #60707 | |
|
|
Your mail server may be having issues. You can offload it to another dedicated mail service. I recommend the following WordPress plugin: I’ve been using Mandrill for a while and they’ve been great at delivering mails reliably. |
|
Posted: Thursday Sep 19th, 2013 at 9:57 pm #59705 | |
|
|
You can use jQuery. Stick one of the following in whatever custom javascript file you have: For the authnet form:
For the paypal form:
|
|
Posted: Saturday Sep 14th, 2013 at 3:23 pm #59575 | |
|
|
I wrote a post a few days ago that detailed conditional loading: |
|
Posted: Friday Sep 13th, 2013 at 8:30 pm #59551 | |
|
|
Check the following in your admin area: |
|
Posted: Friday Sep 13th, 2013 at 8:21 pm #59549 | |
|
|
I too would prefer to have s2member’s files load statically instead of dynamically. But until that’s done, perhaps the following could help: When I began using s2member it took some time to optimize things so .css and .js affected load time as little as possible. The things I did that made a difference was the following: 1) Move all JavaScript loading from the head tag to the footer. This will allow the page to render, without JavaScript blocking page load. This was probably the most critical thing of all, in terms of perceived rendering/load from a user’s perspective. 2) Use a cache plugin. This is a must. I’ve used W3TC, WP Super Cache, and Quick Cache. I prefer the 3rd due to its simplicity. 3) Don’t load s2Member’s CSS. This may not be practical for all users, but since I only needed to style the checkout form, I disabled s2Member’s CSS and just recreated the CSS styles in my main stylesheet. 4) Only load s2Member on pages that need it. If you have 100 pages, but only 1 or 2 has a checkout form, then just load s2Member’s code on those 1 or 2 pages. 5) Use a CDN to offload images, scripts, css, such as Amazon CloudFront or MaxCDN. Another thing you’ll want to do, if you haven’t, is test your site on: It’ll tell you where some bottlenecks are with recommendations of what you can do to resolve them. The WebPageTest.org site was critical for me to find out problems with the site that didn’t even have anything to do with s2Member. For instance, it detected a legacy Keep-Alive Apache problem on SSL pages that had to be corrected. It was affecting all IE users by closing connections after each asset request.
|
|
Posted: Friday Sep 13th, 2013 at 8:06 pm #59548 | |
|
|
In the admin’s users area there should be a group of links that say something like:
The numbers next to the titles is the count of how many users belong to that role. Demoted users are typically set back down to the lowest level, which is “Subscriber.” Just look at the count to see how many you have. You can click the Subscriber link to just list them. If you don’t see “Subscriber” listed that means you don’t have any with that role. WordPress will only list counts for roles that have inhabitants. |
|
Posted: Friday Sep 13th, 2013 at 12:31 am #59509 | |
|
|
The following are suggestions directly from WordPress about hardening your installation: At the bottom of that page are other resources you can read. Doing some google searches for “securing wordpress” and “hardening wordpress” will get you a number of good resources. |
|
Posted: Friday Sep 13th, 2013 at 12:27 am #59508 | |
|
|
Bob, you shouldn’t be using two caching plugins at once. They’ll conflict with one another. Deactivate one or the other. As for the username being shown for the previous registered user… It sounds like you’re caching “logged in users” which should be disabled. Quick Cache disables this by default, as does W3TC. So wherever you have that set, it needs to be disabled. If that doesn’t work, then you should specify in your settings URL’s to block. Both plugins are capable of doing wildcard matches, so you can block entire directories or just specific pages. After you save changes, clear the cache. |
|
Posted: Wednesday Sep 11th, 2013 at 12:57 pm #59456 | |
|
|
1) Log into WordPress as the admin
4) Click the “Update File” button. |
|
Posted: Wednesday Sep 11th, 2013 at 12:43 pm #59452 | |
|
|
The height is messing you up:
Either remove the height declaration altogether, or change it to auto:
If the above doesn’t work, you’ll need to add ‘!important’ to increase its overriding specificity:
|
|
Posted: Thursday Sep 5th, 2013 at 5:56 pm #59173 | |
|
|
Jake, I thought the customer forum was removed within the past few weeks and merged with the community forum? Are you still seeing the customer forum? |
|
Posted: Thursday Sep 5th, 2013 at 5:49 pm #59170 | |
|
|
You can use API notifications: |
|
Posted: Thursday Sep 5th, 2013 at 5:45 pm #59169 | |
|
|
I can’t speak to the first part, but the second may be a mail delivery issue. If you’re using PHP’s native mail() function to send your emails, then you may have delivery issues if your mail server is malfunctioning or has its IP blocked/blacklisted by other servers. You may want to look into sending your mail via SMTP instead. Here are some WordPress SMTP plugins: I do recommend the following over the above though: They both do the same, but the latter better integrates with Mandrill’s SMTP service, which is free for a certain number of emails. You can create a mandrill account here: |
|
Posted: Thursday Sep 5th, 2013 at 5:36 pm #59167 | |
|
|
You can just load the necessary s2member javascript/css files on the pages that need it, instead of site-wide. Here are some pages that discuss the logic behind it: If you only have a few pages that need the s2member code, such as your buy/checkout pages, you could get away with something like the following. Create a file called “s2-hacks.php” (or whatever you want) in your “/wp-content/mu-plugins/” folder, and save the following in it.
The code above is saying, if a user is viewing “/checkout-page-1” or “/checkout-page-2” then load s2member’s CSS and JavaScript. Otherwise, don’t load it. If you have many checkout pages located in a directory, such as “/checkout/product-1/”, “/checkout-product-2/”, then you can just swap out “/checkout-page-1” with “/checkout” and it’ll protect everything within your directory. It’s a pretty hacky way to accomplish the goal, but it gets the job done. By the way, even on pages where s2member is loading, it should be possible to get an excellent pingdom score if you’re covering all other bases: gzipping content, using CDN for static content, setting expiry headers, efficiently loading JavaScript, minifying CSS/JS.
|
|
Posted: Tuesday Aug 13th, 2013 at 10:44 pm #55715 | |
|
|
Could you be running into the WordPress autop? See: These plugins can also help defeat it on a case-by-case basis: Using the above, make sure you’re using the Text and not Visual post editor. I use the latter, which has always worked for me, even though the prior has been cleared to be compatible with s2member here: |
|
Posted: Tuesday Aug 6th, 2013 at 7:24 pm #55331 | |
|
|
Wow, thanks Jason. That’s completely unexpected and very much appreciated. |
|
Posted: Tuesday Aug 6th, 2013 at 6:20 pm #55326 | |
|
|
No problem. I just posted a review. It’s the “Reliable membership software…” one at the top. Thanks again. |
|
Posted: Tuesday Aug 6th, 2013 at 3:55 pm #55315 | |
|
|
That makes sense. Thanks for confirming this. After disabling EOT, the firewall blocks appear to have stopped.
I spoke with Authorize.Net about the original IP 66.185.181.137, but they were not able to find a reference to it in their literature or developer forums. They said it seems to be ok to whitelist, based on a public whois lookup suggesting it belongs to CyberSource. They couldn’t speak with certainty about the IP’s origin though. I assume I’d have to contact CyberSource to determine that as Authorize.Net says they can only speak with certainty about what’s in their documentation.
Thanks for the suggestion. I was focusing on IP’s instead of hostnames. The latter should be more future-proof. I did ask Authorize.Net for any additional IP’s that should be whitelisted, but was told that wasn’t necessary, so I left it at that. Since Mike already provided the hostnames s2member uses to connect to, I should be able to use those to lookup the IP’s, assuming I can’t whitelist the hostnames directly. In another post, I mentioned that I downgraded from v130802 to v130617. After doing so, activity on the site seems to have normalized. But the abnormalities I reported did coincide with a ddos attack on an unrelated site on my switch, so I may have attributed fault to the upgrade unnecessarily. I also have to consider the possibility that I was just experiencing “noise” and the upgrade had a neutral effect. Regardless, I’ll stick with v130617 a little while longer and see how things shake out. Once again, thank you Mike and Jason for your assistance. |
|
Posted: Monday Aug 5th, 2013 at 2:08 am #55208 | |
|
|
Hi Mike. Do you recommending enabling both:
That’s odd about the IP address. When I did a whois lookup on the IP here: it comes up with the following domain registered 13 years ago:
The email address listed on the whois shows
Which matches the cybersource.com domain. Now if you do a whois lookup for cybersource.com, the first two parts of the IP are the same, and their GEO location is “San Mateo, CA 94404”, which is the same as the first. So, I suppose, the question is, is this truly a legitimate cybersource company, and if so, why are they trying to communicate with my website. My messages log file has thousands of references to this IP being blocked, such as: So it’s strange that this cybersource server is trying to communicate with mine, and interesting that the firewall decides to block them:
It looks like these deny references in my messages log were occurring in 5 minute intervals. Which coincide with WP-Cron’s default 5 minute intervals. s2member’s Authorize.Net “Automatic EOT Behavior” setting being set to on result in the site communicating with Authorize.Net’s servers every 5 minutes all the time. Jason even chimed in when I brought this up here: ME:
JASON:
I had forgotten about this, but today’s activity brings up a few questions: * Should I disable automatic EOT after all (since I don’t provide subscriptions or time-limited services)? I don’t know for certain how strict CSF is operating, but since it doesn’t permanently block IP’s I’m concerned things are getting swept up or deemed suspicious when the activity is innocent and necessary for s2member to function properly. It could be a random, moving target that operates outside of the s2member app hemisphere, but results in a silent, operation conflict anyway? Thanks. |
|
Posted: Monday Aug 5th, 2013 at 1:31 am #55204 | |
|
|
Thanks Mike. That’s similar to what I did. I took a zipped up backup and just overwrote the files on the server. I then deleted the two new file additions specific to the latest version:
Thanks again. |
|
Posted: Sunday Aug 4th, 2013 at 6:12 pm #55118 | |
|
|
Thanks Mike. While you’re at it can you please pass along two suggestions: 1) The expiration year drop down extends out to around +40 years. I think this may be a bit excessive. PayPal.com’s expiration extends to 20 years. Amazon.com’s extends to 24 years. After visiting a number of ecommerce sites, I haven’t seen any extend beyond Amazon.com. And I’m pretty confident if Amazon’s setting a max of 24 years, it’s probably safe for any site to do so as well. Perhaps 20-24 years would more reasonable than 40. Another thing is, 40 years makes for a long drop down box. For folks on small screens, and mobiles, that’s a lot of scrolling that can go off screen. 2) The expiration month and year are defaulting to empty values. If you look at how these fields are rendered on other ecommerce sites, January [01] and the current year [2013] are always defaulted as the first choice. There’s not even a blank field at the top, as there’s no practical reason to have it. This forces folks to immediately, and intuitively recognize that this is the expiration and credit card part of the fields. Since this field is always required, and backend validation will catch expired years anyway, I think the blank values should be entirely removed and the first month and year just shown by default as they’ll be the first values in the drop-down list. Another practical reason to remove the blank lines for both drop-downs is if a user submits the form with both fields unchosen, the following JavaScript validation error is outputted:
It’s outputting the same error twice, which can confuse the user. If a person submits only one out of the two, it’ll output it just once. Removing the blank lines at the top of the drop-downs resolves all these issues. |