I have no idea about PHP.
I have PHP site hosted on Server A. Now I want to transfer the hosting to another company having Windows hosting on Server B.
Can I just transfer all the contents of WWWROOT folder of Server A to Server B? Will the site work that way? Or I do have to get the source, compile and publish it?
Thanks!
the process is this:
copy the content from server A to B (also db dump)
make sure your site is working on server B correct
set a redirect on server A to server B (usually in .htaccess file)
edit DNS entries to point to server B
wait that DNS changes have been picked up (note: as suggested by Emil you can reduce this time by lowering TTL setting on the DNS entries)
remove content from server A (end hosting)
PHP is not (usually) compiled, you should be able to simply copy the files and directories over and they should at least run. You may have to set up a database and connections to it, change some configuration in the scripts and you may or may not run into incompatibilities between different PHP versions and/or UNIX/Windows problems though, depending on how portable the scripts were written.
you don't need to compile anything. it's enough to copy project directory from one server to another. one thing can cause your project not working on ohter hosting, if there will not be installed some php-extensions that are required for you project.
and of course, if your project uses some databases, they must be created on new server
PHP scripts are source code and are compiled when needed. Simply moving the files is enough. Problems may occur if it is a package that has been isntalled on that server and may have some properties in various files about absolute paths to other files.
Also, issues will occur if the files are talking to a local SQL server or the such.
Many hosting companies offer a free (or sometimes payed) service to copy your website accross including any databases. Ask your hosting company for help.
No need to compile, however you have to make sure that the new server meets all the requirements of your application (e.g. server modules) and that paths are correctly configured. Also under some circumstances the PHP version can matter as well. Only one way to find out!
Related
First of all I apologize for the dumb question. I'm new with all this. I already searched an answer on Google, but I couldn't find anything comprehensible for me.
So, I managed to create my html, CSS, JavaScript files. I managed to install XAMPP, create SQL databases, access and update them with PHP from my html page.
Now I have full access to my files, since they're on my computer. But how does it work when I move them to a server?
First, what files should I move exactly? All the XAMPP folder? Just html, css, js and PHP?
Second, once uploaded the files, how can I access them, for updating, or for viewing the database? Can I still use XAMPP or after uploading the files to a server XAMPP becomes useless?
Thank you a lot.
First of all if you want to upload file to a online server. there are many tools which can allow you upload them. In my Case i use filezila.
This is how it is presented:
you will move everything located under xamp/htdocs/YOUR_PROJECT and move it on the server ( in my case under public_html folder). Html, php, css, ...
You can delete, rename or modify them within filezila at server file section as described in the picture. Right click on a file > all actions will be seen
for viewing the database check in Admin panet of your host website in my case hostinger and on Databases choose for example phpmyadmin and you will be redirected to you Database panel to view all your databases
I think this helped.
Your hosting provider presumably already has the equivalent of your XAMPP stack installed. (Unless you're starting with an unmanaged VPserver, in which case you'll have to install and configure an Apache-MySQL-PHP stack before your website will function.) Assuming a standard hosting solution, you will only need to upload the files specific to your project.
Basic steps to deploy from local to remote server:
Using an FTP client of your choice, upload your PHP, HTML, CSS, JS, image etc. files to your server's public_html folder. (Full path will be something like /home/example.com/public_html/ on a Linux server, depending on your hosting provider.)
Use a database manager (such as PHPMyAdmin) to upload the SQL file into a database you've created.
Update any absolute paths you may have used in your PHP files, reflecting the live/production server's filesystem structure.
Update your database-connecting PHP file(s) with the appropriate credentials. (They're probably different from your local server's user/password.)
You will want to ensure that your remote server's configuration supports all the functionality your code depends on (e.g. PHP modules and other configuration).
If you put a bit of thought into your code, you won't have to maintain separate local/remote files, and won't have to bother with steps 3 & 4. You can e.g. define your configuration based on a local IP address check (we're testing for both IPv4/6), as follows:
if (in_array($_SERVER['REMOTE_ADDR'], ['127.0.0.1', '::1'])) {
// local config here
} else {
// remote config here
}
Then, does your local server become useless? If you don't ever intend to develop code again -- yes. Otherwise, you will probably want to develop and test your code on your local machine, and only deploy it to your live/production server when you're satisfied it's stable enough for public release. You don't want to do your R&D on the live server!
Bear with me here ... I can't show exact examples or provide a link to the web server for security reasons. If anything more is needed I will gladly provide it.
What I HAVE:
I have a server that hosts an internal networked intranet for my company.
Coded with PHP, MySQL, HTML, etc
Ubuntu 14.04LTS
Normal Apache Web Server Configuration
Login access
Couple hundred PHP files for different pages/features needed for the company
Maintenance
FTP into the directories (shown below)
Manually edit PHP files with Notepad++
Test in Beta Directory -> move to -> Secure (overwriting current file there)
I know this procedure for maintaining is horrible so I'm trying to come up with a better solution
What I NEED:
Features
IDE Connectivity (Aptana,Eclipse,etc)
Commit/Push/Pull Capable with Server from IDE
Version Control
Keep backups for Rollbacks
Test & Main Server
Like how I have a Beta and Secure Directory for testing and releasing to everyone
What needs to be done on the Ubuntu Server in order to accept push/pull requests, store multiple versions, and store commit messages?
Do I need to install anything on the Ubuntu server in order to communicate with the remote computer I'm trying to access from?
I have been running a PHP site for years on my own servers. I recently purchased a dedicated server package and am trying to move my site to the dedicated server. I recently upgraded to PHP 5, and my current server is running PHP 5.6.16. I moved the files and the database, and put it in a live test domain, but the site is not functioning properly on the new dedicated server. Several key scripts are non-functional. I made sure that the dedicated server is running a version of 5.6. I have configured it to the same settings I have on the old server. I can see that the site is talking to the MySQL database. I turned on error reporting and I see no significant errors suggesting why these important scripts are now non-functional. I made sure the include path is there, and if it wasn't nothing would work. What am I overlooking? What could be different between one server and the other that might impact PHP functionality? I'm basically at my wits end here, so if these seems stupid please forgive me, but I don't know where to look next.
Start with the basics.
Does your web server respond to static page requests?
Is your web server configured to use PHP?
Can your web server execute and/or connect to PHP?
If you have a simple script with <?php phpinfo(); in it, does it work?
Are all the expected modules there in your phpinfo() output?
Do you have rewrite rules that need to be reconfigured? (Check your web server error log. Check your response status codes.)
Assuming PHP is all good, move into your application.
Are you absolutely sure error logging is on? (Again, check phpinfo() output. Try to force an error, maybe a syntax error or something and see if you see the error.)
How do you know your application is connecting to MySQL?
Start with a basic script that just echos some things.
Comment out large swaths of code and see if you can narrow down the problem that way, re-enabling chunks as you go. (You want to bi-sect the problem, cutting in half and in half and in half until you figure out exactly what the issue is.)
Other system-level things to check...
File system permissions? (See also https://serverfault.com/questions/48587/is-there-a-linux-log-for-when-a-user-is-denied-access-to-files-due-to-permission, for Linux.)
Firewalls? (Are you sure you can actually access MySQL over the network?)
Disk? (Are you out of space? Are your partitions set up correct? Is /tmp full?)
Once you figure out the problem, some advice:
Do this sort of thing regularly. Write a provisioning script to build yourself a new machine from one command, and do it regularly. These days with cloud providers (physical hardware or not) there's no reason you can't blow away your application servers on a regular basis, and re-provision them. Consider making this your system upgrade strategy. (Why reboot to get a new kernel when you can just have a whole new server with the new kernel and other patches, that you can cut over to?)
Ensure your development environment closely matches your production environment. (Consider Vagrant for this.)
You're using version control, right? If not, start using version control so that you can hack on your code for things like this and easily roll back when done.
How create beta (testing) website use same webroot and cake folder ?
That beta (testing) website probably is at http://beta.example.com or http://example.com/beta
A method I have been using for a couple of years is to set up staging server instances. These could be either separate physical servers, or on the same server using hostname checks. However, it is good practice to have separate web roots and separate databases under each instance. You'll be asking for trouble if different aspects of your site are shared between staging instances!
My setup is the following:
Development (a computer with the source code on, set up to serve to http://websitename.dev (a local domain).
Preview (a separate server, used to provide a preview of a website or a change to a website, before doing the extra work to putting it live). http://websitename.preview.mycompanyname.com
Next (this is on the same server as the live website, under a different web root, and connected to a different database. The reason for this server is because SO MANY TIMES has a site worked on the development machine, but when it is put live, something on the live server makes the site DIE. http://websitename.next.mycompanyname.com
Live (the usual live server setup) http://websitename.com
This is all achieved by assigning DNS records correctly (to point to the correct servers), and using the config script of my web server application, listening to the hostnames and serving the correct web root.
A testing or "staging" server should be set up completely independently of the production server. You should not reuse any component of the live system, which even includes the database. Just set up a copy of the production system with a separate database, separate files, if possible a separate (but identical) server.
The point of a test system is to test code that is possibly buggy and may delete all your live data, shoot your dog and take your lunch hostage. Also, your test system may not be compatible with the production system, depending on what you're going to change down the road.
As such, create a new virtual host in your Apache config (or whatever you're using) and set it up exactly like the production system. Done.
When i've worked on Drupal sites before, if there is internal access to the server, or if remote desktop access is available, i've always developed it on the machine it would be ran from when live, and just not made it public on the server.
However, what is the best thing to do if you don't have access to the server yet, for example if the client hasn't got anything in place?
I need to be able to build and test the solution on my local machine, or on my VPS which I have RDP access to, and be able to move it over with as much ease as possible to the clients server when ready.
Any tips or best practices? As far as i'm aware Drupal doesn't have any specific migration tools? I could be wrong though
I don't work with Drupal, but for Prestashop, Wordpress, Zencart, etc. I always use the same workflow:
I setup a vhost in my virtual sever, usually using a subdomain of my own domain (like customer.mydomain.com). Install the software with its DB etc. on the server. Setup FTP access.
I get a local copy of the files, which I maintain in a local git repository, pushing to github for backup purposes mainly.
I work with ZendStudio and configure a remote server and set it up to upload the files when I save them, so I can check them pretty much as if I were working locally. But the main advantage of this approach is that I can share the project with the customer as it progresses.
When I have to move to final server, at least with Wordpress, I have to search/replace the domain name, which wordpress saves on DB. But I do it locally. I download the entire DB as an SQL file through phpmyadmin, open it, searc-replace and upload it again via phpmyadmin to the permanent server.
With ZenCart and others the problem is the config file, which stores some paths. For long projects or long term customers I modify the config file to use some config details or anothers depending on the server name.
adding to the above comment...
Check the "backup and migrate" module and the "backup files" module. "Backup and migrate" is useful in any setup...
with this I was able to do a barebones drupal install and then migrate/replace the database with the one backed up from my local system... if the databases are named differently you will still need to edit the settings.php
"backup files" is useful for themes and content assets like images etc. but is essentially just a wrapper around gzip
I typically develop on my local machine and then upload to server once complete.
All you need to do is change the folder name in /sites/ and change the settings.php file to reflect the server settings/domain.
Something you should be aware of:
If you are uploading files on your local installation, the file paths will be wrong on the server and you will need to execute a one off mysql replace query.
Make sure you use relative paths in any hard coded links.