Greg
Forum Replies Created
-
By “extend” I meant derive a new class with WO_Server as the parent. I wouldn’t edit your plugin code directly.
> hook into WP OAuth Server’s core to do what you need to do in regards to
> retrieving/validating tokensYes, this is what I’m trying to figure out. 🙂
Thanks Justin. Actually, I’m trying to add an endpoint that is NOT below the oath URI.
I was assuming a custom plugin of some sort, but I guess a more precise framing of my question would be whether it is possible to add a custom endpoint at /something/api/{method} …
1. with a filter, OR
2. will I have to extend the WO_Server classI think you’re saying it is #2.
BTW, thanks for such a rapid response to my original question.
Forum: Networking WordPress
In reply to: Adding All New Users to Main SiteIn case it is useful, this is what I have been doing since 3.1. I added this in functions.php in the theme of the main blog. I am using the ‘wpmu_activate_user’ hook because that is fired close to the place that pre-3.1 WordPress would assign blogless new users to the main blog.
Note that in my situation we don’t allow new users to create blogs so YMMV.
function _activate_user( $user_id, $password, $meta ) { // Ensure that new users are registered to the main blog add_user_to_blog( '1', $user_id, get_site_option( 'default_user_role', 'subscriber' ) ); } add_action( 'wpmu_activate_user', '_activate_user', 10, 3 );Forum: Hacks
In reply to: Loading the WP environment in a (non-blog) subdomainI guess this party has moved to StackExchange.
Forum: Hacks
In reply to: Loading the WP environment in a (non-blog) subdomainUpdating…
I have a prototype that works, but I’m worried about the side effects of what I’m doing so it would be great if someone who’s familiar with the core could weigh in.
What I am doing is pre-populating the $current_site and $current_blog globals appropriately before including “wp-load”. Then, “ms-settings” doesn’t try to create these and doesn’t hit the code path that detects the subdomain and redirects to the front page.
I can now access member information (e.g. using ‘get_userdata’) and $wpdb.
Does this seem like a reasonable approach?
Forum: Fixing WordPress
In reply to: Subscribers appearing in author dropdownRefinement on the above…
In the single site (non-multisite) case all users at the lowest level (0, or ‘Subscriber’) level will be excluded. In the multisite case the query finds all users because the additional piece of the query that weeds out users with “user_level == 0” does not have any effect.
That is, this line…
$query .= " AND meta_value != '0'";…adds ” AND wp_N_capabilities != 0″ to the query, which has no effect.
This is more of a bug than a “TODO” and I’ll look into opening a bug in trac.
UPDATE: Opened http://core.trac.wordpress.org/ticket/14926
Forum: Fixing WordPress
In reply to: Subscribers appearing in author dropdownI dug into the code for this and it seems that for now the list will return any user who has any role on the blog in question.
The author selection box is created in the function
post_author_meta_box(). The following line gets the authors to populate the list:$authors = get_editable_user_ids( get_current_user_id(), true, $post->post_type ); // TODO: ROLE SYSTEMThis returns EVERY user who has a role on the blog AND is editable by the current logged in user. For the admin, that is everyone who has a role.
It does this because the query in
get_editable_user_ids()only checks that the user has awp_user_level(single site) orwp_N_capabilities(multisite) entry on thewp_usermetatable. Here’s the line:$query = $wpdb->prepare("SELECT user_id FROM $wpdb->usermeta WHERE meta_key = %s", $level_key);Note the “TODO: ROLE SYSTEM”. Presumably there is a plan to make this function do what it should do in the future.
Forum: Fixing WordPress
In reply to: Subscribers appearing in author dropdownI am seeing this too. It is quite a problem on a site with thousands of members but only a few authors.
Can’t find a setting to control this.
Forum: Networking WordPress
In reply to: Multisite: default .htaccess rules cause infinite loopThanks Andrea.
I find that there are quite a few requests coming in for outdated resources (e.g. assets in themes we no longer use) and with enough of these I’m worried that it will start impacting server performance.
Yes, I’ve also noticed that LiteSpeed doesn’t have this issue. Or nginx, which is what WordPress.com is using right now.
Forum: Networking WordPress
In reply to: Multisite: default .htaccess rules cause infinite loopA trac ticket is probably the right thing at this point.
Andrea, have you checked whether your subdirectory based multisite installs generate these internal server errors for files not found below “wp-*”?
Forum: Networking WordPress
In reply to: Multisite: default .htaccess rules cause infinite loopI’m starting to think this is a bug in the default htaccess rules, perhaps related to the way mod_rewrite implicitly handles files/directories that aren’t found.
I don’t know mod_rewrite well enough, but something like this:
- some implicit rule rewrites “/wp-content/folder/missing.php” to “/something/wp-content/folder/missing.php”
- rule in the default .htaccess rewrites “/something/wp-content/folder/missing.php” to “/wp-content/folder/missing.php”
- repeat until recursion limit is reached
If I add a 404 handler rule to the .htaccess (like below) then the internal server error goes away, which supports the theory but doesn’t prove it.
RewriteCond %{SCRIPT_FILENAME} !-f
RewriteCond %{SCRIPT_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1I have done this on my development server but still not production because I’d like to test more thoroughly.
Any input on the real reason that mod_rewrite is looping infinitely with the default htaccess rules would be much appreciated. I’d love to understand what is happening here.
Forum: Fixing WordPress
In reply to: Multisite: default .htaccess rules cause infinite loopThanks adiant. That makes sense.
Now moved here: http://wordpress.org/support/topic/multisite-default-htaccess-rules-cause-infinite-loop-1
Forum: Networking WordPress
In reply to: Multisite: default .htaccess rules cause infinite loopAndrea, can you explain why the rewrite limit would need to be higher than 10? That error message tells you to bump the limit past whatever you have set in httpd.conf. It defaults to 10 because once mod_rewrite has repeated the rewrite 10 times there is a pretty good chance it is in a loop. For completeness sake I set the limit to 50 and this doesn’t change anything (except the error message where the 10 is replaced with 50 of course).
BTW, the error I get on my development server is similar, but is issued by mod_rewrite:
mod_rewrite: maximum number of internal redirects reached. Assuming configuration error. Use ‘RewriteOptions MaxRedirects’ to increase the limit if neccessary.
And I do understand that these directories are virtual, but that doesn’t explain why it would generate a server error instead of a 404. Or am I missing something?
ipstenu, are the plugins relevant if I can disable every single one of them and still see this issue?
There is something strange happening here because if I remove the following line from the htaccess then the error goes away:
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]Of course, this is the line that makes the admin page accessible for the non primary blogs, so it is necessary.
The strange thing is that this line shouldn’t kick in for a path off the primary blog’s “wp-content” because the pattern matches “subfolder/wp_content” where “subfolder” here is one or more characters.
I know this is all a little obscure, but I was hoping that someone with experience of the issue could point me in the right direction. I’m pretty sure there are many multisite installs out there doing this and none the wiser, because you need to be watching your server error log to even know it is happening.
UPDATE: Should have done this earlier, but I have created a brand new, bog standard multisite install on my development server. No plugins activated, and the default MU home page theme. The same problem occurs.
Forum: Networking WordPress
In reply to: Multisite: default .htaccess rules cause infinite loopipstenu, the problem is present with the exact htaccess I pointed to in the codex. No additional rules to cause conflicts.
The site in question is http://youlookfab.com, which is running several plugins. But I have tested this on our staging server and the problem is present with all plugins deactivated.
Forum: Networking WordPress
In reply to: Multisite: default .htaccess rules cause infinite looptdjcbe, is Apache your web server, and is it a subdirectory install?