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.
Related
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.
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.
So, I'm trying to take advantage of 'Path Variables' (or Linked Resources), in my teams FlashBuilder4 project properties, so that its not such a bear to get a new project out of SVN, and up and running. I'm all done with that, except that I can't figure out what I'm supposed to do for the "Web application URL" .
It doesn't allow me to create a "Path Variable" for http:// type items, only files and folders.
Short of saying that all developers need to configure their servers exactly thus, how can I configure this property so that individual team-members settings don't interfere with other team-members ?
What we do is create Linked Resources to point to a debug directory e.g. project/r11.1/dist in the main project. Everyone has r11.1/dist directory structure within their project. Each person has a local Apache server running, and each person sets up a local Alias in the server for r11.1 that points to whatever location the dist files are stored C:/.../r11.1/.
The SVN only contains the Apache Linked Resource name plus the common folder structure i.e. DISTRIBUTION/r11.1/dist along with the server name i.e. http://localhost.whatever.com/ + {DISTRIBUTION}/r11.1/dist
Does this make any sense in terms of what your after?
Here's what I did to solve the problem. I hate it, but it gets me to where I need to go.
I assigned the "Web Application URL" to the value "https://HOSTS.DASHBOARD.DEV/foo/bar/blah/..."
Then, each of the developers needed, in addition, to create an entry in their HOSTS file, to resolve 'HOSTS.DASHBOARD.DEV' to the proper ip address.
This works (so far), even though I'm less than satisfied with it.
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.