• Hey All,

    Recently setup a proof of concept within my organization for running our custom website product off of wordpress. We currently host about 2000 custom sites and are launching about 100+ a month. Hardware is not an issue, we have load balanced environments with fail over etc.. so from a technology perspective we aren’t challenged with the load.

    However, I am struggling with the best way to install wordpress. I currently have it setup (successfully) using subdomain with the multisite feature enabled. I can spin up sites, map domain and assign users to sites. I am listing a few questions below, and would love to hear insight as to what I am doing wrong and what I can do better based on my needs..

    1.) We have 2000 custom designs, will loading each of these into the MS install cause the backend to slow down? The overall goal is that each site will have its own design since all of our work is 100% custom. Im nervous that this many themes will be hard to manage.

    2.) File uploads: If i wanted to upload a file like sitemap.xml or a straight html file to one of the network sites and have it serve-able from the root (ie. site1.wp.dev/sitemap.xml or https://www.site1.com/random_page.html) how would I accomplish that since each site doesnt really have its own file system?

    3.) When setting up plugins, how can i have some plugins persist their settings onto the sub sites? I saw the YP-plugin-options plugin… but this plugin just pushes the changes to the rest of the site tables, I’d prefer a solution that just store the options to the main site table and use it from there only.

    4.) Finally, is this the way to go for me? Would I be better off creating a core file system somewhere, then symlinking installs to it? Each site would then have a working folder with its own theme and I could symlink the core system files… I can elaborate on this but Im sure you get my drift.. My only concern with this is that the users are then broken out per site and we have over 100 users in house that I dont want to maintain on every single site individually…

    I’m open to any and all suggestions.

    Best
    -Sam

Viewing 8 replies - 1 through 8 (of 8 total)
  • Moderator Ipstenu (Mika Epstein)

    (@ipstenu)

    ?????? Advisor and Activist

    1) Shouldn’t, since each design (i.e. theme) is only called by the site that runs it. Hard to manage, maybe, but it won’t slow things down.

    2) Very carefully via .htaccess – Some people have done it. Search the forums.

    3) It’s YP or nothing at this point.

    1) the only place you *might* see a slowdown is the Appearance menu. But that’s been redone in 3.1 for scalability. So.. not so much anymore.

    3) you’d be hard pressed to find anything that just pulls from the main site tables.

    Thread Starter Sam Napolitano

    (@eightamrock)

    Firstly, thank you both for the responses. I see you both commenting all over this forum, so I am glad that I have the top minds here.

    So 2 questions with your answers:

    @ipstenu for #2 do you think that 2000+ lines in the .htaccess will be an issue? I know in the past we have had trouble with redirects that got around the 500 line ear mark…

    @andrea_r for #3, since our install is static, meaning our core tables won’t change and there’s no chance of the network structure changing, could plugins be written that are network activated and read their settings from the core tables? To me it seems plausible, but I’m not sure if there is some trickery in WP that wont allow me to activate a plugin that doesn’t read that sites tables.

    Thanks again to you both… I will probably be a WP expert once I am done figuring out this install and writing about a dozen custom plugins… lol

    Moderator Ipstenu (Mika Epstein)

    (@ipstenu)

    ?????? Advisor and Activist

    Hrm. Honestly I don’t know, but I was thinking that with a clever htaccess you can re-route with regex and spare yourself some lines.

    For ‘straight HTML’ I would use WordPress’s built in Page functionatlity, and skip the need for extra work. And there are sitemap plugins for MultiSite, so again, no need to reinvent the wheel there.

    In GENERAL, though, when you need external per-site files, it gets messy.

    2000+ lines in htaccess is too much. If you need that many lines, you should look at editing the Apache httpd.conf file and putting the appropriate code in the virtual host directives.

    You can do nearly anything with a plugin. The problem today is that multisite is fairly new to the plugin development community and it will take time for (1) multisite to grow in popularity and (2) plugin developers to make the appropriate changes. That being said, plugins can be made to do anything, including reading any and all tables in the database.

    You can wait for others to do it or, as you hinted at, you can become a multisite plugin creator god and write your own for your custom functionality.

    could plugins be written that are network activated and read their settings from the core tables?

    oh heck yeah! ?? have a look at things liek buddypress and some of the multisite plugins out there iwth global options. This one https://www.ads-software.com/extend/plugins/network-privacy/ has global options, for example.

    And party to what ipstenu said, before you go writing plugins specific for multisite, check & see if they exist first. likely they do.

    use the multisite, wpmu and wordpressmu tags in the plugin repo.

    Thread Starter Sam Napolitano

    (@eightamrock)

    Thanks for the help!

    I have been researching a ton of plugins… do you guys know off the top of you haed, whether modification of a plugin is ok via the GPL as long as I give credit for the origin?

    Thanks again, great advice!

    GPL applies to redistribution.

    you have the freedom to modify the code as much as you like.

    you also have the freedom to redistribute it as you see fit. as long as it’s still GPL.

    Yes, keep the credit there too.

Viewing 8 replies - 1 through 8 (of 8 total)
  • The topic ‘Enterprise Install Ideas?’ is closed to new replies.