Forum Replies Created

Viewing 15 replies - 481 through 495 (of 519 total)
  • Plugin Author David Dean

    (@ddean)

    I feel like this will only ever be settled by some monster blog series, but I’ll try the short version.

    About what it does: it creates another Network with the same codebase and user database.

    Think additional Network Admin to log into, separate set of sites to manage, potentially a different network admin or admins, etc. It is NOT for everybody, and it is NOT for you if all you want is for an individual site to have a vanity domain name.

    About the various plugins: They all do the same thing.

    Once upon a time (before WP 3.0), “Sites” were called “Blogs”, and WPMU kept track of the blogs in a wp_blogs table. And there was another table – wp_sites – that appeared to just keep basic info about your domain.

    There was only ever one row in the wp_sites table, and no interface for making others. But, if you created a second row with SQL and made a few other changes, you ended up with a second site (now called a Network) on a different domain.

    So, in 2007 I released the WPMU Multi-Site Manager to automate those changes. Networks for WordPress is a descendant of that original plugin, as is WP Multi Network. I can’t speak for Network+, but the description makes it look similar enough. The point is that any plugin that creates Networks has to make these same changes, because it’s how the Network feature operates.

    About the plugin warning: BuddyPress.

    BuddyPress creates global tables, so it isn’t attached to a particular blog/site. So, if you activate BuddyPress on two networks, it can’t tell which set of data it’s supposed to be using.

    Finally – thank you for the kind thoughts! TBH, if we didn’t use it extensively at work (JerseyConnect is an ISP that also hosts blogs), I wouldn’t have kept it up. You never know who will find the next bug. ??

    I hope that shed some light on things. Let me know if you have any more questions!

    Plugin Author David Dean

    (@ddean)

    Q2. I think other plugins have fudged the cookies somehow to create a persistent sign-on, but that’s been 1) too much of an assumption about who will be administering each domain, and 2) too far from the purpose of the plugin.

    Your site admin credentials from your original network still work for all other networks, unless you don’t want them to.

    Q1. Your path should almost certainly just be “/” and DEFINITELY shouldn’t be “//”. Your comment triggered a thought: Are you set to use subdomains or subdirectories? If you are set to use subdomains, that could explain a lot of these problems.

    Plugin Author David Dean

    (@ddean)

    1 – That’s odd. How did you create the /newyork site? I would check your wp_blogs table to make sure everything looks normal.

    2 – the same login will let you log in to all your networks (provided you copied the site_admins sitemeta key, which is copied by default). But because the log in cookie is set with the original network’s domain, you have to log in to each separately.

    Plugin Author David Dean

    (@ddean)

    Sounds relevant to me. Do you still have domain mapping active? Including the sunrise.php file? if so, removing it might help troubleshoot.

    Does it actually report that no blog was created at the root? Or is that the “No site defined on this host” error?

    It sounded like DNS and your web server are set up correctly, since you pointed both domains at the same filesystem location. It wouldn’t hurt to turn on mod_rewrite debugging and see what it says if nothing else works out.

    Plugin Author David Dean

    (@ddean)

    You’re thinking of it too much like domain mapping. Path is essentially just the address of the top-level site on the new network. In most cases, it’s simply “/”. So, you probably want something like this:

    Domain: https://www.mynewsite.com
    Path: /

    And create the new network. This lets you create sites at /, /newyork, and whatever other path you’d like under that domain.

    If you created one with the settings you supplied, you should delete it.

    Plugin Author David Dean

    (@ddean)

    Haha! I thought your name looked familiar. ??

    If you used Domain Mapping but now want to create a new network, I’m not sure this plugin can help you. I know next to nothing about the domain mapping plugin and what it can/can’t do, but here’s what will need to be done:

    – undo the domain mapping
    – create the www.mynewsite.com network
    – Move the blog that WAS mapped to www.mynewsite.com to the new network

    Plugin Author David Dean

    (@ddean)

    That is an interesting scenario. There’s no need for the groups to be “under” the parent in the URL-based way they are with this plugin, so that frees up the association a lot more.

    TBH, it’d be a pretty low priority considering I’ve still got to get BP 1.3 support hammered out, but I’ll keep it in mind. In the mean time, I can ensure that the appropriate hooks exist.

    Plugin Author David Dean

    (@ddean)

    Unfortunately, having multiple parents would require a significant rewrite of the plugin, and there are no plans for that.

    Is there something specific you’re looking to achieve that we might be able to accomplish in a different way?

    Plugin Author David Dean

    (@ddean)

    hkcharlie: there isn’t anything in the plugin that does this. The coding that would be needed to make this work is so little related to the hierarchy that it would be practically two plugins joined at the hip. For the time being, an RSS / aggregator solution is probably best.

    Ipstenu: you’re right; having a link is a huge help as to which plugins people are actually talking about, and I appreciate the link so I can try to lend some help. ??

    And your reading of the doc is exactly right. A new domain can be its own network and, if you’ve set up WPMS for subfolders, you can have all the subfolder sites you want. Ditto for subdomains.

    Thanks for countering some of the FUD, Curtiss! ??

    Magyar: Creating multiple “networks” allows you to run sites with a shared codebase and userbase on two or more domains, but doesn’t let a single “network” span domains. For that, I think domain mapping is the way to go.

    When you create a new “network,” you’re just adding a row to the sites table and creating/changing some meta values. You won’t see any new tables. It’s just like adding a “site” to your existing “network.”

    What does your web server config look like? Honestly, that is the first place to look.

    Plugin Author David Dean

    (@ddean)

    It’s definitely worth upgrading. The bug only affected the main network, and may have popped up after the site_id and domain were changed but before the blog/site options could be changed. So it seems like a good match for the issue you were seeing.

    If you still see it after upgrading, I’d be happy to help troubleshoot further.

    Plugin Author David Dean

    (@ddean)

    RavanH: was your network created before WP 3.0? I identified a bug in the current version of the plugin that might keep you from moving sites back to the main network if you have an older install. A fix will be coming shortly!

    I’m not really sure about why the file upload path is the way it is. Maybe feed processing is outside of the normal path, or it has something to do with the path being different depths on different sites?

    Plugin Author David Dean

    (@ddean)

    Thanks for the report! I’ll take a look at this issue and see what I can find.

    I made a conscious decision to not try and move files / update all the links within posts and pages when a site is moved. New uploads should go to the proper uploads directory for the new site.

    While I agree that it would be cleaner to have everything moved with the site, I just don’t have time to properly implement and test such a potentially destructive feature.

    If these problems are related to having the *_CURRENT_SITE constants undefined, then feel free to uncomment them. The decision to instruct commenting them out was based on my best reading of the site routing logic, and while it causes no problems on our install and many others, it’s definitely worth considering as a source of issues.

    Unless there are more issues at play here, I’ll change the instruction to a troubleshooting step. People seem to be running fine with those constants in place, and the fewer file edits needed the better.

Viewing 15 replies - 481 through 495 (of 519 total)