jnorion

Unfortunately I can’t link to the site, due to client confidentiality. But here’s my footer.php code… it’s just all the closing tags for the site structure, and then the call to wp_footer.

<?php
        // Define global path variables
        global $templateFolder;
?>

                                <hr class="clear" />
                        </div><!-- #mainContent -->
                        <div id="footer">

                        </div><!-- #footer -->
                </div><!-- #wrapper -->
                <div id="shadowBottom"></div>
                <?php wp_footer(); ?>
        </body>
</html>

Ah, ok. I was looking at your first bit of code, which was mixing the two. That’s interesting though, I can’t replicate that one myself in my current project.

The scope of this project got changed considerably so my interest is academic at this point. However:

@jskov: the get_site_url() command seems to do the trick! Somehow I hadn’t caught the option to pass the blog ID when calling that function. Is it safe to assume that the main blog will always be #1?

@pszeinert: the bloginfo('url') command actually includes the echo function built in, so it should also work if you just remove your echo command. In other words, echo get_bloginfo('url'); and bloginfo('url'); should give you the same results.

The second one looks helpful to me. Although I’m not quite sure how it determines which blog is the primary one. It doesn’t mention the admin requirement on the codex page… is that the only way it would have a primary blog set? Or would it do the same if someone was only added as a user to one subsite, and was left as a guest on the others?

That makes sense. So I guess the evolved question (I really didn’t do a good job explaining the first time around, did I? ?? ) is more along the lines of this: is there a way to accomplish this that IS multisite specific?

For instance, is there a way to keep track of a specific user’s “home” site? This is assuming that all sites would be part of the same multisite network, and that only a couple of admin users would be registered on the main site. So the normal user would be a member of, say, the office2 subsite and have guest access to the blog and wiki subsites. Now that I think about it, this may be easier using subdirectories rather than subdomains.

Then I could create a menu like this (including hypothetical WP function):

<a href="intranet.domain.com/blog>Blog Subsite, same for all</a>
<a href="intranet.domain.com/wiki>Wiki Subsite, same for all</a>
<a href="intranet.domain.com/<?php wp_user_home_site(); ?>/policy">Local policy manual, displayed based on user name</a>

Or some other way that WordPress could help determine this sort of thing?

Hmm. I’m not quite sure if that would do it, but I may be misunderstanding what you’re saying. Let me see if I can clarify and if that still seems like the answer I may have to ask for more detail from you.

Person A visits office1.domain.com. After viewing a couple of pages, he then clicks the “Blog” link in the nav menu, which redirects to blog.domain.com. Person B visits office2.domain.com and eventually clicks the “Blog” link as well, which also directs to blog.domain.com. So far so good, because they’re both seeing their specialized content first and then a shared blog second.

Here’s the catch: while viewing blog.domain.com, Person A clicks the “Office” link. This should redirect them back to office1.domain.com. But if Person B clicks the same “Office” link, it should go to office2.domain.com.

Because the link is located on the blog.* subdomain, both visitors will see the same code. So I’m not quite sure how to code that to dynamically choose which it would go to. Is there a method I don’t know of?

Or, am I going about this wrong? Is there another way to make a shared blog embed in a site, so that they’d never leave the office*.domain.com site in the first place?

Thanks!

Ah, perfect. Added all controls back and it works normally now. Thanks!

I’m having the same problem. WordPress is v3.1.1, FEE is v1.9.3.

I have editing turned on for post title, post content, and comment content only. With the WYSIWYG editor turned on, highlighting and tool tips work normally, but when I double-click the post content it disappears and never gives me an editor. Inspecting with firebug shows that the editor is there, and populated properly, but has display: none; set inline at the element level. I am able to edit the post title and comment content as normal.

If I turn the WYSIWYG editor off, it appears to work fine in all three places.

I have no custom controls set on the WYSIWYG editor.

I can replicate this in Firefox 4, Chrome 10.0.*, and Safari 5.04 (all latest versions), on OSX 10.6.

site_id doesn’t return the URL, though, it returns the Site Title from the general settings page. wpurl returns the URL, but it also returns the URL of the subsite if called as part of a subsite. Same problem.

you know all subsites pull from the same code too right? that’s how they pull tinymce in the subdomain edit areas.

Yes. That’s why I’m having trouble. It is using the same code — <base href=<?php bloginfo('url'); ?>" /> — for both the main site and the subsite. Because that code returns something different in a subsite but the file it should be pointing to is not different, it doesn’t work.

Obviously there’s a better way to do it, because as you said it’s being done on the back end. I simply don’t know what that better way is, which is why I asked the question in the first place.

Sorry, where am I looking for site_url vs. blog_url? What I was using was get_bloginfo('url'), not specifying site/blog.

The installation is part of a low-level project management system. The multisite installation is set up as mydomain.com/client/project, with client being the main parent blog which has multiple project blogs underneath it.

One of the features is a front-end posting system, for which I activated TinyMCE so people could use a visual editor without dealing with the WordPress back end. This needs the include I mentioned above, wp-admin/includes/post.php.

Normally I include a <base> tag in my header file and then reference all includes/images/links/etc. as relative to that. I generally set that as <base href=<?php bloginfo('url'); ?>" /> because then the theme doesn’t need to be customized for every installation. However, because the sub-blogs are virtual installations, there is a mydomain.com/client/wp-admin folder, but not a mydomain.com/client/project/wp-admin folder, and so the include fails and the front-end post doesn’t load correctly in the sub-blogs.

Hmm, I think I may have left out important info… I am using WordPress 3.1 with the built-in network system, rather than using WPMU. Aren’t the functions separate?

I’ll give that a shot though. Thanks!

Yeah, that should work. It’s a small and heavily moderated environment and there are only a couple of people who will ever be posting these files, so links are easy enough to verify.

Thanks!

Figured it out. Apparently it was a stupid problem on my part.

wp_update_user only attempts to clear and reset cookies if it’s updating the password.

The php function setcookie(), used in both the cookie-clearing and cookie-resetting functions, adds to the page headers and therefore must be called within the first php tag on the page, and before the WordPress get_header() function. Since wp_update_user needs this, it must be at the beginning of the page as well.

I was already sending user input to this page via POST anyway, so I just moved all the handling code to the top:

<?php
/**
 * Template Name: Profile Settings -- Updated
 *
 */

                                if ( $_POST['submit-button'] )
                                {
                                        include_once(ABSPATH . 'wp-includes/registration.php');

                                        $post_firstname = $_POST['firstname'];
                                        $post_lastname = $_POST['lastname'];

...... the rest of the code here .....

                                        if ( $post_password1 && $post_password1 == $post_password2)
                                                {
                                                        $new_user_data["user_pass"] = $post_password1;  

                                                }   

                                        wp_update_user( $new_user_data );
                                        //print_r( $new_user_data );
                                }
get_header(); ?>

I had this same problem, and the include posted above fixed it for me as well. I’m concerned about future updates breaking it, though. Can this be brought to the developer’s attention so it can be fixed in the future? Or is there something unusual about my installation (and those few above) that’s causing a problem where there wouldn’t otherwise be one?

Hmm, apparently I posted too quickly. I’m not sure what changed but for good measure I went back to play with it again, and this time it’s worked perfectly.

It appears the second argument of wp_category_checklist() is unknown_type $descendants_and_self, which takes a category ID number as input. For some reason it didn’t do what I expected before, but now it is. When supplied with 7 (ID for the To Do category) it shows only that category and its descendants. Also, repeating the process with a different parent results in two sets of checkboxes which combine, allowing me to have one window for employee and a different one for jobs.

Here’s my new code:

<?php if ($cat_list_type == 'checklist') { ?>
	<div id="quick_post_cat_checklist" style="<?php echo $cat_checklist_style; ?>">
		<ul id="cats">
			<?php wp_category_checklist(0, 7, $_POST['post_category'], false, null, true);?>
		</ul>
	</div>
<?php } ?>

<?php if ($cat_list_type == 'checklist') { ?>
	<div id="quick_post_cat_checklist" style="<?php echo $cat_checklist_style; ?>">
		<ul id="cats">
			<?php wp_category_checklist(0, 9, $_POST['post_category'], false, null, true);?>
		</ul>
	</div>
<?php } ?>

For reference, this begins on line 416 of quick-post-widget.php.