Hi,
does anyone know what may be a reason, why WPMU tells me "Access denied" and stops the wp-activate.php Script?
If I open the activation URL again, it works fine!
Hope, You have ideas.
Thanks!
Hi,
does anyone know what may be a reason, why WPMU tells me "Access denied" and stops the wp-activate.php Script?
If I open the activation URL again, it works fine!
Hope, You have ideas.
Thanks!
Check permissions on the file.
Any plugins you have set for auto-activation?
Damn it!
Just had the same problem here. Right after I installed Plugin Commander 1.1.4 (the newest).
Do you have it as well?
BTW, this is definitely not permissions issue. At least not permissions of wp-activate.php file
I'm guessing there must be a conflict somewhere with plugin commander.
I'm using that on a site, but the blogs are created by admin, so we haven't noticed anything.
andrea, I'll check your guess.
But is there any other way to set a plugin to be auto-activated on new blogs creation? Except mu-plugins of course ;)
Mmmm... *thinks*... if it's included in the theme's functions file, maybe.
BUT (and this is a big but) I do know some plugins, especially NextGen, have issues with being activated ways others than manually.
Mu-plugins, for clarification, doesn't auto-activate, it auto-executes, which is slightly different.
OK, does someone know a gallery plugin that works with WPMU 'out of the box'?
Not really, I tend to use the internal gallery functions.
Why not just let the user activate the plugin?
Also see here:
http://wordpress.org/extend/plugins/tags/gallery
Quite a list you can test.
When I installed plugin commander I get the same: "access denied" when activating new blog. Is there any solution?? The plugin is gone but not the problem. Tips would be great :) I am ripping my hair off
/Patrik
Me too :(
Is there any solution?? :(
Not without any more details.
Check error logs etc...
From error logg:
PHP Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /home/quadt/public_html/wp-captcha.php:44) in /home/quadt/public_html/wp-captcha.php on line 52
This code came from my error log, I installed Peters random anti-spam + plugin commander. I already have wpcaptcha installed for registration and it works fine.
I removed plugin commander+ antispam but there must be som code left on pages or in the database....
I am trying to resolve the problem but if nobody else experince the same then I have to digg deaper in this!
Why is wp-captcha in the public_html folder? Shouldn't it go in plugins?
Since the error relates to that, I'd disable that too.
And check for spaces at the end of these files.
wp-captcha should be there. This is captcha for signup and you can find it on wpmudev, one file is in mu-plugin and the rest in root...My logg doesnt say anything more...
1. I sign upp testblogg
2. get the activation link
3. click on it and I get access denied on wp-activate.php
when it is suposed to show you the password etc, no email sent with your login information. And nothing else in the logfiles...
I have to digg more, but I am litle fustrate....whats stopping the script is it the anti-spam from peter or plugin commander thats the last plugin I installed...
Here is the solution!!
I used plugin commander to activate random anti-spam from Peter. When I massactivate and put on auto it´s not working! So i unistalled everything but somethig went wrong I dont know what?? But I put everything back again and then installed the anti-spam with plugin commander and uninstall + removed plugin commander and it´s working now!!!
anti-spam from Peter can go right in the mu-plugins folder with no issues.
I comment the lines 215 to 225 from plugin-commander.php and dont get more error messages.
function pc_new_blog($new_blog_id)
{
// a work around wpmu bug (http://trac.mu.wordpress.org/ticket/497)
/* global $wpdb;
if (!isset($wpdb->siteid)) $wpdb->siteid = 1;
$auto_activate_list = get_site_option('pc_auto_activate_list');
$auto_activate = explode(',',$auto_activate_list);
foreach($auto_activate as $plugin)
{
pc_activate_plugin($new_blog_id, $plugin);
}*/
}
Plugin Commander 1.1.5 solves the compatibility issues with WPMU 2.6 (and possibly with previous versions).
alexandrehaguiar, Thanks for the hint.
and guys, next time if any of you suspect there is a bug in plugin commander, please let me know. I found this thread accidentally.
omry, I also discovered another problem with plugin commander.
Well, for WP e-Commerce plugin. If activated via WPMU Plugins menu - everything is OK.
If activated via plugin commander - it does not create tables in DB with default settings.
The same thing happens with NextGen gallery.
VentureMaker, I will post my email reply to you here:
-------------------------------
I am not doing anything special, and plugins that are written
'correctly' should work fine.
what do I mean by 'correctly'?
there are two ways for a plugin to initialize itself:
1. call some code straight inside the global scope.
2. register to the activate plugin event, and initialize itself there.
the first option have been deprecated in favor of the second one when WP
2.0 came out (IIRC).
so it's been around for a very long time now, and all plugins should use
it instead of calling code (other than registering hooks) in the global
scope.
Plugin Commander supports only plugins that work using option 2.
in FireStats, I register the hook like this:
$plugin_name = substr(__FILE__, strlen(ABSPATH . PLUGINDIR . '/'));
add_action("activate_$plugin_name",'fs_activate');
the hook name depends on the plugin file name and this bit of code
should work for every plugin (at least - it works for me regardless of
the directory where I put FireStats).
obviously you will have to replace fs_activate with the name of a new
function, and to move the current plugin initialization code into that
function.
everything except add_action and add_filters calls should go into that
function.
add_action("activate_$plugin_name",'fs_activate'); should obviously not
be in the function, but the rest can probably moved into it.
You are most welcomed to send patches to the authors of the plugins you fix.
the changes may be easy or difficult, depending on the plugin you are
trying to fix.
I looked at WP e-Commerce, and it looks it's plugin file
(wp-shopping-cart.php) is pretty messy and may be a bit hard to fix
without understanding it properly.
this is because it functions and actual code is mixed over 90K of text.
you might want to contact it's developers about this or if you feel
comfortable enough with PHP fix it the way I described.
good luck.
Yep.
I crawled through the wp-ecommerce code a while back. I should do it again.
Some tips given here for Nextgen, basically commenting out a couple of checks.
http://mu.wordpress.org/forums/topic.php?id=9953
Thanks andrea_r. you might want to contact the developers about your changes. to validate them and possibly to put them into NG.
I think the capability check can be safely removed with modern WPMU installations.