I am using Lando for local WordPress development.
But because it relies on Docker the performance isn't great out of the box. To solve that problem the Lando devs say we can exclude files and folders from Docker to speed things up.
So far I have excluded three folders in my .lando.yml file, like so:
name: my-blog
recipe: wordpress
config:
webroot: .
excludes:
- wp-admin
- wp-content
- wp-includes
This has made the WordPress admin and front end considerablly faster on my local machine.
But then I tried to squeeze out every last bit of performance by excluding the entire root wordpress/ directory, like so:
name: my-blog
recipe: wordpress
config:
webroot: .
excludes:
- .
When doing this I ran into issues where changes on the site (such as edits to pages etc) were not being saved.
With that in mind I have three closley related questions:
Why I can exclude those three folders mentioned above but not the root directory?
What are the potential draw backs of excluding even those three folders I mentioned above?
What are the exact WordPress files and folders that are considered safe for exlcuding this way?
Why I can exclude those three folders mentioned above but not the root directory?
It depends on what files change. Excluding a folder means only the copy inside of the container is used and you'll have to rebuild to pick up any new changes.
Think of it like this, without exclude you're creating something close to a symlink. This is where the slowness comes from, every time a file is touched in the container the filesystem has to reach outside of the container and get the file from your local filesystem.
Adding an entry to exclude is basically making a copy of the file inside of the container that does not get updated.
What are the potential draw backs of excluding even those three folders I mentioned above?
Any changes you make on your local machine in excluded folders will not be reflected in the container like you're used to happening.
What are the exact WordPress files and folders that are considered safe for excluding this way?
This depends on what you're doing honestly and how you've installed WordPress. If you've installed it via a package manager, excluding those managed folders is typically very beneficial (ie, vendor/node_modules/etc). If you do this and make changes via your package manager, you'll have to rebuild the container or ssh into the container and rerun the package manager
But it really depends on what you're going to be changing. If you're working on a plugin or a theme then you'll need to ensure the plugin or theme folders is included, and so on.
For parts of the filesystem you aren't touching or aren't concerned with seeing, it is probably safe to exclude those. They will still work within the container, you just won't have easy access to inspect anything created/altered.
Related
I have recently been working an application that will soon need to be moved from one server to another. (Testing environment to live environment). The problem I am having is how can I make it so when I move folders, it will still work without need needing to change directories.
Example -
<?php include $_SERVER['DOCUMENT_ROOT'] . '/arcade/layouts/_header.php'; ?>
Here I include a layout file called '_header.php', the problem I will have when I move the test environment to the live is that we will need have the folder '/arcade' so this will be looking for a folder that doesn't exist. I could use ../ or ./ but then I couldn't be able to use $_SERVER['DOCUMENT_ROOT'].
My initial thought was to have a _config.php and in it have global variables such as
$root = "/arcade";
Then when I move from the test to the live I just have to change 1 value from "/arcade" to "" and possibly the directory to the config file.
Just looking for some insight for managing folders and files across domains
Having a configuration file is desirable anyway. Anything that is a parameter of the application (locations, access parameters etc, feature toggles, other flags etc.) should be defined there.
What is even better if you have a local configuration as well. In the configuration you can check if a local configuration exists (say config.local.php) and include it if it does at the end. This way you can have a minimal, possibly unversioned, environment specific override for settings that you need.
I want to backup my existing ASP.net web app before updating it.
Therefore I create a backup folder inside the website (ie same level as App_Code, web.config). Call it something like Backup_20110910
Then I move all the current website files/folders (excluding web.config, app_data) into the backup folder.
Then I extract the zip of the latest code in the now clean folder.
Is there any potential problems with this approach? As after all, you are increasing the number of csharp files in your website folder, could there be conflicts etc.
I wouldn't back up within the folder structure, there's a possibility that someone then finds your backup folders and browses to them, running the older code. If you zip it then you suddenly have files someone can download too. Even more amusingly if, as a lot of people do, when you change web.config you rename the old one to web.config.bak a lot of security scanners look for that because now it can be downloaded, as it's no longer a .config file, but a .bak.
Backup outside the web root, not within and all of those worries will go away.
There won't be an issue - except that it might become confusing to have identical folder structures within the current folder structure - it's always wisest to keep backups completly seperate from the current build
I would like to move a test Drupal installation from
/opt/lampp/htdocs/corporate/internet
to
/corporate/internet
What corresponding changes changes do I have to make in .htacess, settings.php and/or other settings?
That depends on that how your sites/ directory is set up. If you just have a default directory within, they you really should be good to go.
Mostly, you don't have to make changes. This is because Drupal installations tend to be set up to use relative paths that will be valid no matter where in the system it is. You may want to do a quick search of any custom code for the string /opt/lampp/htdocs to see if someone didn't do something relatively, but any other contrib code should work fine.
As Jubal mentions, sites set up in the sites directory may need renaming if you're going to be using a different URL to access the site - if you're moving from devel.site.com to www.site.com, and you have a sites/devel.site.com directory, then you're probably going to want to copy that directory to sites/www.site.com. On the other hand, if you're using sites/default for your site, or if you're not changing the url at all, then this isn't a problem.
Do note that the .htaccess in the root directory of Drupal is very important for Drupal to work, and that doing a simple cp -R of the directory will not copy the .htaccess, so make sure you copy that. (.htaccess files in sub-directories, like sites/default/files, will be fine, it's just this one in the root.)
And finally, check your file permissions after you move the files. You'll especially want to make sure that the file permissions for the files and tmp directories are correct so that people can properly upload files. (This may not be important - but it's something to check nonetheless.)
I have recently moved a drupal site. (both servers run on a debian based LAMP stack) Everything works great here, including the uploading of images via a CCK filefield. Original url:
dev.example.com/foo
Deploying it to a test folder on the production server to a test folder for an environmental shakedown cruise lead it here:
www.example.com/foo
Everything works here too, including image uploads. After adjusting sites/default/settings.php, then making it readonly again, I renamed the folder to its production name:
www.example.com/bar
Everything works fine here except for image uploading. I've adjusted the webroot variable within settings.php .
Things I have tried so far:
Gave php system user write permissions to sites/default/files (images are set to go in sites/default/files/images but imagecache just puts them in sites/default/files)
Enabled file php file uploading for www.example.com/bar/sites/default/files
Are there any other configuration settings I should be looking out for here? I'm running low on relevant solutions.
Edit: I had quite the typo there, I adjusted sites/default/settings.php, not sites/default.settings.php .
Your question is slightly confusingly framed. default.settings.php has no impact on Drupal -- its merely a template. The file that contains the actual database connection information and other configuration is settings.php.
You may also want to look at your .htaccess file in your root Drupal folder and try changing the RewriteBase directive to the folder you are accessing your site on. Usually you should not have to change the $base_url directive in the settings.php file that you may/may not have done. Reverse that change for now if you have (you may need to play around with that later though).
imagecache will always upload the image derivatives in sites/default/files but imagefield will upload the original image in the folder you specify (within sites/default/files). You will get a setting for the imagefield under Manage Fields->[Name of Image field]->Configure under Path Settings.
Please google to understand the difference between imagecache and imagefield. Make sure your sites/default/files (and subfolders) are writable by the apache user (usually www-data).
In such situations, its usually a good idea to pick up a book on apache (if you haven't already) and try to understand how it works. It will be time consuming but will help you out in the future when you encounter configuration issues like this.
This worked for me. When having issues uploading images to a cck field, I gave write permissions to directory:
sites/default/files/field/image
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.