WordPress MU

Blogger page = http://example.com/blogger

How can one link to http://example.com on the blogger themes without having to hardcode it http://example.com

kishore

Maybe you should review the template tags on the codex.

Actually this brings to mind a question I had that I'll go ahead and ask.

On my own WPMu install, I've been planning as my next addition to go back through and work on the themes, adding in additional Page Templates, nextpage support, widgets and the like. I;ve thought about releaseing them into the WPMu community.

A couple questions though.

- Think we should do up a themes-wpmu.wordpress.net? I would rather do it theme by theme. The pack idea is cool but it could be a bit much for those who are just starting and don't realize the work that goes into WPMu'ing a theme. Overlap between themes is also an issue.

- Hosted by such-and-such in the footers. This is my main question. I know that by using the get_option function, we can pull the blog name and the URL out of the individual blogs. I'm guessing that we can pull this information out of wp_1. Kind of a pain to hardcode that, especially since it may not be blog #1.

Item a)
Not a bad idea if coding standards could be monitored and enforced. I know I usually put anywhere from 4-16 hours into a theme to "properly" convert it. Depends on what shape the theme is in originally.

Some require no additional modifications other than my personal ones (header, footer, paged comments, ajax comments, captcha, etc). Then again, some don't even validate out of the box, or have so much extra crap that it takes a while to sort it out, or are so full of typos and url's without a trailing slash, or full of spammy links in the footer, or link to sites that don't exist or have been moved, or useless blocks of 100's of lines of commented text in the source, and the list goes on.

Item b)
For me, I think the most simple way would be to stick a couple of definitions in functions php, and call it that way. There would be 2, where one is for the site name and the other would be for the site link. Hey, it's 2 less database calls, and simply editing a little text there wouldn't be difficult even for a novice.

The less db calls, the better. Especially when there's a lot of sites involved. If it's only a couple for a few friends someone probably doesn't really care. As a plus to it the db calls by default with MU have been cut in half out of the box, which is much appreciated if you happen to skim this, Donncha. ;)

I think there's a site_id tag you can pull that hauls the main URL.

For the link to the site, use the $current_site object. It has domain, path, and site_name elements. I could have sworn I used that in the default template didn't I? (Checks, yes!)

lunabyte - db call reductions have been the result of work by many people, but the sentiment is appreciated!

/aside

Cool by me Donncha. If there were a list (unless I'm blind) I'd thank em all, but at least the "boss" spreads the love around.

Has it been considered to stick the options in an array, and call them once instead of individually? Not sure exactly what the difference in overhead would be, but that might help cut them down even further.

To keep from killing the "current system" the function could be written so that it converts the parameter and returns the right value from the array, so then it wouldn't take much to recode, and the get_option stuff would still work and not break. Then again, who knows. There's always a trade off, and it might be better to just grab it as needed.

Almost all the get_option() stuff is preloaded at the start of a WP request and fetched from memory after that, If you use memcached it works really well. So, in effect, it's already getting the data from an array!

For the link to the site, use the $current_site object. It has domain, path, and site_name elements. I could have sworn I used that in the default template didn't I? (Checks, yes!)

But isn't that the blog you're looking at? I'm wanting the function calls to get the URL and name for the main blog.

True that.

What better testbed than wp.com, huh? Excellent little tidbits in the presentation from BarCamp earlier this week. Some I hadn't even considered yet on the hardware side of it, and then some of the software implementations as well.

Also Matt's mention of getting Domas to groom the queries is cool. All combined is making for a great server environment. Oh well, off to look more at splitting up DB's again. :D

This shoudl do it shouldn't it?

<?php $current_site = get_current_site(); ?>
<a href="http://<?php echo $current_site->domain . $current_site->path ?>"><?php echo $current_site->site_name ?></a>

I know what you're saying re: themes but I reckon that people - on the whole - want to do as little work as possible for the maximum possible rewards :) So packs are infinitely preferable to individual themes.

Cheers, James

I disagree Farms. Packs are problematic once you've gotten one pack updating and keeping all of your changed files becomes that much more cumbersome. I like the idea of wpmutheme specific site much more. Many of us try and add a new theme every so often and being able to grab one theme seems better.
Granted there's no reason that as the theme site grows we couldn't maintain a weekly zip file of all the current themes too. Best of both worlds.

I'd love to have theme viewer for WPMU themes, as I rather like to pick one and one theme than using a package.

But I'm not sure how a project like that should be maintained, - when is a theme ready for MU?

- Only that it works?
- That it works and are widget ready?
- That it works, widget ready, have link to the bloghost?

And themes should be displayed in a MU installation, so that any MU spesific functions works.

Goes back to my mention of coding standards. Something would have to be put in place to ensure that they are maintained.

IMHO, a theme should :

1. Be MU compatible (obviously).
2. Validate against W3C.
3. NOT have spammy links and sponsored by junk.
4. Be widget ready, since it's compatible either way.
5. Maintain a consistent login/info area.
6. Be free of spelling and grammar errors.
7. Have a consistent footer. Such as left aligned the 2 following lines:
   

   (C){Year joined}-{Current Year} SiteName(link to home). All rights reserved
   Part of the {Primary Site Name(linked)} Network.

   And right aligned the two following lines:

   Powered by: WordPressMU(link to here)
   Theme: {Theme Name} (Name linked to the theme viewer)

8. No useless comments in the source, provide a readme instead.
9. A simple configuration file, included through functions.php where the MU owner can set their license type (if they want CC, or something else, and some other small vars like sitename and link to their site. Leaving (in theory) no editing of actual template files unneeded.
10. Screenshots must be no larger than 20k
11. Consistent header content/format, and DOCTYPES as well. IMHO, (x)HTML 1.0 transitional is the most flexible in an MU environment, with so many people writing posts, etc.
12. Simple straight HTML 404.php template, to eat as little BW and power as possible.

For a common footer, this way all links to the theme are valid, and then the author's link/info to (their site only) can be displayed on the theme site, that they can keep updated.

The deal would obviously involve a lot of time from volunteers, as well as a place to host all the info.

I'd be willing to personally contribute a few hours a week of my time, if there are some others that have the skills and knowledge to also help out as well.

In order to "ensure" compliance is maintained, every theme submitted would have to be reviewed and compared.

The way I see it, is that a theme shouldn't take more than 10 minutes to implement for production out of the box. Open a single file, add your relevant information, and upload it. If someone needs to add additional stuff (like for paged comments or adsense, that's on their own and not "counted on" by an author.

Finally, isn't the point of an MU site to keep "some" consistency across the entire "network" in place? Like a common login/info area, consistent source code output, and consistent and relevant information in the footer so that visitors aren't searching for where or how to log in or whatever just because someone changes their theme?

With this in mind, that's the reason behind ensuring a standard is maintained. So that someone can have the confidence when they download a theme they like, they won't have to worry if it's going to hose up their sites, or worry about how much time they would have to "waste" in trying to make it work and fit into their site. Edit a couple lines in a single file, and call it a day.

Right now, there isn't anywhere you can get a theme for MU that you can fully trust to be anything of the above.

So, like I said, I'd be willing to collaborate on this and put it into reality. I won't do it alone though. ;)

(Sorry for the length, but good info though.)

I think you should add SEO friendly title-tags as well to the list.

And viewable in "any" browser, theme working with javascripting/ AJAX disabeled.

I'd like to help out on this as well. And I have a ton of space on my Dreamhost account that I'll never will be able to if you worry about where to host this project.

What about using the regular wp themes repository but getting the maintainer to add a WMPU-ready tag?

Eh, on second thouhgt... yeah. Andrew has already set up TWO domains for WPMU stuff. The space and sites are there. wpmudev.org alreayd has a themes section, we could all start sending things in.

(lunabyte, 99% of your list should be followed by ALL theme developers. Even if I am guilty of a couple. ;) )

andrea; I'm not sure if a normal theme author will know if a theme is wpmu ready or not.

True Andrea. True. (sigh...)

Space/bandwidth isn't a concern, I run my own stuff. I know Andrew has his site(s), but I wouldn't want to just assume they could be used for this purpose. If Andrew says he's coll with it, then cool. If not, my stuff's available.

Thanks for the offer KK, but if I were to say anything to dreamhost it would be

"Would you like a chocolate covered pretzel?"

:D

Great spec. - can I add

- Includes plugin PLUS tag that allows WPMU admin to badge each blog either in footer or sidebar.

Packs plus individual themes would be great.

BTW I may be able to provide hosting so long as it doesn't go over 100Gig a month - on one of my servers - Have always wanted to try one of these massive Gig hosting servers though and see if I can actually use it up.

http://wpmudevorg.wordpress.com/themes.php

I'd say he was more than cool with it. :) I know he was gung-ho for theme packs and there are a couple individual themes listed as well.

(I so totally need to get around to it myself.)

I'm not sure if a normal theme author will know if a theme is wpmu ready or not.

Or even care.

Remember right now with the change in how wordpress handles categories and links, I'm betting a lot of theme designers are scratching their heads while looking at their inboxes right now.

Yes, true Andrea. But that doesn't quite operate in the manner in which this discussion is heading.

To me it sounds like, and should be implemented in this new deal, that authors contribute themes, but don't add them directly. They would simply submit them, and then they would go through an inspection and verification process. If they fail, the errors are noted and returned to the author for correction.

OK, that sounds like a chore, but it should build that "trust" factor with the MU admins looking for themes. If it's available for download, they would know it meets a certain minimum criteria and isn't going to jack up their site. If individual authors just upload what they want and then say it's compatible, then it breaks someone site or isn't up to snuff, then where does the credibility lie?

The way I see it, is that if the credibility and trust of the source can be built, then the end user can have confidence that they are getting a reliable product. The only way to do that is to review the submissions prior to their being made available.

@Farms... I think that would be a bit much James. That's more plugin oriented than theme oriented. Just my opinion though.

Of course the exact specifications would need to be addressed, and worked on first. Which can be done by the volunteers of the little deal, and then we can put it up for review here by the regulars.

So, anyone else with strong html and good php knowledge willing to help out with it?

Luna, I like that verification thing a *whole* lot better. Some pile o' work though.

Yeah. Probably about 15-30 minutes per theme submitted.