edtiley

I’ve looked at this one before. If only it could be piggybacked onto Theme My Login. Does Mr. Farthing know Miled?

As for Multisitable (great term!) the only clue is a diagnostic sent to them with support requests includes the value of is_multisite(). Switch_to_blog is nowhere in the source code.

Really I plan four levels of user:
Readers – No account needed
Subscribers – Must be logged in to rate and comment
Contributors – Authors
Premium Contributors – upgrades like domain mapping, extra storage, etc.

Subscribers are read-only, except for commenting and doing ratings, so social logins would be more than adequate.

Contributors would need a more robust registration obviously both to maintain accountability and to be the platform for premium features.

Again, interesting.

not right so say Twenty Twelve breaks your plugin

I’m an old newspaper guy. Never let facts get in the way of a good headline! At any rate it sparked an interesting thread, and I learned a couple of things.

crucial to the functionality of the plugin

If it weren’t crucial it shouldn’t be in the stylesheet

add more specificity

The logic of that is unassailable. It’s one of those concepts that just kind of makes you say, “Oh yeah, I should have thought of that!”

add_action( 'wp_enqueue_scripts', array( $this, 'register_plugin_styles' ) );

What hook would you suggest other than wp_enqueue_scripts?

The codex warns against using wp_print_styles on front pages.
The setup_theme hook has already come and gone, so I’m thinking that it is somehow a “feature” that the theme’s css file loads last.

A single “! important” is hardly a big PITA.

ROFL! I never have claimed to be normal.

The db training and experience voices in my head (two of the four) say not to waste disk space duplicating every post.

And hey, I learned a lot about the save_post hook, so it’s not a total loss in WP education. <grin>

Thanks for your help.

Ed

Oh, I think you misunderstand my question.

I’m not talking about going outside wpdb-> to make the calls. The question is if I have the proper wpdb->prefix for the main blog, does the routine even need to use switch_to_blog() to update that table.

but it’s still something I wouldn’t use, say, seven times on one page.

Oh, no. I’m crazy not stupid!!

I’ve written a plugin that has some similarities to “sitewide tags” but in mine a table gets created in the main blog (id=1) and every post gets a record that stores the blog id, post id, author nicename, guid, a list of the categories, a list of the tags, how many times the post has been viewed, reader rating info, etc.

When a post is created or updated:

add_action('save_post',array($this,'new_post_added') );

	function new_post_added($postinfo) {

	global $wpdb , $post , $blog_id;

	$postid = $postinfo;
	$user_blog = $blog_id ;
	$sql =  "SELECT * FROM " . $wpdb->get_blog_prefix( $blog_id ) . "posts WHERE id=" . $postid ;
 	$newpost = $wpdb->get_row($sql);

 	if ( $newpost->post_type == 'post' && $newpost->post_status == 'publish' ) {

		$title = $newpost->post_title ;
		$author = get_the_author_meta( 'display_name', $newpost->post_author );
		$pageurl = get_permalink() ;
		$catnams ='';
			foreach (get_the_category() as $cat)
  	  	{
  	     	$catnams .= ' | ' . $cat->cat_name ;
  	  	}
		$catnams = ltrim(substr($catnams,2));

		$tagnams =  strip_tags(get_the_tag_list('',' | ',''));
//		$tagnams = ltrim(substr($tagnams,2));

		$wpdb->flush();
		switch_to_blog(1);
		$table_name = $wpdb->prefix . "ipubratings";
		$sql =  "SELECT * FROM " . $table_name . " WHERE post_id =" . $postid . " AND blog_id = " . $user_blog   ;
 		$starpost = $wpdb->get_row($sql);

		if ( !empty( $starpost->rating_id ) ) {

			 $wpdb->update( $table_name , array(
						'post_title' => $title,
						'author' => $author,
						'pageurl' => $pageurl,
						'cat_list' => $catnams,
						'tag_list' => $tagnams),
						array('rating_id' => $starpost->rating_id)
					);
		} else {

			 $wpdb->insert( $table_name , array(
						'blog_id' => $user_blog,
						'rating_date' => current_time( 'mysql',1),
						'post_id' => $postid,
						'post_title' => $title,
						'author' => $author,
						'pageurl' => $pageurl,
						'cat_list' => $catnams,
						'tag_list' => $tagnams,
						'voters' => '|')
			);
		} // end ! empty
	restore_current_blog() ;

    } // end if  published post
	} // end new post added

I’m just worried that if the site gets really busy that the switch might be too resource hungry.

Actually, I’m wondering if I globalize or DEFINE the wpdb->prefix for the main blog id if I can create a method in the plugin’s class that would be able to access and maintain the ipubratings table without switching blogs. Seems I tried that, but it didn’t work out too well, but then I’m not nearly as good a coder as I was twenty years ago. Sigh…

My goal is to come to understand MultiSite half as well as you and Andrea! You two are an MU-Treasure. (not fawning) Thanks.

I assume you mean something like editing sidebar.php (or its equivalent). That’s unfortunate because it limits choices of themes for users. I was planning to limit users to child themes of twenty-twelve anyhow, so…. That triggers two questions:

Is it possible/practical to have grandchild themes? That is a child theme of a child theme, so the extended programming is separated from the styling.

Is there a good example plugin that shows how to build a screen for the superAdmin Dashboard to be able to control ad rotation etc.?

Thanks,

Ed

Putting it in functions.php makes it globally available.

$this->foo();
Bingo! I searched unsuccessfully for that for hours. In all the tuts I’ve read on building class based plugins I don’t think that little construct was explicitly mentioned. Or at least failed to penetrate my grayRAM.

Thanks.

Ed