Seeking good practice advice: multisite in Drupal - drupal

I'm using multisite to host my client sites.
During development stage, I use subdomain to host the staging site, e.g. client1.mydomain.com.
And here's how it look under the SITES folder:
/sites/client1.mydomain.com
When the site is completed and ready to go live, I created another folder for the actual domain, e.g. client1.com.
Hence:
/sites/client1.com
Next, I created symlinks under client1.com for FILES and SETTINGS.PHP that points to the subdomain
i.e.
/sites/client1.com/settings.php --> /sites/client1.mydomain.com/settings.php
/sites/client1.com/files --> /sites/client1.mydomain.com/files
Finally, to prevent Google from indexing both the subdomain and actual domain, I created the rule in .htaccess to rewrite client1.mydomain.com to client1.com, therefore, should anyone try to access the subdomain, he will be redirected to the actual domain.
This above arrangement works perfectly fine. But I somehow feel there is a better way to achieve the above in much simplified manner. Please feel free to share your views and all advice is much appreciated.

Since it seems you want to reuse the files/ directory and settings.php from your development domain, I'd suggest using the default/ directory + symlinks to achieve your goals.
ie, during development
sites/default/settings.php
sites/default/files/
sites/client1.domain.com -> sites/default (symbolic link)
once you're ready to switch over to their domain:
sites/client1.com -> sites/default
You can then remove client1.domain.com from your virtual host (or continue with your rewrite, etc...).
It will accomplish the same as your method, but you get the added "protection" of all requests going to default in case you add an additional domain at a later date as an alias (for example).

If you're simply sharing core and module files between the sites, you can use a different symlink layout.
In my setup I have all of the shared files in a common, non-web-accessible directory:
/var/www/drupal
/var/www/drupal/sites/all/modules
then for each deployment, common files and folders are symlinked to those files.
/var/www/client1/public_html/index.php -> /var/www/drupal/index.php
/var/www/client1/public_html/includes -> /var/www/drupal/includes
...
/var/www/client1/public_html/sites/all -> /var/www/drupal/sites/all
Then you can place the site's settings.php and any modules or themes for only that site in the default sites directory
/var/www/client1/public_html/sites/default
This layout also offers you the flexibility to override any common files as necessary, such as .htaccess.
To move from staging to production, you will just have to modify your virtual-host configuration from the staging to production domain name.

If you don't like a ton of symlinks, another option is using the Aliased Multi-Site Support patch:
http://drupal.org/node/231298#comment-1420180
This will allow you to specify in configuration that any requests for client1.domain.com should actually use /sites/client1.com/ instead of /sites/client1.domain.com/.
Then when you move to production, you can just remove the configuration setting (though it doesn't hurt anything if you don't).
This feature is part of Drupal 7, but as a new feature won't be added to Drupal 6. More good news is that you won't even need to use it in D7 just for file paths, since instead of storing the full path to files in the database, they use a schema such as public:// or private:// which Drupal then maps to the correct file system path, allowing multiple storage types/locations with much better portability.

Related

Load-balance wordpress site

I would like to have a scalable infrastructure for my wordpress site. We currently have the following:
A cloudfront that serves the website
A load balancer and target group with only one registered target in it
An RDS.
The WP server (on which config, and wp-content is).
We have several thousands of pages in the wordpress instance, and sometimes we need to make changes, invalidate caches in the cloudfront to serve the new content. Doing this on a lot of pages can create a huge load on the server, and make it unreachable or super slow. So we thought about adding an autoscaling group, which would spin up new instances if the load is too high, and remove then when necessary.
To do so, I believe we need to move the wp-content folder to a shared directory (between all the servers). Is it a correct assumption first of all?
So I naturally created an EFS, which I mounted on a copy of my wordpress server, then rsync all the files with permissions in the efs.
Then as suggested all over the net, I added the following in my wp-config.php:
define('WP_CONTENT_DIR', '/mnt/efs/wp-content'); where /mnt/efs/wp-content is directory on the efs.
From this point, the website worked as expected, I could see some traffic on the EFS monitoring page when viewing pages.
To make sure all the files are correctly shared and copied in the wp-content, I deleted /data/app/wp-content/ folder (it shouldn't be used, as I referenced wp-content to be in my efs).
And my site started acting weirdly. Some formatting disappeared, buttons are native and not customized etc. The console shows a lot of 404 also with following errors:
www.mysite.eu/:1 Access to font at 'https://www.mysite.fr/wp-content/themes/mysite/dist/fonts/icomoon/icomoon.ttf' from origin 'https://www.mysite.eu' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
GET https://www.mysite.fr/wp-content/plugins/js_composer/assets/lib/bower/font-awesome/webfonts/fa-solid-900.woff net::ERR_FAILED 200
Looks like there are no fonts, no plugins, no themes anymore.
So, quite a few questions:
Do I need to keep both local wp-content and shared wp-content? If so, if I install a plugin or a theme, would it be available for other servers as well?
Do I really need an EFS? Or data is fully stored in DB, and wp-content can live on its own for each server?
Are there any other steps in moving the wp-content folder? Maybe specific steps for some plugins?
Is my architecture lacking anything for what I would like to achieve (scale up and down based on demand), or does that make sense?
Thank you!
Don't put wp_content on a shared file system (s3 bucket). It contains a lot of theme and plugin code, and running code from s3 can cause performance trouble and crank up IOPS costs. Instead, use a plugin to offload your site's uploaded media files (jpg, etc) to the s3 bucket, then clone the site.
Use a shared persistent object cache if you can. redis is a good choice.
AWS has a tutorial about doing this, without the cache, on Lightsail. https://aws.amazon.com/getting-started/hands-on/launch-load-balanced-wordpress-website/

Is doing drush archive-dump enough to transfer a drupal site to another server?

I am relatively new to Drupal. I have a drupal site on my staging but I would like to transfer the site to production server. My question is: Is doing drush archive-dump enough to do this? I tried doing this and it seems like the site is not loading the configurations correctly? I already executed the sql commands from the file generated by the dump.
There are three components to moving a Drupal site to another server:
Database
Code
Files (e.g. files uploaded by content creators; usually sites/all/public)
drush archive-dump is specifically there to grab all three and tar them. So yes, that is all the data you need. There can be other issues (e.g. server permissions; software versions; DB credentials; etc...)
To go live you need to:
Test your site in the same environment as production site have.
Move code to production server.
Move database to production server.
That's all.
Please read:
http://www.slideshare.net/erikwebb/the-basics-of-smart-drupal-deployment
https://www.drupal.org/best-practices
Almost. It seems that archive-dump will not include the Private Files Directory if it resides outside the DocumentRoot.
Some administrators will place the Private Files in a directory such as DOCROOT/sites/default/files/private/ and although Apache 2.x should deny access to this directory directly via .htaccess rules, placing this outside the DocumentRoot entirely ensures that protection regardless of HTTPD service...
So no, archive-dump is coming up short if you have Private Files outside your DocumentRoot directory.

Configuring Drupal for Upstream Deployment

I'm trying to help a co-worker configure a Drupal site so that we can deploy the same site upstream without making database changes. We're having trouble with file paths. Here's what I have:
A Nginx webroot pointing to the root of my Drupal 6 (in this case) install (/opt/frameworks/drupal-6).
The content for this site is in /opt/www/my-site.
A symlink exists in /opt/frameworks/drupal-6/sites: dev-my-site -> /opt/www/dev-my-site
Because of some sharing that's going on, there are multiple versions of my-site on the box, so they have to have different symlink names. Right now, the "file system path" is set to sites/dev-my-site/files which breaks when moved upstream.
Is there a way that I can set a configuration variable to override the database setting? Or is there a better way to configure my webroot and sites? I don't know much about Drupal, but I'd like to build this out so that deployments are as simple as possible.
A bunch of trial and error by 2 inexperienced Drupal folks has led to a possible solution. It looks like setting the $conf['file_system_directory'] in settings.php does exactly what we need. Each site on each box will have it's own settings file that isn't touched by deployments, so we might be all good.
If there's a better way or if there are unintended side effects to this particular way, I'd love to hear answers from more experienced Drupal admins.

Which config files for a LAMP Drupal site should be held in source control?

My team are generally .Net developers but we are currently building a Drupal site, so I am less familiar with standard practice for the LAMP stack.
We finally have the servers configured how we need them to be, so I want to make sure the relevant config files are put into our source control system, so we can track any changes.
I have taken copies of the files below, but I'm not sure if there are any other files that I've missed:
httpd.conf
php.ini
.htpasswd
We already have a strategy for storing the Drupal modules and so on and we don't have any .htaccess files, but are there any other config files that I should be storing for a LAMP-based Drupal site?
Depending on your configuration, you may have used virtual host files and might need to reference /etc/apache2/sites-available/vhost and/or /etc/apache2/apache2.conf as well as /etc/apache2/conf.d/servername.conf.
You may also have certain settings in /etc/php5/apache2/php.ini, but again it depends on how you set up your lamp-stack.
As well as .htaccess, you should reference the drupal file settings.php, if only for security.

Interacting With Folders Outside The Root/Web Directory With Dreamweaver (CS5)

Using FileZilla, I can access folders that are outside my web directory. How can I do the same with Dreamweaver so that I can edit the files and automatically save/upload all through Dreamweaver? I currently can only access the web directory.
I know how to include them with PHP, but I would like Dreamweaver to find/access them.
Thank you!
You would have to set the Site Definition (both local and remote) paths to look one level higher than you currently have it. So if the local path is
My Documents/Web Sites/This Site
you would change it to
My Documents/Web Sites/
and if the remote is:
/user/home/domain.com/
change to
/user/home/
The problem you are going to run into is that Dreamweaver doesn't work well when set like this. It assumes the Remote path is the public web root and will create all sorts of files and folders there automatically and DW expects those to be in the public root. Also, things like setting paths to includes and images automatically will start to not work as all paths will start outside of the public web root.
Best to leave it as it is and use an external FTP program to handle the files outside of the web site.
We've bumped up against this situation previously where the desire was to have the PHP include files be moved outside the public HTML directory. JCL1178's answer is absolutely conceptually correct.
The actual implementation was to duplicate the site (under "Manage Sites") and essentially create a separate site for the "includes" directory that would go one level up. So the "Root Directory" setting was normal (in our case "public_html/" in the main site and we removed "public_html/" from the Root Directory setting in the "includes" site, effectively causing the path to go one level up.
Definitely not an ideal situation/workflow, to say the least, as you'll end up with two site definitions for one site (which can cause other issues); but Dreamweaver is what it is. We were working on a project offsite that did not allow for anything other than Dreamweaver to be used, so this is what we came up with to comply.
As an added note: we were only able to implement this solution because the webhosting plan allowed us to get to the root. If you're on a webhosting plan that is strictly limited to the public directory, the whole thing will be DOA.

Resources