Forum Replies Created

Viewing 11 replies - 1 through 11 (of 11 total)
  • nadaoneal

    (@nadaoneal)

    This looks good to me so far (WP 3.3.1 multisite). Thanks for your quick fix.

    Thread Starter nadaoneal

    (@nadaoneal)

    Thanks! Embarrassingly, it looks like that’s v1.3.1, identical to the currently available version, AND that it works just fine for me in 3.3.1 now, all of the sudden. So I may have had a brain meltdown of some kind causing it to appear to not be working.

    In case anyone else is reading this and is curious…. To also add the the edit_themes/theme_options capabilities for administrators, I did two things.

    (1) To um_unfilter_roles() I added:

    $wp_roles->role_objects[‘administrator’]->add_cap( ‘edit_themes’ );
    $wp_roles->role_objects[‘administrator’]->add_cap( ‘edit_theme_options’ );

    (2) To um_unfilter_multisite() I changed the condition to:
    ( $cap == ‘unfiltered_html’ OR $cap == ‘edit_themes’ OR $cap == ‘edit_theme_options’ )

    In the Multisite version, it’s SuperAdmin > Options, then uncheck “Registration notification” under “Registration Settings”.

    I’m not sure about the single-blog version. I don’t have it installed, and I’m having trouble finding any reference to the location of the setting in the Codex. I suppose it’s possible that you can’t turn those emails off.

    Are you receiving any mail from WordPress, like if you sign up for comment notification? If you’re not receiving any mail at all, it may be a sign that your hosting provider has security features set that prevent Apache or php from sending mail.

    If you can receive other mail from WordPress, post again and maybe someone will have a bright idea…

    Thread Starter nadaoneal

    (@nadaoneal)

    I’ve added this as a feature request here, since the lack of response implies to me that it is indeed a missing feature.

    Hmm, I’m not sure. Is it overridden by your template somehow? Sorry I can’t be more help.

    The additional hacky thing you could do, maybe, is add actions onto the authentication system hooks. This way, if someone managed to activate the action through a default link, they’d still be redirected… (I’m not sure if this would result in every single person being logged in to WP or other undesirable things, though… maybe try it out and see what happens? )

    hooks:

    add_action('wp_authenticate', 'authenticate_redirect',);
    	add_action('wp_logout', 'logout_redirect');
    	add_action('lost_password', 'disable_function');
    	add_action('retrieve_password', 'disable_function');
    	add_action('password_reset', 'disable_function');

    example function:

    function authenticate_redirect() {
    	wp_redirect("http://your-site/login-page");
    }

    I don’t know how you’d pass through the WP session id for the logout this way, but there might be some kind of wp_get_session_id function, so you could do something like:
    $sessid = wp_get_session_id();
    wp_redirect(“http://your-site/logout-page?session=$sessid”);

    Good luck, hope that helps some.

    You can make a simple plugin that just adds filters to the loginout and register hooks.

    Something like:

    add_filter( 'loginout', 'bb_loginout_link' );
    add_filter( 'register', 'bb_register_link' );
    
    function bb_loginout_link ( $original_link ) {
    	if ( is_user_logged_in() )
                    /* pull in data from $original_link and transform it if you need to*/
    		$link = "http://yoursite.com/bb-logOUT-link";
    	else
    		$link = "http://yoursite.com/bb-logIN-link";
    	return $link;
    }
    
    function bb_register_link ( $orignal_link ) {
    	return "http://yoursite.com/bb-register-link";
    }

    Note: I have NOT tested this exact code, this is just a guide. Please test. Hope this helps.

    I think this article is really helpful:

    http://codex.wordpress.org/Dashboard_Widgets_API#Advanced:_Removing_Dashboard_Widgets

    … basically, I just wrote a plugin like so:

    # get rid of dashboard junk
    function example_remove_dashboard_widgets() {
    	// Globalize the metaboxes array, this holds all the widgets for wp-admin
    	global $wp_meta_boxes;
    
            unset($wp_meta_boxes['dashboard']['normal']['core']['dashboard_incoming_links']);
            unset($wp_meta_boxes['dashboard']['normal']['core']['dashboard_plugins']);
            unset($wp_meta_boxes['dashboard']['side']['core']['dashboard_quick_press']);
            unset($wp_meta_boxes['dashboard']['side']['core']['dashboard_primary']);
            unset($wp_meta_boxes['dashboard']['side']['core']['dashboard_secondary']);
    
    } 
    
    // Hook into the 'wp_dashboard_setup' action to register our function
    add_action('wp_dashboard_setup', 'example_remove_dashboard_widgets' );

    … then dropped it into the “mu-plugins” folder, and this got rid of everything except “latest comments”, “Right now”, and “Recent Drafts”.

    Thread Starter nadaoneal

    (@nadaoneal)

    So, I tried the fix – suppressing the RSS feeds on the dashboard, deleting the transient feed records out of the options tables, and then running mysqlcheck -Aaeo from the command line. This has made a significant improvement, but we still notice (less severe) slowness from time to time, especially on the backends of blogs that were upgrade from WPMU.

    Including the simple perl script that I used to delete the transient_feed records from the options tables, in case it saves someone 10 minutes in the future…

    #!/usr/bin/perl 
    
    use DBI;
    use strict;
    
    my $db_name='****';
    my $db_host='****:***';
    my $db_user='***';
    my $user_pass='****';
    my $dbh = DBI->connect("DBI:mysql:$db_name:$db_host",$db_user,$user_pass); 
    
    # first, get all the "options" tables
    my (@options_tables);
    my $query = "show tables;";
    my $sth = $dbh->prepare($query);
    my $rows = $sth->execute;
    while (my @data = $sth->fetchrow_array()) {
    	my $tbl_name = $data[0];
    	# options table?
    	if ($tbl_name =~ /wp_[0-9]+_options/ ) {
    		push(@options_tables,$tbl_name);
    	}
    }
    $sth->finish; 
    
    # delete the transient feed junk from the options tables
    foreach my $opt_table (@options_tables) {
    	print qq~deleting from $opt_table...\n~;
    	$query = qq~delete from $opt_table where option_name like "%transient_feed%";~;
    	$sth = $dbh->prepare($query);
    	$rows = $sth->execute;
    	$sth->finish;
    }
    Thread Starter nadaoneal

    (@nadaoneal)

    Thanks Andrea. I read this article:
    http://codex.wordpress.org/Dashboard_Widgets_API#Advanced:_Removing_Dashboard_Widgets

    to see how to suppress the dashboard widgets that have these feeds. I’m currently testing to see if this fixes the slowness issue. I will post again if I find out anything useful for posterity.

    Are you running MySQL for the backend? Have you tried running a repair and optimize on all the tables – or whatever the equivalent is for whatever db you’re running?

Viewing 11 replies - 1 through 11 (of 11 total)