Support » Networking WordPress » OK – I give up – how do we pull home site name into a $variable

  • So what I’m trying to do is create a function where the HOME site name is stringed for use as a default fallback string in a naming convention for images, e.g. (along these lines, this is not proper code) –

    if !exists ($image-folder . $child-blog-name . $this-month . ".jpg" ) {
      $page-bg-image = $image-folder . $home-blog-name . $this-month . ".jpg";
    } else {
      $page-bg-image = $image-folder . $current-blog-name . $this-month . ".jpg";

    Problem is, after hours trawling backwards and forwards in the codex, the only function I could find to do anything like this was blog_info(‘home’) – which would then need string stripping to get the home blog name out of the URL … but that’s been deprecated !!!

    So two questions really –
    1. – how do I use a native WP tag to acquire the NAME of the home blog
    2. – how do I use get_blog_info() to get the url of the home blog for a fixed link in the theme header? (The home BLOG index is not the site front / home page).

    Completely stumped now – so much for child theme making being easy … so far, I prefer the old hard-coded way under WP2.5 and earlier. At least that didn’t bury stuff under umpteen layers of cascading functions.

Viewing 13 replies - 1 through 13 (of 13 total)
  • Andrea Rennick


    Customer Care at Copyblogger Media and Studiopress

    In the db, the main site in the network is saved in the SITE tables, not the blog tables or functions.

    (possibly. it’s early. i need more tea.)

    Morning Andrea

    Yes, I know it’s in there somewhere, but the point is –

    supposedly (I say that because firebug is showing me a hidden fatal error when I try this) if I use get_bloginfo(‘name’) It’s supposed to return the name of the current site (home or sub-site), but there’s no tag or function anywhere I can find for get_bloginfo(‘home_name’) or for get_homeinfo(‘name’) or anything like that.

    I’ve also noticed that on pretty much every plugin that uses the name (not domain name) of the home site, you have to input it in a form and it then gets it from that form via short code.

    It seems there is no way within WP 3.0 to just get the name for the home side ( site_ID(1) ) – can’t even find a way to get_sitemeta(ID=1,name) or anything similar. I’m sure there used to be a way under WPMU (pre-3.0) to do this. Might be wrong though, I often am.

    Right, this is getting more complex that I thought …

    What I’m trying to do is be a bit clever and use a stylesheet.php as well as a style.css for the CSS

    The main reason is that I want to set the overall screen background to have auto-rotating images and colours according to the time of the year and whatever is on the national calendar for the current month.

    Regular CSS doesn’t accept PHP in the stylesheet, but by adding

    <?php header("Content-type: text/css"); ?>

    To the top of a PHP file, you can then use normal PHP code and data manipulation intermingled with the regular CSS code.

    Sounds great? It is … Until you try and do it with WordPress.

    Putting the stylesheet.php’s link rel=blahblah right after the regular style.css in the header causes undefined function fatal errors on any WP function or template tag in the stylesheet’s PHP code.

    I’ve tried jiggling around with the position of wp_head() and so forth, but it’s just not playing at all.

    I tried to build the assembled stylesheets using a custom function in the theme’s functions php and pointing it as an add_action at wp_head and that didn’t work either, nor did assembling it and running an apply filter against TwentyTen’s original stylesheet assembly from the child-theme functions.php

    I’m pretty much out of options now, and it’s starting to look like it’s going to have to be good old fashioned “to heck” with being able to auto-upgrade via the parent theme, and just hard code everything into replacement files.

    Of course, it would help if the Codex had actually been fully updated BEFORE 3.0 was rolled out – I’m having to use a local copy of TwentyTen to read all the functions files to find out exactly what WPMU functions and template tags they left alive, and what they replaced the killed-off ones with.

    Child themes easy? Pfa!! Not so far they’re not.

    (In a grumpy mood now – lost my entire Sunday on just this one issue.)

    get_site_url does not provide for the home (main) blog name on an MS install

    … here’s where it gets tricky … looking through ms-functions.php a lot depends on whether or not you’re using subdomain or directory path for sub blogs. Examples –

    get_bloginfo(‘name’) and get_bloginfo(‘sitename’) both only handle the current blog you’re at

    get_dashboard_blog() handles getting the ID, but not the name of the dashboard blog

    get_site_option(‘site_name’) only handles the currently active site name

    global $current_site; $current_site->site_name handles … guess what?

    get_blogaddress_by_domain($domain,$path)->$blogname only handles subdomain names (not home site).

    $details->blogname = get_blog_option($blog_id, ‘blogname’) is starting to get there … if you can figure out which function to call to pull the pertinent $details

    then we have the issue of sanitisation –
    MyBlog / My Blog / My blog / my-blog are all different in PHP and for a file name to be created containing either of the 2nd or 3rd versions, the space has to be lost or replaced – WP has a function that does that (as per pretty URLs for post titles), and I dare say that SOMEWHERE there is a function to pull the blog name and sanitise it as a simple string that could be inserted into paths and file names … I want to create the background images offline and FTP them up en-masse with the pertinent sub-blogs’ names as part of the file names.

    I’ve checked back, and this WAS easy under WPMU with things like is_main_blog() and so on. It’s not now.

    (Maybe it’s time to re-open the old MU forums?)

    Andrea Rennick


    Customer Care at Copyblogger Media and Studiopress

    Did you look at the codex link at all?

    get_site_url is the function. it will get the site url, which in the db, is the HOME URL of the network.

    which is exactly what you’re asking.

    Morning (at my end)

    Yup – looked, but it’s not the URl of the home site I want, it’s the name (like wot appears in the very top left of TwentyTen) without the dot and tld if it’s the same as the domain – it isn’t always, even on the main top blog.

    Now I’m in an even deeper pickle related to the style sheets which seems to all be related to severe lack of documentation for all the new bells and whistles in 3.0 and TwentyTen (off to read the plugins API codex in a mo – might help a little). Also the current Codex not having version applicability or date on most of the documents is a real pain – sent me up so many wrong paths this last 48 hours.

    Moderator James Huff


    The Codex is contributed to by volunteers. You’re welcome to start contributing at any time.

    I guess that’s why General Motors collapsed – the maintenance and driver manuals were written by volunteers and enthusiasts? … I can just imagine NASA issuing a Press Release – “free to new home, one used space shuttle … oh, and you have to write your own user manual after trial and error testing”

    C’mon James – gimme some credit, I’ve been here best part of three years – I KNOW that. BUT, there’s not even a complete single list anywhere by WordPress / Automattic to provide a side-by-side of ALL deprecated functions and template tags against their replacements or gravestones. As the script programmers, they should be creating that most basic of information pages and updating it at each upgrade. Read how they phrased it in the 3.0 release announcement – listed many and rounded up with a “loads of others” type statement and no link, no list elsewhere, etc. Makes me feel like Nelson putting his telescope to the eye with a patch on it … I see no functions!

    Moderator James Huff


    You forget that you haven’t paid anyone for WordPress. There’s no monetary gain for anyone to write the documentation. The regular volunteers will get to it when they can. In the mean time, you can either help or wait.

    Sorry, it’s just a matter of fact when dealing with a free software platform supported by a volunteer community. Honestly, comparing WordPress (a free open source platform) to GM and NASA is in poor taste. If you want perfection for the price of nothing, this isn’t the place for you. I thought you would have figured that out by now after being here for the “best part of three years.”

    I think the problem here is that you’re constantly referring to “WordPress / Automattic.”

    WordPress is powered by the community only. Volunteer developers, volunteer documentation writers, and volunteer support personnel. Automattic’s interest in WordPress extends only to Yes, they do contribute quite a bit to the WordPress community, but their primary concern is making WordPress work for

    Anyway, most of the new functions are outlined here:

    I’d start with that.

    You make it sound like I’m not grateful to those who have previously volunteered effort and documentation, which is simply not true.

    What I am pointing out is that when such a major change as the switch from 2.x to 3.x rolls, then a minimum level of pre-written documentation should be in place already – written by the code developers! After all, initially, they are the only ones who know what their code is supposed to do.

    None of which resolved the problem of where is the NAME of the home blog stored? Not the URI, not the tag-line, the NAME. And, how do we obtain and use it as a string variable when there appears to be no function to do so (otherwise I am sure plug-in developers would already be using it), without directly accessing the database … which so many here say is a no-no in WordPress coding standards.

    Moderator Ipstenu (Mika Epstein)


    Lead Plugin Wrangler

    1. – how do I use a native WP tag to acquire the NAME of the home blog

    Well. Obviously you have <?php bloginfo( 'name' ); ?>

    Assuming you want to call this from a different MultiSite, you’d want to wrap that around the switch_to_blog() call.

        global $switched;
         >>> DEFINE SITE NAME HERE <<<
         >>> CALL THE DEFINE HERE <<<

    2. – how do I use get_blog_info() to get the url of the home blog for a fixed link in the theme header? (The home BLOG index is not the site front / home page).

    Same idea, really.

    Or, y’know, go ugly and hard code it.

    “how do we pull home site name into a $variable … the url of the home blog “

    get_site_option uses $wpdb->sitemeta aka network sitemeta if network/multisite enabled and object cache see wp-includes/functions.php

    	$variable = get_site_option( 'site_name' );
    	echo $variable;

    network_site_url from wp-includes/link-template.php

    	$variable = network_site_url();
    	echo $variable;

    network_home_url from wp-includes/link-template.php

    	$variable = network_home_url();
    	echo $variable;

    get_blog_option uses $wpdb->get_blog_prefix( $blog_id ); options and object cache see wp-includes/ms-blogs.php

    	$blog_id = '1';
    	$variable = get_blog_option( $blog_id, 'blogname' );
    	echo $variable;

    get_home_url from wp-includes/link-template.php

    	$variable = get_home_url($blog_id);
    	echo $variable;

    get_site_url from wp-includes/link-template.php

    	$variable = get_site_url($blog_id);
    	echo $variable;



    @ ipstenu – thanks – I’ll try working it with that

    @ David – again thanks – I’ll have to see which of those works best in the functions I’m building … don’t suppose you have timelines for when they’ll get deprecated do you? Most things in WordPress seem to get deprecated in the version after I start using them.

    @ both – just coming back onto this project after too long on another one, sorry it took so long to respond to you.

Viewing 13 replies - 1 through 13 (of 13 total)
  • The topic ‘OK – I give up – how do we pull home site name into a $variable’ is closed to new replies.