I have developed a site in the url www.example.com/demo on now i want to move the site to www.example.com on the same server what are the steps that are to be taken to move the site on the same server with the same database.
Just copy all the files from demo folder to root folder. Since Database configuration in file will be same, so you don't need to change those.
In database Run this query
SELECT * FROM core_config_data WHERE path = 'web/unsecure/base_url' OR path = 'web/secure/base_url';
change base secure and unsecure url to www.example.com.
Clear the cache and your are ready with www.example.com
I do a similar thing to you. I have a subsite set up for testing before I push to production. I simply copy the files (using git) and the database whenever I want to update production. However, these are two distinct sites with their own directory structure and database.
So, in order to keep things "simple" (ie I don't need to redo things every time), I have untracked versions of app/etc/local.xml so each site connects to the right database and on the production system I have a module to set my secure and unsecure urls (see here for more detail than you probably want: Unable to set base url from config file).
Good luck
Related
I am using shared hosing for Codeigniter application for deployment.
How can i run staging url on live server?
1) domain.com (Working)
2) domain.com/staging/ (Not working, showing 404 error)
I created staging folder under public_html directory, now put All CI code in staging folder, and tried to run the application with URL domain.com/staging/ but it redirect on domain.com/404
I expect to run domain.com for users and domain.com/staging for development. (Staging URL i will use for development and after that i will place the same code for live URL.)
This is most easily done by using a subdomain for the staging version, i.e. staging.doman.com. The folder where you put the CI files isn't super important as the subdomain will be set to use the directory you choose.
You will either need to have complete control over the server or have a service provider that allows you to set up subdomains.
- Expanded Answer -
If you cannot set up a subdomain then your next best option is to use the advice in the documentation on Managing you Applications. It isn't required to use the file structure shown there. In your case try the following.
Create a folder on the same level as application named staging.
Into that folder copy all the folders and files normally found in /application.
Add all application folders and files required by your site. The files in these folders are those that make up the application you are staging.
Make a copy of index.php (the file at the root of the public folder, i.e. domain.com/index.php) and name it staging.php. Both index.php and staging.php will be in the same folder.
Edit staging.php and change the value of $application_folder to be the absolute path to the staging folder. For example:
$application_folder = '/path/to/domain.com/public_folder/staging';
The path above is an example. You must replace it with the actual path in your server. If you have no idea what the full and absolute path is you can use
$application_folder = dirname(__FILE__).'/staging';
Browse to the URL domain.com/staging.php and you should get your default controller's output. To test that you are actually seeing the staging version of the page temporarily change something in the view file so there can be no doubt.
You will go to other controllers by using the URL domain.com/staging.php/other_controller.
Change the value of $config['index_page'] in /staging/config/config.php to staging.php, e.g.
$config['index_page'] = 'staging.php';
Without the above change redirect() and many other "helper" functions will not work correctly.
(Optional?) You can probably edit the main .htaccess and add rewrite rules for staging.php the same way it is done for index.php. But I will leave that as an exercise for you. (Or for another SO question.)
A final word. It might be necessary to make other configuration changes to accommodate the revised file structure. I tested the answer here but did not go beyond the most basic task of browsing to controllers. Most likely config values for sessions, cookies, and many others will need to be adjusted for the staged version to work correctly. Check out the documentation on Handling Multiple Environments for guidance on making this less painful.
I am trying to transfer my website with jomsocial from one server to another.
www.iremember.gr
Previous server steps:
Backup all the files from public_html folder.
Backup the DB from php my admin.
New server steps:
Install joomla, entered the prefix in DB of the previous DB prefix.
Deleted all files from public html and extract the backup from the previous server.
Export the DB from the previous server, to the new one.
Changed the configuration.php file with the new user/dbname/password.
Now when i try to enter the new server at this IP address
93.174.121.23/~niremco/
and i login ok.
It loads the main page
but when i try to enter a profile i get a 404 Error.
Although when i try to see the profile
http://93.174.121.23/~niremco/index.php?option=com_community&view=profile&userid=109
i can see it.
But not from the correct link that i had in the previous server
http://93.174.121.23/~niremco/team-iremember/profile
Any idea why this happens?
You probably haven't copied the .htaccess file from the old website, you will need to copy it from the old Joomla website to the new one. This typically happens because the .htaccess file is considered to be a hidden file and as such does not get copied over automatically.
First of all, installing a clean Joomla first is totally unnecessary. As for why you are getting the 404 error pages, this is because you probably have URL rewrite enabled in global configuration, while there is not a proper .htaccess file sitting in your new server.
With proper I mean either no .htaccess at all, or one that was setup for your old hosting. I rather tend to think the second.
To test that your moved correctly your site, disable url rewrite from global configuration.
If you would want to test with url rewrites enabled, then I would suggest to edit the hosts file in your computer and point your domain to the ip address of the new server.
Google Search: How to edit my hosts file - choose the resource for your OS.
How do I duplicate my production site to a preprod domain?
I have a live site # www.theprinterdepo.com
I have a sub domain preprod.theprinterdepot.net
I copied the folders over to the folder for the preproduction site, but its an exact copy of the original, so it always redirects to www.theprinterdepo.com. Anybody have experience with this?
Thanks.
You need to also duplicate the database, and update your app/etc/local.xml with the duplicated database details so that your pre-production site is referencing it.
Then you need to specify the new BASE URL in the Magento configuration, or else it will redirect to the production site.
preprod.theprinterdepot.net
If the (preprod.theprinterdepot.net) domain is not publically accessible, then specify it in your local hosts file for example:
192.168.2.1 preprod.theprinterdepot.net
You can find an overview of the complete move details # Magento wiki
We have moved out magento site to another host. But it is redirecting to the old site
We did following changes before moving the site
1. DB backup
2. files are zipped and copied to another host.
after moving the site to another host
1. changed the /web/secure and /web/unsecure values in the DB.
2. In magento files /app/etc/local.xml changed the database name.
3. cleared the var/cache
4. cleared the var/tmp
5. cleared the var/session.
but still the magento site is redirected to old site.
Can any one help me with this.
Thanks
Several steps involved in cloning or moving a website.
NOTE: It's common practice to empty the var/cache, var/session directories before copying to new location. Clearing cache is mentioned below as it's necessary to clear the cached config after you've run through the list and properly set database access, BaseURL, etc.
Copy application files to new location and import database into MySQL. (best to do this with a tarball and database dump sql file, ftp has issues with things like getting .htaccess files to transfer, case to matter, etc.) Note: more sophisticated Magento admins use rsync, it's far easier.
(important!!) Make sure file/folder permissions and owner/group are correct so that var/ folder system is writable. Otherwise the Magento cache gets written in system /tmp instead of Magento var/ and only a server reboot or manual deletion will clear Magento cache out of /tmp . Also, not having var/ writable means that any drastic errors that write a file to var/report/ will fail to write any stack traces, compounding your installation heartburn.
Make sure app/etc/local.xml points to the proper database and make sure if you back up the original local.xml that it doesn't end in .xml -> needs to be something like local.xml.sv1
Change your database entries Unsecure BaseUrl for and Secure BaseURL to point to your new location (http://www.example.com and if ssl cert installed https://www.example.com respectively). Use phpmyadmin to look for the paths web/unsecure/base_url and web/secure/base_url in the core_config_data table. (Note: entries will exist for each scope set, minimum is Global)
Manually clear your cache by deleting all the mage--? subfolders in var/cache
If you were using the compiler on the previous site, disable compiler with SSH command line php shell/compiler.php disable from the Magento root.
Attempt to load your admin backend, you should be on the new server URL now.
Following these steps should clear all the hiccups that cause Magento to adamantly redirect back to the old server. And believe me, I've had them all happen.
I have installed drupal on my localmachine(ubuntu, Xampp), at localhost.
Path and Pathauto modules are active (a module to produce friendly URLs).
Migrating/Pushing my local install to the www.mysite.com
Exported SQL from phpMyadmin(localhost).
Made a new DB at live site (I think a different name from the localhost-DB does not create any problem).
Imported SQL into phpMyadmin, (mysite).
Changed the username-password-DBname in the sites/default/settings.php in drupal folder.
Now, uploaded the drupal folder and all its content into the /www of the "mysite.com".
Visited the URL www.mysite.com, site looks same as on my localhost, good.
But --
I made a tryPage on my
localhost/drupal, for which
pathauto(cleanURL) recommended the
URL "content/trypage" which i
explicitly changed to "trypage", so
that absolute link to the page is
"localhost/drupal/trypage" and not
"localhost/drupal/content/trypage".
Now When i click the trypage link on the mysite,
it open's it in-reference to my
localhost, my local-pages are
opened. That is, when I click
newpage on the mysite.com, the URL
requested is
"localhost/drupal/newpage" and not
"www.mysite.com/newpage".
Do you think it is coz of the SEO
friendly URL generation issue, the
Pathauto module.
Anyways how do i solve this
If I make my "localhost/drupal" to open from same URL (mysite.com), i dont know how
to do that exactly, i think by configuring
vhosts. But if i do that, then the URL
www.mysite.com where will it take
me, local or online.
Now If i add new modules, new content, new pages, and new books on my localhost site, and wish to update mysite.com, do i have to redo SQL export/import everytime, and use a software like rsync/sitecopy(), to upload the folders on the live site. How do i solve this.
This is an old question, but here are some thoughts.
Links generated by Drupal (e.g. menu links, links within the admin area, breadcrumbs, etc.) should always use the domain of the currently requested site. URLs within Drupal are handled by the "router", which stores all paths within the database in a relative format.
That said, unless you're specifying the site URL in settings.php (the $base_url variable) or are linking to pages using fully qualified URLs, this shouldn't be a problem. Linking to different nodes from other nodes can be handled with a variety of modules. Pathologic is a good choice, or Path Filter.
Moving Drupal sites from development to staging to production is still a common problem for which there is no definitive solution. This question was asked previously here.