We host a few hundred small Drupal 6 & 7 websites on a single Debian virtual machine. Each of these sites has it's own Drupal code base and database.
When we had each site using /tmp as the "Temporary files" folder in Drupal, we would occasionally have file name collisions across sites.
Is making a /tmp/site_name folder for each site our only option to stop these file collisions?
Multisite doesn't make sense when you do multiple sites for many clients. They are on different boxes sometimes (their hosting), and it just is cleaner to have version control for each site/drupal folder vs trying to put 200 sites in 1 svn project for the 200 clients. For us, we had a demo server for each of these sites. and standalone folders mapped to demo1.test.com, demo2.test.com... I got some issues when duplicating a site to another test subdomain server. The error had some /tmp message in it and some other complaints and Denied Access to my site. The error seemed to go away after refreshing the site. but not sure if visiting many sites at a time will cause issue to popup again... Maybe in the long run it makes sense to have a special tmp folder for each site. maybe like you suggested /tmp/site_name or ../tmp if can use file structure like: /var/www/vhosts/site1/public (for drupal sites) /var/www/vhosts/site1/tmp (for tmp dir)... not sure what perms to give it though.
try to install Drush on your virtual server, as it will help you a lot
Drupal provide multisite concept where you can use same module for all sites.
https://drupal.org/documentation/install/multi-site
Related
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/
I have searched for the answer to this question, and have found some similar results, but most seem to be interested in linking a file on an internal website (such as this one: An URL to a Windows shared folder). I am hoping to find a way to link a file on a public facing site.
On my windows server, I have several drives - for the ease of this, let's call them C:, D:, and E:
C: is, of course, the OS.
I have a file share for internal users (those on the same network) on E:. I have the file share location shared internally as \server\data.
I have a public facing website (through IIS) on D:. Let's say the website is located at D:\Website, with the default page being D:\Website\index.html.
Is it possible to create a link on the website that points to files on the E: drive? Like file://server/data/file.txt? Or would it be easier to move the website to the same directory as the file share?
it is possible , but \\server (Windows UNC port 445) is a port that was abused and is blocked by many ISP's for almost a decade now.
Your "public" most likely will not have access
file:/// will not work either , as to the user, that means the persons local machine
what you can do is create a virtual directory to your drive or network share in IIS and make sure in iis (optionally can you can enable use directory browsing)
ftp:// is also a possibility as well and what i think you should look into
I have to move an existing Drupal site from one server to another. I've done so by doing a mysql database export/import and copying over the files to the new server. On the new system, the root page comes up fine but if I try to go to any deeper directory levels I get a 404 Not Found Error.
so drupal.newserver.com -> works fine
but drupal.newserver.com/user -> gives me a 404 and happens,same for all subdirectories
Is there something that I'm missing that is part of a drupal export? Could it be related to the structure of the /sites directory which is under the webserver's docroot?- which has a folder named after the old server (ie drupal.oldserver.com but not drupal.newserver.com? Also, I noticed that there are _htaccess files and .hta files but not .htaccess files in the site files that I've copied over.
Sorry if I'm asking a bleedingly obvious question - I'm very new to Drupal. Thank you!
Check whether the clean url is enabled in your web server. To check try this:
drupal.newserver.com/?q=user.
Just to let anyone who might come across via a google search - I was able to get this to work . It turns out that while mod_rewrite was enabled, what I had to do was to enable the AllowOverride directive for the web directory in httpd.conf to be set to ‘All’. If it’s not set to this, the server won’t respect the .htaccess rules you put into the drupal directory. It’s been a while since I’ve worked with apache config files so it took a while to finally piece it together. The main breakthrough came when I realized that if I turned off clean-urls then the links worked but looked ugly and then was able to research clean_url.
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.
After recent upgrade to latest WordPress version, media uploads no longer work. They return missing temp folder error.
I found out that WP thinks that /wwwroot/wp-admin/ is the temp folder, that's where it is trying to send uploads.
I tried everything to force it to change within WordPress. Setting WP_TEMP_DIR, even tried rewriting core function that looks for temp folder in /wp-includes/text/Diff.php and setting static path.
Nothing works. I don't really know much about Azure, so it's been a pain in the butt.
My last resort is to install and use Azure Storage plugin for WP, but that's last resort.
Anyone can shed some light on this issue? Would greatly appreciate it.
UPDATE: Site is a Azure website, it does not use Azure instance.
http://www.windowsazure.com/en-us/home/features/web-sites/
I'm not to sure about Azure but you can change the tmp directory WordPress uses by using the command below. Make sure to make a folder in your home directory before doing so.
wp-config
define('WP_TEMP_DIR','/link-to-your-folder-you-just-made');
First of all, you should never store anything on an Azure instance, consider it volalite storage just like RAM - if the instance goes down or even gets randomly restarted you could literally get a brand new virtual machine with a new file system and lose everything.
That being said, you can safely RDP into the instance - create a directory (c:\temp for example) and as long as the IIS account has rights over the directory you won't have any issues using it as scratch storage. I would use Andy's approach above (I don't know wordpress, but I know Azure) and simply make sure that it points to a directory that you can use as temp and that the IIS user can safely use.
You may want to log in to the VM with RDP if only for the additional reason that it will give you great insight in how Azure structures the file system for the software it runs, you will see 3 drives and if memory serves one of them is purely a scratch drive that you can use. But it's not persistent, consider that it can get cleared at any moment.
Hope this helps,