[resolved] Running a "network" on WordPress (21 posts)

  1. AndyM3
    Posted 10 years ago #

    I must say that I'm rather confused right now. I paid a guy to design a nice site design, paid another guy to code it, and now I have an awesome WordPress theme - only problem is I'm trying to think up how I can set it up for a website network.

    I own a large gaming-related network, there are about 8 different .com domains associated with the network. Each .com is its own site devoted to a particular game.

    Now I suppose I could run 8 installations of WordPress, but honestly that doesn't sound efficient at all. Is there any other way that I could run all 8 sites in one copy of WordPress all using the same theme and the "main site" or network hub showing the news from each individual site?

    Any help/suggestions/tips/advice would REALLY be appreciated.

  2. vkaryl
    Posted 10 years ago #

    You *might* be able to do something like this using different table prefixes in the database. I've never tried anything like this, since the dozen or so blogs I have all have different themes, raisons d'etre, etc. I do know that you can have many different table prefixes under one database, so that might be the place to start.

    There's a Codex article here on multiple blogs/installs:


  3. AndyM3
    Posted 10 years ago #

    Thanks vkaryl, so besides that page there's nothing else you might have in mind?

  4. Pizdin Dim
    Posted 10 years ago #

  5. AndyM3
    Posted 10 years ago #

    Hmm, well I guess that one might be a possability. However, it appears it runs off of 2 different directories.

    I found something called WordPress MU, would that help me with what I'm looking for, or is that something totally different.

    Is there any way I can run 2 seperate sites/blogs using one dashboard? (One copy of WordPress/One directory, etc.)

  6. AndyM3
    Posted 10 years ago #

    Sorry, not trying to bump or anything.

    Just seeking if anyone else has any additional advice for me to offer. Thanks in advance, many thanks.

  7. newflesh
    Posted 10 years ago #

    WordPressMU is intended as a solution to host blog sites like wordpress.com – to run your own blogging "community", so to speak. You would still have to manage eight individual blogs, and due to the scale it is less flexible than the regular version.

    Maybe you should look into blog clients to handle your posting: http://codex.wordpress.org/Weblog_Client

  8. AndyM3
    Posted 10 years ago #

    I will look into that, thanks.

  9. AndyM3
    Posted 10 years ago #

    How about Lyceum, or is that virtually the same thing? There's a whole list of things here: http://codex.wordpress.org/Installing_Multiple_Blogs - but I'm not sure which to to try.

    Does any one of them on that list allow you to basically manage ALL blogs from ONE interface? Because from what I'm seeing most of them are just seperatel

  10. AndyM3
    Posted 10 years ago #

    So do any of them allow you to manage ALL OF YOU BLOGS from JUST ONE interface? Just curious..

  11. vkaryl
    Posted 10 years ago #

    If you can use wordpress MU, then I think this is possible. Otherwise, no, AFAIK.

  12. lunabyte
    Posted 10 years ago #

    This is in theory, I haven't tried it. I'll try to explain.

    The "table prefix" is hard coded into the config file.

    Why couldn't someone do the following?

    1) Set up wordpress as usual. Tweak it, set permalinks, and all that jazz.
    Let's say the table prefix for this is "site1__"

    2) Next, duplicate the entire tables for "site1__", but change the table prefix to "site2__"

    3) Edit the db, to change the links to the index and files. (WordPress address and Blog address)

    No need to edit the site title yet, the links would be what matters.

    4) Repeat for additional sites, changing the table prefix and editing accordingly.

    5) Edit the config file.

    Use a check of the url, probably a stristr(), in a sequence of if/elseif logic.

    Something like if stristr(url, domain)) $MyTablePrefix = site_1

    Then, where the table prefix is normally hard coded into the config file, just stick the table prefix variable in there.

    Then anytime the config file is loaded, aka: every page load, it would use the table for the site that is related to the domain.

    Couldn't swap between domains in the admin, because the users would be different and so would the domain, etc.

    That's the basic idea, I suppose. Although, I haven't tried it out and I'm sure it would need refined a tick.

    Thinking about it, I just might have to give it a go. I've got a couple domains sitting around with nothing to do.

  13. vkaryl
    Posted 10 years ago #

    Hiya Luke - if you play with it and it works, please let us know. If you play with it and it doesn't work, please let us know.


  14. lunabyte
    Posted 10 years ago #

    Wow, if that wasn't a wide open door...

    I think I will give it a go. Might take an evening or two, but I really don't see why it couldn't logically work.

    Granted, anytime you would add a site you would need to edit the config file duplicate the tables. But, there wouldn't need to be any hacking of actual core files. And since they tell you to never overwrite the config file, it isn't too big of an issue.

    Great. Now I'm curious, and it won't go away until I know.

  15. vkaryl
    Posted 10 years ago #

    *laughing* Heh. Been there done that. Nice to see there's someone else like that out there.

  16. lunabyte
    Posted 10 years ago #

    Yeah. I'm really bad about it too.

  17. lunabyte
    Posted 10 years ago #

    Well, well well.

    I started messing around a couple hours ago with this.

    In short: It works, beautifully.
    I'll try to keep this as short as possible.
    Here's what I did.

    The set-up:

    I used three domains for this experiment. We'll say md1.tld, md2.tld, and md3.tld.

    All three domains point to the root public html directory.

    The process:

    1) Installed wordpress.

    WordPress extracts to a "wordpress" directory. I didn't feel like moving all the files up a level, so I simply renamed the directory to another name (I used "media", but whatever), and then moved the index.php file up a level. I have other stuff in the main directory, else I could have just did an mv, and made it the new root html dir. Anyway, for testing this worked out nice since it is different than a completely untouched install.

    I did the modification to index.php, to point it to the right place, and put a new index.php in the directory with all the core files that redirect to the one above.

    Next, I added the info to config.php, and installed as normal.

    I made a few minor changes to the default configuration in the admin panel, as I usually tend to do. These included:

    - changed site name to suit the purpose, and description,
    - as well as took out pingomatic (no need to ping with test posts),
    - as well as changed the permalinks to "/%category%/%postname%.html.

    I left the theme set on Kubrick, but I did upload another theme to use later.

    Changed my password. (important)

    Edited the default hello world, and comment. Left them, just changed the data. Did same for default "about" page too.

    Back into phpmyadmin, I edited the user table, and replaced the value "admin" in login and nicename to something different.

    Now that I have a workable default configuration, onto step 2.

    2) Dumped the current tables

    PhpMyAdmin, dumped the tables, saved them in a default local file.

    Made a copy, renamed it to Dump-md2, and then did a search/replace to find the original domain and replace it with the new one.

    Next, did a search for the original table prefix (i used "md1___") and replaced it with the new table prefix ("md2___").

    Next, pasted it back into phpmyadmin, and it created just fine.

    3) Time to alter the config.

    Opened config.php to make the following changes. I will generalize them here, but you'll get the idea.

    - above the db info, i added a 4 sequence if/elseif statement.

    I used 2 stristr functions, and checked the $_SERVER variables
    HTTP_HOST, and X_FORWARDED_HOST for "md1.tld".

    If it returns true, I set a variable to equal the table prefix for md1
    ( $tbl_xtest = md1___ )

    Then added two elseif statements to the sequence, changed the domain i was looking for, and the resulting table prefix.

    The final check in the sequence was a plain old else, which set the table prefix variable to the one i wanted as a default. I used the first one.

    Next, the line where it actually sets the table prefix, I removed 'wp_' and replaced it with $tbl_xtest.

    4) Testing

    I uploaded the new config file, and checked the initial domain. Check 1.

    I checked the second domain. It worked flawlessly. The third was just fine too.

    Now, time to see what happens if I use a domain not listed. Bam. It was the default site, just as it should be.

    I logged into the second site, and made a few changes. (Note, with the duplicated tables, your username/pass is the same.)

    I changed the theme to the one uploaded earlier, and some other things. All were seamless. It was no different than it being two installs.

    In summary, it worked just fine.
    Now for some notes...


    Some may or may not work. In theory, most should. Ones that would not, are ones that create tables in the DB, but don't use the table prefix. I've seen a couple that have done this, at least they did at the point I used them.

    wp-cache? Don't know, don't use it.

    Themes should be ok. As long as it keeps in line with table prefixes, and the site url/file settings, all should be ok. Don't take my word for it though, as I said, I haven't tested any plugins.

    There might be an issue with plugins that want to modify the htaccess file. Look at what it wants to do, and edit it manually to be safe.

    There shouldn't be a problem with multiple conditions for different domains, but you never know.


    Should be fine. Since they are activated in each DB, and follow the settings that are set in the options pages.

    I should note, that any theme customization for a particular domain should be made into a theme identifiable for that domain. I wouldn't recommend allowing the theme files to be writable, just in case.


    Since they are controlled by the database, all is well.

    Final Note:

    This was a test, simply to prove that it can be done. I'm not supporting my changes, only showing you how. This is by far not an option for a novice or noob, that can barely figure out where to edit the style sheet for Kubrick to change the color of the links or header image.

    If you don't know php, and that does not mean being able to cut and paste a tag it means KNOW php, then don't try this at home folks.

    If you have a test site, then feel free to experiment until your hearts content.

    Just remeber, I'm not responsible for anyone messing something up, and all that jazz. ;)

    Have fun.

  18. vkaryl
    Posted 10 years ago #

    Wow. I don't have any need for this, but I think I'm going to have to do it anyway.... I have more domains sitting around doing nothing than you would believe....

  19. lunabyte
    Posted 10 years ago #

    No, I'd believe it. I know exactly what you mean. Projects planned, but never followed through, and the domain is too good to pass up.

  20. vkaryl
    Posted 10 years ago #

    Heh. Yeah. If my husband ever finds out how much they all cost me.... well, divorce court would be a definite probability.

  21. lunabyte
    Posted 10 years ago #

    You mean that isn't how it's supposed to be? Wow.

    The only good part to mine are that if I see one, I'll spring for a full 10 years up front. I had a few that I didn't do that with initially, but when they came due I upped it. I have a couple small exceptions, but nothing significant.

Topic Closed

This topic has been closed to new replies.

About this Topic