Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In with Google Sign In with OpenID

Multisite Functionality

edited April 2013 in Framework

Can elefant be setup to serve in a multisite environment like WP Multisite with domain mapping and so forth? Or is it possible to setup a single location on a server and symlink files into the site? Either way, just looking for some suggestions. I'm looking at possibly converting all of my sites to elefant from WP.

«1

Comments

  • You can get partway there by setting a per-domain ELEFANT_ENV environment variable (info about that is here). This will make Elefant use a separate config for each site to separate the database, theme, etc.

    The main limitation you'll hit is with the File Manager, since the sites would all be sharing the same /files/ folder path. It would probably take refactoring that app to use a configurable root folder, which wouldn't be too hard to change, just hasn't been done yet.

    A few other areas that may need tweaking are the navigation, since it writes to conf/navigation.json which would need to become a configurable file name, and the designer and translator apps, since those expose shared files as well. In a multisite setup, you can probably just remove the translator and designer apps and be fine without them.

    Off the top of my head, those are all the limitations I can think of for now.

  • Do you offer customizations or setup on a paid basis?

  • At this time I'm not able to myself (just too busy atm), but you could ask others on here. @betaman, @gareththered, @indytechcook, @Mike, @shortj, @twheel, @wokkie, anyone interested? :)

  • hI jevansnc,

    sorry I'm fully booked as well at the moment, which is kind of :-( and :-)

    Cheers betaman

  • edited April 2013

    To be honest, this customization doesn't make any sense to me. We have used multi-domain setups in things like silverstripe, where there is a fairly high overhead, and it can be minorly useful, if somewhat troublesome to maintain.

    But Elefant is so streamlined, fast and low resource that this would be a waste of time. If you want to save on hosting costs, just look for a hosting account which gives you multiple websites - which many web hosts offer - rather than having a multi-site solution with elefant. That'd would be my recommendation anyway.

  • Good point. Really, a multisite setup really only makes sense when the sites all belong to the same organization, for sharing content in some way. Otherwise, for security between sites it's definitely best to keep separate site owners on their own copies with their own separate web space.

  • Well the main reason come from the nightmare of managing multiple sites for Wordpress. Does elefant require the amount of updating and maintenance that wp requires? Also thanks for all the quick responses.

  • Can't take on anything new at the moment either. But I will say that it was frustration with WordPress that caused me to switch to elefant for new sites.

  • WP was great at one time but I don't feel it is a good platform as a developer or designer to build a business on.

  • So with all of these mods would it be possible to get a multisite functionality going? I'm not hell bent on it as I don't think elefant is a nightmare to administer like WP for the longterm.

  • I was going to add that if you do make the changes to make the navigation.json, /files/ prefix, etc. configurable via app settings, that could be integrated back into the core.

    Then setting up multisite installs, even if they're only recommended for sites that share a common owner, would be much easier to setup (setting ELEFANT_ENV plus a bootstrap.php file could probably even do it).

  • I'm not looking for a traditional multisite functionality as in the way wordpress has with subdomains, or subsites, etc. I'm more referring to having a central code base for the CMS so updating down the road is easier. The CMS would be hosted on fully qualified domains as in www.site.com. We have some custom plugins from WP that we want to migrate to work on elefant and we had intended on using the method of loading those plugins to a central place that WP offers. Anyways either a single codebase or a command line method of updating elefant on all sites without interfering with customizations made to the CMS in regards to branding or custom options or apps. Sorry if I'm rambling. Perhaps someone could write a shell script that could update sites from the command line and not effect files like product.php for instance.

  • @gareththered In most sites ELEFANT_ENV would always be config and there would only be one navigation.json to worry about too. In the usual use of ELEFANT_ENV, we're just switching config files for staging/dev/production servers, mainly for database settings and debug/display_errors, but we would want the same navigation.json across them all too.

    I think it can be broken down into two parts:

    1) Making the navigation app look for the path to conf/navigation.json from a setting (same for the /files/ path in the File Manager), but not to be dependent on ELEFANT_ENV themselves.

    2) The setting can be dynamically set use ELEFANT_ENV in a bootstrap.php file in the site's root. So for multisite setups, it would require two steps, setting up ELEFANT_ENV, and dropping a bootstrap.php into place.

    That way the core behaviour stays relatively unchanged, but both can be accomplished easily enough. The changes in #1 are still required to support the multisite setup in #2, but this ought to keep them cleaner too.

    A sample of what I'm thinking in a bootstrap.php might be:

    <?php
    
    $nav_file = 'conf/' . ELEFANT_ENV . '-nav.php';
    conf ('Navigation', 'path', $nav_file);
    if (! file_exists ($nav_file)) {
        copy ('conf/navigation.json', $nav_file);
    }
    
    ?>
    

    @jevansnc You probably want to take a look at our Composer support for managing apps/themes. Composer looks poised to become the standard for installing/updating PHP libraries, and seems to be a great way to keep apps up to date as well. You can even define scripts to run post-update routines like schema updates.

    As for Elefant itself, we've added a ./elefant update command line updater, so we'll be using that to keep the core CMS updated as well, since it's a bit outside of the scope of what a Composer package is meant to handle.

    The update command uses diff and patch and tests with a dry run before applying the updates to make sure they won't conflict with changes you've made from site-to-site. It's a very recent addition though, so the next beta release will be the first that can make full use of it (although I've tested it manually with older releases). Of course there's also a ./elefant backup command too :)

  • Does that command update all sites or just a single site? Would it need to be run on a per site basis? Again sorry for all the questions. Just formulating a road map of sorts here.

  • That would update a single installation.

  • is the ./elefant command just hitting a php script? Could it be hit using a wget or something similar or I'm assuming since the command is interactive then that would be no.

  • The script is just PHP but it won't run from the web, although to be extra safe you can either chmod 700 elefant so web requests get a Forbidden message trying to read it, or run pear install conf/package.xml to install it globally (see here for more info on that) then remove it from the individual sites.

  • Wow you guys are awesome. I really wasn't expecting my thoughts to spur anything. The only reason I mentioned multisite is because as a developer while the core of the way WP carries it out is flawed it was a huge life saver. Most clients whom are using a CMS don't care about FTP or getting into the backend of anything. They want it to be as straight forward and easy to use as possible. I really think elefant excels at all of that. I'm just really impressed by the project and the ease of setup.

  • I think in this case it just looked cleaner being on separate lines, although you could format it like this and it isn't too bad:

    $page->add_script (
        '<script>'
        + 'var filebrowser_max_filesize = ' . (int) ini_get ('upload_max_filesize')
        + ';</script>',
    );
    
  • So in the end is it possible to have a multisite type environment? I'm not even really looking multisite in terms of how WP handles it but more of a centralized way to have cms and app files in a centralized location. If it is possible could you put a quick and dirty blog post or something together on how to accomplish this?

  • We're a lot closer now! The ELEFANT_ENV trick above to swap configurations now lets you set a per-site file manager path and separate navigation file in the settings too.

    The designer and translation apps should probably still be restricted from individual site owners, and there will be a few other quirks like the layout selection in the page editor's extra options, which would list all of the installed themes and not just the ones for the individual site.

    We also decided to add admin-level access control to 2.0 instead of pushing it back to 2.2, so once that's ready you'll be able to create a "site owner" role that can give you more fine-grained control over what each site owner can see (e.g., hiding the designer and translation apps).

    Once the access control stuff is done, I'll definitely put together a tutorial about it. If you need help before then, send me a message.

  • So would you be able to have a central admin like with WP Multisite and then just assign editor type role users to the individual sites? Would the sites as well have fully qualified domain names or would they be subsites? The only other question would be how are apps handled? I wouldn't think you would want all apps pushed to all users? An ideal situation would be to have the ability to store them centrally on a server somewhere and then symlink them in but that would become a problem I'm assuming if you approach this is a multisite fashion. I, myself am looking something that can just be a CMS for several sites but with individual databases, users, etc. but keep the same code base for the CMS and Apps. That way changes/updates are universal to users. Anyways thanks for your continued work.

  • Since the sites would each have separate databases, the file structure would be common to all sites (with separate folders for uploads, and configs unique to each too, but with shared layouts and apps). So there wouldn't be any kind of master admin for managing users between sites, unless that was built separately (likely on a separate "admin" site).

    Each site would essentially only be defined by its virtualhost entry, each pointing to the same folder:

    <VirtualHost www.example.com>
        DocumentRoot /var/www
        ServerName www.example.com
        SetEnv ELEFANT_ENV example
    </VirtualHost>
    

    The rest is up to the configuration for that site. That will cause it to switch from the default configs to this:

    conf/config.php          -> conf/example.php
    conf/app.blog.config.php -> conf/app.blog.example.php
    conf/app.user.config.php -> conf/app.user.example.php
    etc.
    

    And in your conf/example.php you would change things like these:

    site_name = "Example Inc"
    email_from = "joe@example.com"
    default_layout = "example"
    navigation_json = "conf/navigation.example.json"
    filemanager_path = "files/example"
    master[file] = "conf/example.db"
    

    Once the ACL stuff is ready, you'll also be able to limit access to different apps if you create a custom role for your site admins, which would look something like this:

    ; <?php /*
    
    [master]
    
    default = Off
    admin = On
    designer = Off
    translator = Off
    
    ; */ ?>
    

    Hope that gives you a clearer idea of how it will work.

  • Will converting a current elefant site to this setup be an issue in the future?

  • I think it should be okay to convert a site with this without much trouble.

  • Could you possibly write a step by step blog post on setting up multisite. Also a blog post on ACL would be great. Is there a way to avoid setting up multiple users but also limiting access. Something configurable from the conf file would make life great especially in a multisite environment.

  • For ACL, end users should really only have to go through the GUI to manage roles. There's not much beyond that, except understanding what each option means when defining roles (all of which needs to be added to the docs still).

    For developers, the info in the blog post is really all there is to it.

    For multisite, I'll see what I can do when I have a chance, but my previous post does contain all the key elements. If you try them out and get stuck, let me know where and that will help put together more complete docs.

  • Where would the core files of the CMS be stored?

  • I think I got it down to a one-liner:

    SetEnvIf Host ^www\.(.*)\.com$ ELEFANT_ENV=$1
    

    And @jevansnc, your Elefant files would live in the document root shared by your sites. So for example, on my dev machine I have the following virtualhost setup:

    NameVirtualHost www.multisite.lo
    <VirtualHost www.multisite.lo>
        DocumentRoot /Users/me/Sites/multisite
        ServerName www.multisite.lo
        ServerAlias www.foo.lo www.bar.lo
        SetEnvIf Host ^www\.(.*)\.lo$ ELEFANT_ENV=$1
    </VirtualHost>
    

    So I can access the same virtualhost as http://www.multisite.lo/ http://www.foo.lo/ or http://www.bar.lo/ (.lo being my lazy version of using a .local top-level domain to denote localhost sites vs real ones).

    And with the SetEnvIf line in place, it will now load conf/multisite.php when I visit http://www.multisite.lo/ or conf/foo.php when I visit http://www.foo.lo/ or conf/bar.php when I visit http://www.bar.lo/

    From there, it's just a matter of customizing the config file for each site.

  • Hey @jevansnc, I've started a page to document the multisite stuff here:

    http://www.elefantcms.com/wiki/Multisite-setup

    Not really much more than what's in this thread yet, but it's a starting point for expanding on at least.

Sign In or Register to comment.