|
|
Hi David.
After more digging I realized the redirections work for logged out users, so if I try to access level 1 content such as /microsties/create or level 2 content such as /mediawiki I get a redirect to membership options. Only if I’m logged in as a subscriber does the redirect fail for level 1 and 2 redirect, as does a s21member redirect fail for s22 content.
Okay, I registered a free account and tried the /mediawiki/ address. Got redirected to the Membership Options page URL, but got a blank page. I checked and I see that I got a 414 Apache error: Request URI Too Large. There’s a setting for this limit in Apache, you’ll need to raise it.
About the notices, you don’t need to worry, they’re not errors. None the less, in the new s2Member we’re taking care of these as much as possible.
I hope that helps. :)
When a subscriber tries to access Buddypress Create Blog http://domain/microsites/create/ by:
I noticed you have a Single Site license, but since you’ll be giving blogs to your users, you need the Network Support license. http://www.s2member.com/prices/#s2-terms-blog-farming
In your Account page you’ll find a link to upgrade just paying the difference. ;) http://www.s2member.com/account/
|
|
|
Hi Christian, thanks for the lead. If I go to Apache it suggest that if the lenght exceeds default of 8190 GET is being abused and POST should be used instead. http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestline
Are you recommending I override this?
*Under normal conditions, the value should not be changed from the default. Also, you can’t set this higher than 8190 without modifying the source and rebuilding.
Thanks for the note on network license. I will upgrade when the site is open to public and everything in S2 works correctly.
|
|
|
Also, just revisited licensing…
*If you operate a WordPress® Multisite Network, for the purpose of maintaining multiple child blogs or sub-sites that you own yourself (yes I do, all the sub sites belong to me, primary domain and sub directories), an s2Member® Unlimited-Site License is sufficient (e.g. you do NOT need a Network Support License if all child blogs or sub-sites are your own).
moreover…
A Single-Site License provides support for ONE instance of the s2Member® Product(s) that you purchase. Perfect for site owners with only ONE domain name. However, please note… if you run a WordPress® Multisite Network, with an s2Member® Product activated on multiple child blogs or sub-sites within your Network (NO, S2 will not be avalibe for sub blogs to provide membership), this will always require our Unlimited-Site License, because s2Member® runs as a separate instance on each child blog or sub-site in the Network.
Please clarify.
|
|
|
The URL that gives the 414 has 284 chars, which seem to be over the 8190 bytes because when I removed a few characters, the page loaded.
If you don’t use the Membership Options page variables, you can hack the redirect to remove them. In your must-use plugins /wp-content/mu-plugins/ put a copy of the file s2member\includes\classes\mo-page-in.inc.php and edit the [hilite mono]wp_redirect[/hilite] to leave just the URL to the page, without the vars.
Replace
[hilite pre_code]
wp_redirect (add_query_arg (urlencode_deep (array ("_s2member_seeking" => array ("type" => (string)$seeking_type, urlencode ((string)$seeking_type)=> (string)$seeking_type_value, "_uri" => (string)$seeking_uri), "_s2member_req" => array ("type" => (string)$req_type, urlencode ((string)$req_type)=> (string)$req_type_value), "_s2member_res" => array ("type" => (string)$res_type), "s2member_seeking" => (string)$seeking_type . "-" . (string)$seeking_type_value, "s2member_" . urlencode ((string)$req_type) . "_req" => (string)$req_type_value)), get_page_link ($GLOBALS["WS_PLUGIN__"]["s2member"]["o"]["membership_options_page"])), $status);
[/hilite]
With
[hilite pre_code]
wp_redirect(get_page_link($GLOBALS["WS_PLUGIN__"]["s2member"]["o"]["membership_options_page"]), $status);
[/hilite]
Haven’t tested. Let me know if it worked.
I hope it helps. :)
|
|
|
Please clarify.
If you have multisite, but s2Member is only used in one of the blogs, then Single Site license is enough.
If you have multisite and use s2Member in more than one of the blogs in it, you need the Unlimited Sites license.
If you have multisite and let your users have their blogs in your network, then you need the Network Support license.
http://www.s2member.com/prices/#s2-terms-blog-farming
Definition Of A Multisite Blog Farm / Network Support License
If you operate a WordPress® Multisite Network, for the purpose of maintaining multiple child blogs or sub-sites that you own yourself, an s2Member® Unlimited-Site License is sufficient (e.g. you do NOT need a Network Support License if all child blogs or sub-sites are your own).
In the case of a WordPress® Multisite Network operating as a Blog Farm, you WILL need our Network Support License (e.g. our Network Support License is required for Blog Farms), which includes everything that our Unlimited-Site License provides, plus support for the creation of child blogs or sub-sites; including the ability to restrict the number of child blogs or sub-sites that can be created by your users/members.
If you operate a WordPress® Multisite Network, and your Network DOES make it possible for users/members to create child blogs or sub-sites (in any way), we consider your installation to be a Multisite Blog Farm. Please note, many site owners run a Multisite Network for the purpose of maintaining their OWN child blogs or sub-sites. The term Multisite Blog Farm does NOT apply to a Network that hosts multiple child blogs or sub-sites, all of which are operated by a single site owner. A Multisite Blog Farm (in the eyes of s2Member®), is a Network that makes it possible for its users/members to create child blogs or sub-sites; where one or more of these child blogs or sub-sites is administered by a user/member (e.g. if you offer blogs or sub-sites to your customers, for free or otherwise).
|
|
|
Thanks Cristian,
so re: ‘If you have multisite and let your users have their blogs in your network, then you need the Netword Support license.’
ok, I think that clears that up but what support is there for the creation of child blogs by main network site user base? From limited tests I can see when a user exceeds the number of allowed bogs they just get a 404. Is this issue tackled by upgrade to netwrok license or require advanced scripting?
|
|
|
No, the license doesn’t affect the plugin’s behavior. I’m replying to your first email with the login info, could please reply back with the URL that the user would try that gives the 404? Thanks! :)
|
|
|
regarding the redirect fails…
S2 member redirect /mediawiki/ redirect to /options/ *fixed by removing ‘membership’-options from slug
but
/microsites/create/
for subscriber eg cristian doesn’t redirect and results in 404
URIs That Require Level #1 Or Higher:
/create/
URIs That Require Level #2 Or Higher:
/mediawiki/
|
|
|
|
|
|
|
When I used /mediawiki/ I did get the Membership Options page this time, but when I tried /create/, I got the 414 again. Maybe you’ll need to do the hack I suggested earlier. http://www.s2member.com/forums/topic/bp-redirect-not-working-for-create-blog/#post-22537
|
|
|
I emailed Jason asking about the 404 when the blogs limit is exceeded. I’ll let you know when I hear back from him on this. :)
|
|
|
re: In your must-use plugins /wp-content/mu-plugins/ (NO SUCH DIRECTORY or do you mean wp-content/plugins ?) put a copy of the file s2member\includes\classes\mo-page-in.inc.php and edit the wp_redirect to leave just the URL to the page, without the vars.
Are you suggesting to put mo-page-in.inc.php in wp-content/plugins/ ?
If anything goes here it will need writing up and registering as a plugin.
I’d suggest this is an option in s2member core if it is required to make the software work with Apache default values.
As a temporary workaround can anything be done with .htaccess?
|
|
|
Are you suggesting to put mo-page-in.inc.php in wp-content/plugins/ ?
If anything goes here it will need writing up and registering as a plugin.
Yes, if the wp-content/mu-plugins/ directory does not exist, please create it. Then follow Cristian’s instructions with copying the file to that directory and modifying the file as he described.
The mu-plugins directory holds Must Use Plugins. These plugins are activated and run automatically with WordPress and do not require manual activation.
|
|
|
Hi Raam,
Thanks for the clarification.
redirection now works without Membership Options page variables and fixes the LimitRequestLine issues I’ve been getting.
So, now I just have /microsites/create/ 404
basically, if a subscriber goes to /create/ they get 404 not an options redirect
if a s2member exceeds their blog quota and goes to /create/ they get 404
if a s2member has blog allowance they get /create/ OK
none of these scenarios utilize the options redirect.
|
|
|
Hi, is there any news on the 404 issue? Thanks.
|
|
|
Hi, please let me know where I am with 404 issue, am I waiting on response from Jason or should I keep trying?
|
|
|
I’m waiting for Jason to catch up with his email. He’s been checking his email less often lately, since he’s got his head deep in the new s2Member so we can start beta testing it really soon. I don’t think it’ll be much longer before he gets to this one. Thanks for your patience.
But since I’m back at this, I went and looked at your site again. I find it odd that s2Member would return a 404 in that situation, that’s very unlike how it deals with any other lack of access.
Is /create/ a default page of WordPress multisite? Here’s a quote from [hilite path]WP Admin -> s2Member -> Multisite[/hilite]:
Multisite Networking makes a new Registration Form available ( driven by your theme ); which we refer to as: /wp-signup.php. If, and only if, you’re planning to offer Blogs, you MUST use /wp-signup.php, instead of using the Standard Login/Registration Form. In a Multisite installation, we refer to the Standard Login/Registration Form, as: /wp-login.php?action=register.
It says you must use /wp-signup.php, but you’re using /microsites/create/. I just tried /wp-signup.php now and it redirected to /membership-options/, even though I was logged into the admin account, but that isn’t the right slug so it gives a 404. Same if I try /register/ which BuddyPress adds. Not sure what’s going on there.
Anyway, I went looking for /microsites/create/, but just found the /microsites/ page and saw that it has a listing of the network blogs and there’s a “create” button that links to /microsites/create/. Now, I went to the editor for /microsites/ and it’s an empty page. What is adding that content there? All this seems added by some other plugin.
Could you clarify what plugin is putting that there? If you deactivate all the plugins except s2Member, do you have the blog creation problem? Then start adding the other plugins, when does the problem come back?
I took at look at the form’s HTML in /microsites/create/ and from some googling, found it seems to be BuddyPress’. The form’s action, though, is empty in the HTML I looked at, not sure if that’s right. The PHP files I looked at in BP do have an output there, so I wouldn’t expect it empty. Or is there some JavaScript at work there?
In any case, the s2Member documentation points to using wp-signup.php, which is giving you a 404 because of a /membership-options/ slug that doesn’t exist, but no redirection should happen in the first place if I’m in the admin account. You should fix that and see if it helps with /microsites/create/ problem.
I hope it helps.
|
|
|
Sorry Cristian, you caught me messing with ht access.
*this notice applies for ‘not logged in user’
re: Multisite Networking makes a new Registration Form available ( driven by your theme #which is Buddypress ); which we refer to as: /wp-signup.php ( #which is Buddypress /register ). If, and only if, you’re planning to offer Blogs, you MUST use /wp-signup.php, instead of using the Standard Login/Registration Form. In a Multisite installation, we refer to the Standard Login/Registration Form, as: /wp-login.php?action=register.
So no, I’m not using /wp-login.php?action=register
To register a new user I am using Buddypress domain.com/register http://screencast.com/t/p8h04GxiR
Buddypress can only use its own create blog screen here:
To create a new blog I’m using Buddypress domain.com/microsites/create http://screencast.com/t/teeAlsKhR
|
|
|
Okay, so it’s a BuddyPress page to create new blogs. I just tried /wp-signup.php again and it still redirects to /membership-options/ with the 404. If BP is trying to use wp-sign.php, then that may explain the 404s you get.
Can you solve what’s preventing you from using /wp-sign.php and and test /microsites/create/ again?
|
|
|
Hi Cristian,
Buddypress inbuilt functionality dictates /wp-sign.php is overridden by /register as set in Buddypress admin http://screencast.com/t/vHLdmtRr
This is standard Buddypress setup. http://screencast.com/t/625qkeePjkK
I do not believe I should solve this functionality as S2meber should support Buddypress standard instal, unless there is something in S2member that should override Buddypress and give back /wp-sign.php to S2member.
*there is no documentation to say that this should be unlocked for Buddypress http://screencast.com/t/f70PwEy3tQ5
-
This reply was modified 4 years, 4 months ago by
 David Hunt.
|
|
|
Hi, the 404 is a red herring!
If I create a page and make it child of microsite its url becomes /microsites/create/
If I’m a logged in S2 level 1 I get /microsites/create/ OK with Buddypress embedded create blog fields.
If I then take that user back to subscriber and try to reload the same page I get /microsites/create/ OK but as a blank page ie NO Buddypres create blog fields and no ‘redirection’ to expected S2 options.
This issue has to be incompatibility between the S2 restriction option level 1 = ‘/microsites/create/ or just /create/’
and the Buddypress plug allowing a non S2 level 1 user to get ‘redirected’ back to S2 options.
-
This reply was modified 4 years, 4 months ago by David Hunt.
|
|
|
Please can I get help on this. As I’ve been waiting for a response I’ve gone through the whole scenario with wp-signup.php open http://screencast.com/t/i9DekqwWF
As before…
If I create a page and make it child of microsite its url becomes /microsites/create/
If I’m a logged in S2 level 1 I get /microsites/create/ OK with Buddypress embedded create blog fields.
If I then take that user back to subscriber and try to reload the same page I get /microsites/create/ OK but as a blank page ie NO Buddypress create blog fields and no ‘redirection’ to expected S2 options.
This issue has to be incompatibility between the S2 restriction option level 1 = ‘/microsites/create/ or just /create/’
and the Buddypress plug allowing a non S2 level 1 user to get ‘redirected’ back to S2 options.
***with wp-signup.php open in S2 Buddypress still overrides wp-singup.php and redirects to /register/
***have now disabled the physical /create/ page as it doesn’t serve any purpose now.
-
This reply was modified 4 years, 4 months ago by David Hunt.
|
|
|
Okay, so what’s the conclusion you reached after the tests?
/wp-signup.php may not be available to people if registrations are closed, but that would not give a redirection to the Membership Options page, much less one that doesn’t exist. When registrations are closed, /wp-signup.php says “registration has been disabled”, no redirection.
But I see that you’re now taken to /register/ as BP wants it, and the proper message about closed registrations is shown now. Cool, what was the problem with that? Something from .htaccess tests?
This issue has to be incompatibility between the S2 restriction option level 1 = ‘/microsites/create/ or just /create/’
and the Buddypress plug allowing a non S2 level 1 user to get ‘redirected’ back to S2 options.
Well, I haven’t had experience with BP’s /microsites/create/ combined with s2’s URI restriction before, but it wouldn’t surprise me to see something odd, happen. Especially if you have two URI strings match at different levels: /microsites/create/ will match /microsites/create/ but also /microsites/.
When you’re trying to solve something with too many variables, it’s much harder than doing, and uncertain than testing, one thing at a time.
What I’d do in your situation is deactivate s2Member for a moment and test how BuddyPress works by default. Then I’d deactivate BuddyPress and activate s2Member and see how that works. Then I’d have them both active, and apply only one restriction at a time with some testing for each.
With each round I’d test: wp-signup.php, /register/, /microsites/create/, at least, and with users at different levels each.
And remember to put -at least some of- the Membership Options page vars, so you know what’s sending you there when it happens (e.g. “was it the Level 1 or Level 0 URI restriction?”)
If you don’t want to touch what you have, you can install a clean WP and set it up for the tests. The cleaner, the better for the tests, cause then you don’t have hidden things from previous tests you did, like the .htaccess thing throwing another variable at it. Don’t add more plugins until you sort those behaviors out between s2 and BP, again: less variables.
I hope that helps find what the issue is being. :)
|
|
|
Hi Cristian,
I’ve cracked one issue after testing hypothetical S2 Level 2 scenario, and found the system was working as expected for L2 users. This led me into looking at wp capabilities and flushing everything clean.
re: ‘Especially if you have two URI strings match at different levels: /microsites/create/ will match /microsites/create/ but also /microsites/.’
This is not the case, I can have a logged out user get redirect for /microsites/
and have a L0 have access to /microsites/ but not /microsites/create/
and have a L1 have access to /microsites/create/
ie. It appears that as far as S2 buddy restrictions are concerned /microsites/ & /microsites/create/ are two distinct entities, which is great!
My original error was coming from a faulty WP capability records. As soon as I reset it to WP subscriber defaults, with relevant S2 level appends, everything worked as I’d hope it would… except the blog number allocation doesn’t appear to have any intelligence.
I can have a logged out user get redirect for /microsites/
and have a L0 have access to /microsites/ but not /microsites/create/
and have a L1 (who hasn’t created their own blog) have access to /microsites/create/
BUT
for an S2 member (who has exceeded their membership level blog allowance) I get 404, not a redirect to options.
Please will you ask Jason explicitly whether there’s any inbuilt functionality to say what ‘should’ happen when a S2member exceeds their membership level blog allowance and tries to access /microsites/create/. Thank you.
-
This reply was modified 4 years, 4 months ago by David Hunt.
|
|
|
Thanks for the update, David.
My original error was coming from a faulty WP capability records. As soon as I reset it to WP subscriber defaults, with relevant S2 level appends, everything worked as I’d hope it would… except the blog number allocation doesn’t appear to have any intelligence.
I see, so you had edited your WP capabilities too?
ie. It appears that as far as S2 buddy restrictions are concerned /microsites/ & /microsites/create/ are two distinct entities, which is great!
Yeah! Good thing you confirmed it through testing. I had not tried overlapping restrictions like that, which is why I mentioned it as something to test.
Please will you ask Jason explicitly whether there’s any inbuilt functionality to say what ‘should’ happen when a S2member exceeds their membership level blog allowance and tries to access /microsites/create/. Thank you.
That’s what I asked Jason in the email. I’m waiting for him to check his inbox this week, which should be soon.
Again, I doubt s2Member would be giving a 404, but let’s see what he replies. :)
|
Pre-Sale FAQs
Video Tutorials
Community Forum
Knowledge Base
News/Updates
s2 Codex / Docs
GPL v2 License
Contact A Human
About Us
Our Customers
Support Policy
Privacy Policy
Old Forums (READ-ONLY): The 
