How to transfer Processwire from local installation to online?

[ashrai]

Hey folks,

Thanks to your help: my first project is done - and running fine on an Apache (local) server.
I've already checked the requirements and set up a new database on the webserver.

Now, how do I transfer my project to a webspace? Reinstall Processwire there and then add templates or ... ? I'm a bit stuck, I have to admit ...

So what would be the easiest way to get my site online for testing?

thanks in advance

ashrai

[Philipp]

Two possible ways to do this:

1) Use the Site Profile Exporter

Just install it on the local installation, run it and then install Processwire with the new created setup on the new host. Don't forget to copy your templates.

2) Manual by exporting the database and import it again.

Copy your local files to the Webserver. Don't forget, that some folders need write permissions for Processwire to work(/site/assets /site/config.php, ...). You should have a phpmyadmin installed on your local machine. Use it, to export the database. Then import the database on your server(again, you could use phpmyAdmin). Check, if the database connection is possible with the login details saved in the /site/config.php. You might also have to delete the session and cache files in the /site/assets directory.

By reinstalling a fresh PW, you would have to create the fields and template and page stuff again. You can copy the templates but the content will be missing .

[SiNNuT]

In most cases there's not a lot to it:

1- Transfer all files from your local environment to the desired location on the 'webspace'. You would probably do this via ftp. I assume you know how to do this. Make sure to also transfer the .htaccess file, because sometimes this is hidden.

2- Make a database export of your local database (via PHPMyadmin or other tools). Do a database import of this stuff in your new database on the webserver.

3- Check the database credentials in the file site/config.php on the server (near the bottom of the files). If needed adjust to the online environment and databasename, login etc.

That's it. All things should work now. There are a couple of things to keep in mind though:

- if locally you developed the site in a subdirectory (e.g. localhost/test/) and you move the site to the webroot or subdomain, most probably links to files and images inside richtextarea's stop working. You would have to adjust the paths in your database export before importing it.

- sometimes you need to change directory permissions for certain dirs to write permissions.

[alan]

I do it as per SiNNuT/Philipp's "2.". The only things I would add are:

1. on a Mac I now use Navicat for all database import/export (as it's so quick, but it is commercial and costs)
2. these tips on dual config files

[choppingblock]

if locally you developed the site in a subdirectory (e.g. localhost/test/) and you move the site to the webroot or subdomain, most probably links to files and images inside richtextarea's stop working. You would have to adjust the paths in your database export before importing it

is there any elegant way to do this except doing an update/replace within mysql?

[Soma]

The best way is to avoid having PW in subfolder and on root on production.

Search replace the sql dump is maybe most simple. And there's also this module http://processwire.com/talk/topic/236-module-page-link-abstractor/

[choppingblock]

That's exactly what I was looking for. Thanks!

[dragan]

Is there a full list of directories / files that need write permissions anywhere? Or are the two mentioned the only ones?

Two possible ways to do this: (...)

Don't forget, that some folders need write permissions for Processwire to work(/site/assets /site/config.php, ...).

[diogo]

Those are the only ones. You will also need write permissions on the modules folder if you use Soma's modules manager.

[dragan]

Thanks! I'm really amazed how fast responses pour in here @ PW forums. Feels good to become part of such an awesome community. I guess I'll completely redo two sites with PW, that were originally built with another CMS (playing around with dummy data is not so appealing for me - a real-life scenario is always much better for learning the ropes, as far as I'm concerned.)

[BillyKoch]

How difficult is it to move Processwire  lets say I am doing like client.mydomain.com and then when done and the client is happy with it then move it to their root domain myclientdomain.com

[horst]

How difficult is it to move Processwire  lets say I am doing like client.mydomain.com and then when done and the client is happy with it then move it to their root domain myclientdomain.com

 Hi, I think this isn't difficult, but it seems to be one of the best solutions because: assuming the subdomain and main-domain are running on the same server, you have may the exact identical environment for development- and public-site.

[diogo]

You might have to change the root on your config file. But that's it.

[apeisa]

You might have to change the root on your config file. But that's it.

Nope. There isn't any setting like that. PW doesn't "know" where it is run or not. It can even run at both domains at the same time (granted they are on same server like horst mentioned).

[diogo]

I could swear I read somewhere cases where this was needed... but ya, there's nothing like that on the config file.

[NoDice]

How difficult is it to move Processwire  lets say I am doing like client.mydomain.com and then when done and the client is happy with it then move it to their root domain myclientdomain.com

Nope.

There isn't any setting like that. PW doesn't "know" where it is run or

not. It can even run at both domains at the same time (granted they are

on same server like horst mentioned).

Actually, I was just wondering this myself as I am just about to install and setup my dev environment.

My initial plan was to just make a “test” folder under the main domain on the actual server I will later use for the live site, and use that as my site root.

As I will be working from several different client computers, I figured that would be the easiest solution (since it will also continuously expose any problems that might exist in the server environment).

I intend to use relative links throughout, in order to not have anything break as I move to the domain root directory.

Anything in particular I should think/worry about if I make these choices as far as pw and the futre move to the root is concerned?

[teppo]

@NoDice: shouldn't be any specific problems with that - though it wouldn't hurt to do some kind of test-run for moving the site before actually publishing it. You know, just to make sure.

Regarding link issues, check this thread too, there are couple of methods to fix and/or avoid these mentioned. In short, either do the page save trick introduced by Soma, dump SQL and search+replace as mentioned by Ryan or install Page Link Abstractor to avoid the whole issue entirely (read the module description carefully, though, as it changes the way your links work a bit.)

[NoDice]

@NoDice: shouldn't be any specific problems with that - though it wouldn't hurt to do some kind of test-run for moving the site before actually publishing it. You know, just to make sure.

Regarding link issues, check this thread too, there are couple of methods to fix and/or avoid these mentioned. In short, either do the page save trick introduced by Soma, dump SQL and search+replace as mentioned by Ryan or install Page Link Abstractor to avoid the whole issue entirely (read the module description carefully, though, as it changes the way your links work a bit.)

OK, thanks for that reply and the link!

 

I installed PW now and did some tests before reading your reply. 

 

What I did was move the whole default folder where I put PW after installation one folder down. 

 

The only thing I had to do to make the site links work again was change the url in the .thaccess file RewriteBase line to reflect the move (this was a fix I had to apply in the first place to make the installation work as described by thomasandman here: http://processwire.com/talk/topic/1-what-is-the-admin-login-url/?p=28330).  

 

The links were automatically output the right way (root relative) after the move of all files (I E one level was removed from all links when output to HTML as read by the browser compared to when read in their original location). 

 

But what I take away from the discussion you linked is that I now may have some problems in my mySQL database where the old links my still be present? Or if no such db-data have been produced yet since I only have the standard installation test pages so far, I may get such problems after a similar move once I have completed my actual site? 

 

If so, the find-replace solution would be ok for me (but I had not planned to have to export and import the database since I will be on the same server the whole time).  

 

** Edit ** I exported and searched but there were no traces of link references (from before or after the move) in the exported mysql database file yet as far as I could find.

[diogo]

That problem happens only with links that are stored in the database. An example would be a link in a tinyMce text area, and those are the ones that the module solves.

[jan]

Hi, I think I'm just getting crazy, because things happen I don't understand

I try to transfer a processwire installation (v2.3.0) to another server. In site/config.php there are NO db credentials set by installer! Anyway the installation is working befor transfering it to a new server!! After transfering it's not working.

I'm just wondering where processwire v2.3.0 gets db credentials from? Can anyone tell me?? Is something changed here?!

PS: After changing ANYTHING (timezone) in site/config.php (of the first, working instance) and saving changes I get 500 Internal Server Error

Log: Error:     Exception: DB connect error 2005 - Unknown MySQL server host 'Config' (1) (in /var/www/spielplatz/conceptPlus/wire/core/ProcessWire.php line 96)

HELP!

[adrian]

Your config.php file should contain something like this:

/**
 * Installer: Database Configuration
 *
 */
$config->dbHost = 'localhost';
$config->dbName = 'dbname';
$config->dbUser = 'dbuser';
$config->dbPass = '123456';
$config->dbPort = '3306';

[jan]

Ok... I got it.... sorry. I'm using Netbeans on remote project.

After installation it did't get the changes made by server in my local environment! So, I could not see db credentials in config.php in netbeans, but they were set in the file on the server. Now after saving config.php localy, netbeans overwrites what is on the server: db credentials were removed.

Hope nobody will make the same mistake..

Now I lost $config->userAuthSalt. is there a way to restore it??

[jan]

Ok, continuing the monologue: I helped myself, simply generating ANY new userAuthSalt. After that I used Ryans explanation to reset admin and user passwords:

http://processwire.com/talk/topic/1736-forgot-backend-password-how-do-you-reset/?p=16163

Logins and everything else works fine now.

[tehandyb]

Wanted to add my two cents. I just did the reverse, I transferred a site from my web server host to my local XAMPP on Mac OSX 10.9.3. I was having php write issues for some reason. There was an error saying processwire couldnt write to the assets/sessions folder. And I ended up using chmod -R 777 on my site directory, which I know would not be a good solution on your production site.

What did I need to do to be more secure, just give php the permission somehow?

[CliffG]

I'm just reiterating what's already been said in easy-to-follow steps using the database export/import method.

1. Export the SQL database from your local development site.

2. Set up a new database on the production server and note the database name, user name and password (they will probably be different from the local names).

3. Create a ProcessWire directory (or go directly to root) on the web server and FTP all files from your local dev (including .htaccess). Note that site/assets and site/assets/config.php need to be writeable, so check permissions if there's a problem.

4. Go into the site/config.php file online and change the Installer Config data from the ones in your local database to the ones you set up in the online database (e.g., dbName, dbUser, dbPass) if different.

5. BEFORE you import the SQL dump from your development database, search through it and fix all hrefs and anything else that still refers to the local installation. Then import it into the web installation.

6. Online, you may have to go into your CSS files and templates to change hrefs (e.g., for background images and the homepage).

That should do it.