Disadvantage to install Drupal on “xampp” on the local system and then upload instead of installing on the server?

By Dirki on 3 Jul 2008 at 14:38 UTC

Is there any disadvantage to install Drupal first on my local Windows XP system on XAMPP and then to upload the entire website via ftp and its database instead of installing it on the server directly as usual?

Will there be a difference between an installation done on the local system (and then uploaded) and one done like usual on the server directly?

And above all, might an installation on the local system on XAMPP cause malfunctions after uploading?

Might there be caused problems with case sensitivity of Drupal’s table names? Are the table names of Drupal case sensitive or lower or upper case? Might there occur errors when installing modules on “xampp” on my Drupal running on the local system and then upload them?

Nice greetings, Dirk.

Comments

This is what i always do. I

lainwired commented 3 July 2008 at 16:03

This is what i always do. I setup the site on work on it localy then upload the files by ftp and export the sql database and re import it on my webhost. Just be sure to modify your settings.php to point to the new sql server and table.

I am not aware of any

lionheart8 commented 3 July 2008 at 20:58

I am not aware of any disadvantages.

One however has to make some preparations before uploading and that is basically editing the file sites/default/settings.php .
You have to change the database settings as illustrated here: http://drupal.org/node/276687 ... It happened to work for that person ;).

Look for the following lines below and edit the highlighted one.

* Database URL format:
* $db_url = 'mysql://username:password@localhost/databasename';
* $db_url = 'mysqli://username:password@localhost/databasename';
* $db_url = 'pgsql://username:password@localhost/databasename';
*/
$db_url = 'mysql://yourXamppDBUsername:YourXamppDBPassword@localhost/YourXamppDBname;
$db_prefix = '';

Replace those Xampp values with those on YOUR ONLINE SERVER, ie the Online DB name, username, PWD and of course host IF it is NOT "localhost".

I am not aware of any other files you need to change.
I assume you have imported the DB & FTPed the files as mentioned by lainwired.

Thank you very much,

Dirki commented 3 July 2008 at 21:54

Thank you very much, lionheart8,

Yes, I have done all exactly the way you describe and all has gone easily and works fine. Very understandable explanation.

Thanks again for your help, nice greetings, Dirk.

----------------------------------------------------
http://www.galerie-der-fotos.de

Gerne geschehen :)

lionheart8 commented 3 July 2008 at 22:05

Gerne geschehen :)

I used this procedure

Morn commented 3 July 2008 at 16:13

I used this procedure without any Problems (xampp under XP to new Webhoster under Unix).
-I exported the DB with PhpAdmin, removed the CREATE DATASE .... (my webhoster provides predefined DBs)
entry from the exported DB and inserted USE new_db_name in this file.
- imported the DB data with phpadmin to the new DB
- prepared settings.php for the new environment: DB data and $update_free_access = TRUE;
- uploaded, with filezilla, directly from my xampp the drupal sources and files directory to the new host.
- executed update.php (http://www.newwebhoster.../update.php
- logged in, and since I use Garland, I changed a little the colors in order to recreate the .ccs file in order to obtain the original layout.

That was, everything works, users are there with they original passwords, etc.

Many thanks for your very

Dirki commented 3 July 2008 at 19:20

Many thanks for your very helpful answers, links, descriptions,

So that all is very easily to handle and an advantage is particularly not to have a downtime when updating as it seems.

And when I use the same settings, passwords, usernames, database names in "settings.php" on XAMPP like I have on the server, there is nothing to modify after uploading.

Without having any user actions or having a few only, like writing comments, registrations and so on it would be possible to update (e.g. 6.1 to 6.2) Drupal on XAMPP on the local system and after that always upload the new / newer files and folders only. Or you can add modules always to Drupal on XAMPP and (when it works fine) then upload the new / newer files / folders only.

When having more than a few user actions, many, I guess, then the only way is to download (e.g. to back up, to keep the local running system up to date) and not to upload anymore to not to delete new user entries. So, to install new modules (their updates) or Drupal updates on the server and then download the new / newer folders / files and the database.

Thank you very much for your help, again, nice greetings, Dirk.

----------------------------------------------------
http://www.galerie-der-fotos.de

it's not necessary to have

valthebald

Sofia

commented 3 July 2008 at 19:39

it's not necessary to have the same user and passwords on both local and provider machines. You can create sites/default/settings.php and sites/yourdomain.com/settings.php to have different db credentials.

http://www.valthebald.net

Thank you, valthebald, That

Dirki commented 3 July 2008 at 20:46

Thank you, valthebald,

That is a good idea.

So, if I understand right, just create a new folder, e.g. sites/gallery and put in another "settings.php" with the credentials of the server database. But how do I make the "sites/gallery/settings.php" accessed by Drupal?

Nice greetings, Dirk.

----------------------------------------------------
http://www.galerie-der-fotos.de

drupal will do it for you

valthebald

Sofia

commented 4 July 2008 at 18:35

drupal will do it for you automatically. In your case, you should create folder sites/galerie-der-fotos.de and place production settings.php there. Exact algorythm for finding appropriate settings.php is described in INSTALL.txt file of drupal distribution (http://api.drupal.org/api/file/INSTALL.txt)

http://www.valthebald.net

Okay, thanks valthebald, So

Dirki commented 4 July 2008 at 23:50

Okay, thanks valthebald,

So when the settings.php is placed in the chosen folder - sites/galerie-der-fotos.de - Drupal will find it automatically and access. So if using two settings.php I just would have to replace the local XAMPP settings.php with the production settings.php after uploading and vice versa after downloading.

And thank you for the link, nice greetings, Dirk.

----------------------------------------------------
http://www.galerie-der-fotos.de

Maybe I was not clear

valthebald

Sofia

commented 5 July 2008 at 09:49

Maybe I was not clear enough, but things are even more simple than they seem to be :)
No need to replace anything after up/download - just place production settings.php in sites/galerie-der-fotos.de and development settings.php in sites/default - that's it!

http://www.valthebald.net

Oh, sorry valthebald, For my

Dirki commented 5 July 2008 at 10:06

Oh, sorry valthebald,

For my misunderstanding.

Yes, indeed, that is realy simple.

Thanks again for your help, nice greetings, Dirk.
----------------------------------------------------
http://www.galerie-der-fotos.de

In my opinion there usually

-Anti- commented 5 July 2008 at 10:45

In my opinion there usually are differences between the intended live server and the local one. Most of the time they don't matter, but is it worth the headache if after weeks of local development you find out somethings don't work just before you intended to go live? Also, after going live, I find keeping my local and live versions syncronised is an extra pain.

So now I am trying developing on a test site on the intended live server, and implementing changes on the live site if there are no problems (although it's not 'live', but is 'hidden' in a subdirectory - I'll just use a 301 redirect to make it live. At the moment the domain just points to a splash page).

So far the workflow is good enough that I don't miss any advantage of WAMP.
The tools I use to get a fluent workflow are:

- Web Builder editor (has ftp capability to edit remote files, as well as being a great editor)
- Firebug add-on for firefox
- Demonstration module to back up the DB with one click before I make large changes or test modules
- devel module (although I hardly actually use it, and it's corrupted the DB a couple of times anyway)
- I keep folders on my hard drive of the drupal core, themes & modules to use 'windows search' to find $trings.

It's working well, and I'm finding it less stressful to know for a fact that my implementation works on the server.

Thank you very much for your

Dirki commented 5 July 2008 at 13:18

Thank you very much for your answer, anti.

In my opinion there usually are differences between the intended live server and the local one.

Which ones could that be? And how might they effect?

Most of the time they don't matter, but is it worth the headache if after weeks of local development you find out somethings don't work just before you intended to go live?

So it might be the same as if you would move your website to another server / another hoster with another server configuration which might not let your website work anymore?

Always when having done changes / modifications on my local XAMPP system I would upload the modificated files right after that, so problems could be noticed immediately (of course, if they appear someone later may be initialized by an user action…).

Also, after going live, I find keeping my local and live versions syncronised is an extra pain.

But wouldn’t you have to just upload new / modificated files every time after editing and nothing more (besides the database when its effected by editing)? Wouldn’t it be the same doing it vice versa (to download / keeping the local Drupal synchronized), apart from the download time being much longer; upload multi threading seems not to work the way as it does when ftp-downloading)?

So far the workflow is good enough that I don't miss any advantage of WAMP.
The tools I use to get a fluent workflow are:
Web Builder editor (has ftp capability to edit remote files, as well as being a great editor)

I use “PSPad”, notepad++ is okay, too

Demonstration module to back up the DB with one click before I make large changes or test modules

Never heard of it. What is it? “HeidiSQL seems to work very well to back up / import / export. With the “MySQL GUI Tools” you can schedule back ups.

devel module (although I hardly actually use it, and it's corrupted the DB a couple of times anyway)

This sounds not very reliable. What for is it?

I keep folders on my hard drive of the drupal core, themes & modules to use 'windows search' to find $trings

Yes, the same way I do it and would do it. Doing a search (& replace) in files, its contents on the server is unacceptable because of the long time needed (if it would work anyway).

It's working well, and I'm finding it less stressful to know for a fact that my implementation works on the server.

Yes, this sounds really well, indeed; I would find it always good to know to have your own website on your local system / XAMPP perfectly running and anyone else (the hoster, scripts running on the server etc.) could not have modified anything of your (local) website (other than downloading the website installed on the server). If you someday would move your website to another server / another hoster you always could set up your own website without any problems (at least apart from new server configurations).

Thank for your good thoughts, nice greetings, Dirk.

----------------------------------------------------
http://www.galerie-der-fotos.de

>> In my opinion there

-Anti- commented 5 July 2008 at 15:25

>> In my opinion there usually are differences between the intended live server and the local one.
> Which ones could that be? And how might they effect?

- Email servers often differ. Hosts have various different settings and security. Eg. I found once that the local version could send through my remote smtp server (because the server just assumed it was an email client), but when uploaded the website, the server was set to not allow localhost scripts to access smtp. I had to find a phpmailer alternative.

- SQL can be set-up in various different ways and restrictions. Eg. I've used utf-8 database for local development, and then discovered that the intended host used latin2 'character_set_server' and 'collation_server system' variables, and the cms scripts didn't over-ride them with SETNAME. I ended up with mixed encodings in the DB.

- php version, especially when there is a major upgrade. Hosts tend to upgrade to the next stable version weeks or months before the WAMP packages are updated.

> So it might be the same as if you would move your website to another server / another hoster
> with another server configuration which might not let your website work anymore?

Yes.

> wouldn’t you have to just upload new / modificated files every time after editing and nothing more

I regularly found myself having to synchronise both ways for various reasons, without a reliable way to do it.
So I'd prefer not worry about synching at all if possible. Working remotely used to be a hassle three years ago, but our connections are faster now, no-one pays per minute anymore, and I think there are a lot of good tools now to make remote editing easier and safer.

> Never heard of it

http://drupal.org/project/demo
http://drupal.org/project/devel

Anyway, good luck with finding a fast, reliable workflow.

...SQL can be set-up in

Dirki commented 5 July 2008 at 22:18

...
SQL can be set-up in various different ways and restrictions. Eg. I've used utf-8 database for local development, and then discovered that the intended host used latin2 'character_set_server' and 'collation_server system' variables, and the cms scripts didn't over-ride them with SETNAME. I ended up with mixed encodings in the DB.

Yes, these are very plausible arguments.

And yes, indeed, I had / have a (MySQL) problem with Menalto Gallery installed on XAMPP, regarding the letter case: lower case default on XAMPP / XP, but the database on the server (unix) needs case sensitivity which generated a “database error” after uploading. Took a long time to reveal this.

and I think there are a lot of good tools now to make remote editing easier and safer.

Yes, that’s true...

Thanks a lot for letting me know your thoughts about this and for the links, nice greetings, Dirk.

----------------------------------------------------
http://www.galerie-der-fotos.de

Temporary directory & co on admin/settings

lionheart8 commented 10 July 2008 at 18:17

Coming to think of it, and as the other honorable members say, some few differences may turn up later, which may not be obvious at the beginning.

I have just installed Drupal 6.3 on Drupal.
As I was going through the admin/settings page and came to admin/settings/file-system ,

I noted the Temporary Directory had been pre-set to C:\Program Files\xampp\tmp (A file system path where uploaded files will be stored during previews.)

When uploading sites in the past, I had not thought about this at all, but I am quite sure if you have that on an online webserver as the temporary directory, I think it would matter.

So I think at least one needs to check out all settings of the different modules which involve settings "paths" unless some function I am not aware of in Drupal corrects them. Currently on my settings page, I only had file-settings requiring such a path. A few others like the image module have "relative" paths which pose no problem.

I do not think however there's much to change as the sites uploaded in the way I & some few others do
would not fail to show a good number of errors or have lots of stuff not functioning.
Thanks for for pointing this out.

> I do not think however

-Anti- commented 10 July 2008 at 21:58

> I do not think however there's much to change

True, but I do hate that nagging feeling of 'have I left the oven on?' when I go to the pub.

And I get the same feeling after uploading my site from local to live: 'Have I thought about and done everything that I need to do to change location successfully?' Working remotely and just syncing folders and databases that are sitting right next to each other on the same server just lessens that feeling for me a bit.

Having said that, a professional developer with a brain the size of a beachball would probably not be daunted by syncing a local and remote site. I've only got a tennis ball sized one.

Hallo lionheart8, Yes, when

Dirki commented 10 July 2008 at 22:31

Hallo lionheart8,

Yes, when you install / maintain the local system and then upload always, it seems as if you should really have to check some or many things like paths after updating, installing modules and so on or without checking (it could be very complex to each time check all) to reckon you have missed new problems after updating / maintaining which you will not see sometime later.

But the wrong paths seem to be the easier to find problems. Much more difficult to find could be problems e.g. caused by different database settings. For example:

These are the settings of my database on my local XP system:
http://www.temp.galerie-der-fotos.de/screenshots/show-variables-myadmin-...

These are the settings of my database on the server:
http://www.temp.galerie-der-fotos.de/screenshots/show-variables-myadmin-...

There are a lot of different settings, but how do you know (when you do not know anything about databases / MySQL like I do) which difference might not let work Drupal anymore on the server after uploading? The problem I recently had with Menalto Gallery would not have been occurred if I had installed it on the server. Hard to find, it took some weeks for me, found by random, easily to solve actually.

Nice greetings, Dirk.

----------------------------------------------------
http://www.galerie-der-fotos.de

A look at the Documentation pages

lionheart8 commented 11 July 2008 at 10:32

Hi again
With so many Drupal sites running, though the issues raised have already been encountered by people and so that is why there is lots of material in the Documentation section such as "Installation, migration and backups" http://drupal.org/node/206647 under Beyond Basics - which are worth checking out.

This article lists some related topics, but there are more in the menu, such as "Migrating Database Changes From Development to Live Websites" at http://drupal.org/node/199771 and http://drupal.org/node/53479 which I think are directly related to what we are talking about.
I think there's lots of stuff there worth knowing that address some of the questions we have.

Cheers

Thank you very much for the

Dirki commented 11 July 2008 at 14:12

Thank you very much for the links, lionheart8,

Yes, indeed, there is a lot of information, (exactly) about what we want to know. Seems to be current information, also.

It seems as if I have made the mistake just to check the German Drupal-Website some time ago (I remember to have found a bit may be regarding older versions) and to have missed checking this English Website, obviously.

It’s becoming more and more complicated (to me). I have lost the overview. Don’t know which advantages (coming with disadvantages) I should prefer at the moment.

Doing it like Anti does is a very good way, I would go when installing / maintaining etc. on XAMPP and then uploading seems to become to error-prone, now.

Nice greetings, Dirk.

----------------------------------------------------
http://www.galerie-der-fotos.de

One more thought or 2

lionheart8 commented 11 July 2008 at 15:50

Hi again :)

I personally prefer trying out stuff locally and if I am satisfied - I make a fresh online installation, based on what i have made on the PC. Components like a custom(ized) theme just need uploading and modules: just upload all those I have around and take some few hours, one evening to enable & configure them. That is what I have done up to now and if there's any static content, etc, I insert it.

Separate from the local experimental version is copy of this online installation I download after & set up under Xampp. This retains the online structure 100%[including the paths, etc we talked about] but generally functions.
I personally regularly save back ups of the database and the whole root folder (esp. if new files have been added - which normally happens) via Cpanel of my hosting account, which is quite easy so that in case something goes wrong, I can simply upload the back ups.
Before making any changes that may have far-reaching implications on a site, it's always safe to download a fresh back-up of the site + the DB before implementation.

Regarding experimenting with stuff, it depends on what site is in question. I for example have a community site online. I have a copy of it on my PC which - runs []. I downloaded the copy from the online installation. If I want to try out something like a new module or theme, I do it on the PC version and if i am satisfied, simply perform the same action directly on the online version. In the case of the theme, that is straight forward, one can upload & simply overwrite the online files.

With modules, which I think normally involves DB changes, I install them directly online as said if I am satisfied with the PC version performance.
With this, the problems we discussed do not come up - i.e. of discrepancies between an offline + online version.

I also in some cases have a copy of the site online in a different folder or server also for testing purposes. With these measures, I think it's absolutely safe to run one's Drupal sites like many are successfully doing thousands of many big & small, private & corporate sites aro)und the world.

Yes, there's much more information and documentation here at drupal.org than at www.drupal.de. (if that's the one you meant). I also ever put a question or 2 and I think got no responses in months - which only shows the community here is much more active and response, partly because it is much bigger.

Herzliche Grüße :)

Hallo again lionheart8. I

Dirki commented 11 July 2008 at 21:15

Hallo again lionheart8.

I personally prefer trying out stuff locally and if I am satisfied - I make a fresh online installation, based on what i have made on the PC.

Ah, okay, I do it the same way with step one till nowadays, but then I just upload what is new / modified (if need be, if the database is modified, also, then with the complete database, “drop tables”) and do not install a new version on the server. To upload I often use a back up program to synchronize all the files, so after all is done on XAMPP just one click and the back up program uploads the new / modified files / folders.

Separate from the local experimental version is copy of this online installation I download after & set up under Xampp. This retains the online structure 100%[including the paths, etc we talked about] but generally functions.

I personally regularly save back ups of the database and the whole root folder (esp. if new files have been added - which normally happens) via Cpanel of my hosting account, which is quite easy so that in case something goes wrong, I can simply upload the back ups.

Before making any changes that may have far-reaching implications on a site, it's always safe to download a fresh back-up of the site + the DB before implementation.

Yes, indeed, that is a way I would like to do, also (meanwhile), the problem is that downloading takes such a lot of time with the ftp programs I tested (fresh install of Gallery download: two hours, identical upload 15 minutes) and the scripts / cpanel of my hoster seems a bit unreliable. So I cannot just download a website (though to download a fresh installed Drupal is much faster to download than e.g. Gallery) to have a back up, it always takes a lot of time. Do you use for back ups your hoster`s cpanel only, or is there another ftp program you use which could be faster by downloading?

Regarding experimenting with stuff, it depends on what site is in question. I for example have a community site online. I have a copy of it on my PC which - runs []. I downloaded the copy from the online installation. If I want to try out something like a new module or theme, I do it on the PC version and if i am satisfied, simply perform the same action directly on the online version. In the case of the theme, that is straight forward, one can upload & simply overwrite the online files.

Yes, this avoids getting problems with wrong paths / settings / configurations than it might occur after just uploading the installed version on XAMPP.

Indeed, the combinations of methods you are apply to seem to be the best way to me, also.

If I would have done some installations of new modules or some changes on a live site which I have done on my test site on a server I would have caused some damage / inaccessibility. So working without a test site there is no chance I think.

Yes, there's much more information and documentation here at drupal.org than at www.drupal.de. (if that's the one you meant). I also ever put a question or 2 and I think got no responses in months - which only shows the community here is much more active and response, partly because it is much bigger.

Ah, sorry, no I meant - http://www.drupalcenter.de/ - this community - www.drupal.de - is really too small, I have never posted there.

Auf jeden Fall freue ich mich über Deine absolut hilfreichen Gedanken zu dem Thema, ist genau das, was mich interessiert, was ich wissen muß, hoffe, das bald alles im Griff zu haben.

Nette Grüße, Dirk

----------------------------------------------------
http://www.galerie-der-fotos.de