Serendipity Forums

[DrNI]

Hi there,

I have an old version of S9Y running on one server. I want to move the blog including all posts and settings to a new server on which I want to run the latest S9Y. What is the best procedure to do this, given I have full access (root permissions) on both machines?

Thanks for your assistance

DrNI

[garvinhicking]

Hi!

First move the blog (with old version) to the new server, then get everything up and running, and then perform the upgrade.

You could do it in one go, but that method has a higher chance of problems then the solution above.

To move an installation, check the s9y FAQ. Basic idea is: ZIP all files, transfer them to new server, makea SQL dump, edit the dump to replace all old server paths to the new path, transfer it to new server, edit serendipity_config_local.inc.php and change your new database/password credentials.

REgards,
Garvin

[Stosh]

Garvin,

Hi.

Re: Database restore

When you say database paths in the sql dump, bo you mean the CREATE DATABASE and USE directives at the top of the dump?

i.e.,

Code: Select all

--
-- Database: `someName_002`
--
CREATE DATABASE `someName_002` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
USE `someName_002`;


If I've already created a new database at the control panel, then, can I comment out the CREATE DATABASE directive?

In this case, setting the USE directive to the name of the database I've set up at the new hosting provider should do the trick for pulling in the sql data and creating the tables, yes?

(not necessarily in that order)



Re: New credentials and other info in serendipity_config_local.inc.php

Here's where I have an actual uri to the database server. This seem fairly straight forward. Just edit the file, changing the name, password, server, etc., and replace it in the new/copied installation directory.

Is this correct?


Thanks for your help.

-s

P.S. I have 1.5.5 at this time.

[Stosh]

. . .
Update: (see above message):


I commented out the CREATE DATABASE directive and changed the USE directive to the name of my test database on the new hosting provider's service. I was able to import the entire database, and it looks great! I have not yet tried to ftp up the blog files, but will just to see how it goes (the whole thing is in the wrong TLD to boot right now, just so I can be as clear as possible on how it will all work when it's time to do the real cut-over).

I know I have to change the base DISK directory in the config table too.

I have already produced a proper serendipity_config_local.inc.php for that test.

-s

[garvinhicking]

Hi!

Yes, exactly so. Seems you make good progress!

Regards,
Garvin

[Stosh]

Garvin,

Stuck!



Keep in mind I'm trying to install this on a new server, and right now because it's just a test, under a different domain name.

The first complaint was about "php_value" in the .htaccess file (never heard of it).

I just commented them out. i.e.,

# php_value session.use_trans_sid 0
# php_value register_globals off



Now I get the following error upon running:

Warning: Smarty error: unable to read resource: "404.tpl" in /home/content/17/8990017/html/Blog/bundled-libs/Smarty/libs/Smarty.class.php on line 1093

Well, I did a recursive dir and could not locate any file in the directory tree called "404.tpl"

Line 1093 is just an error trigger. Because of this, I'm thinking the path to 404.tpl should have been passed to it. Here's the func:

Code: Select all

    /**
     * trigger Smarty error
     *
     * @param string $error_msg
     * @param integer $error_type
     */
    function trigger_error($error_msg, $error_type = E_USER_WARNING)
    {
        trigger_error("Smarty error: $error_msg", $error_type);
    }


Any ideas? Why this message? Why it balks at php_value?

Thanks for your time, in any event.

-djr

[garvinhicking]

Hi!

When you re-upload your SQL dump, check the serendipity_config database table and search for all path references; you need to fix those to the new directory structure on the new server. I think this is also mentioned in the FAQ on s9y.org on how to move an installation, you might want to read that.

HTH,
Garvin

[Stosh]

Garvin,

Thanks. I got one blog moved and it seems to work perfectly.


Now I'm doing another one. . .
Oops. Pay no attention to that man behind the curtain.
Had a question caused by an upload that didn't go. I'll report back when it works.

-djr

[Stosh]

Garvin, et al.

Two moved blogs.

Everything seems to be working fine...

Needed the following when it told me it would no longer take my MD5 password:

viewtopic.php?f=1&t=17712&p=10425053#p10425053

But, came here, searched it out, and got it working.

THANK YOU!

-John

[Kominek]

Hi,

sorry for stealing your topic, but i have a question:

is there any 'plugin' of easy way to move mysql db to another server without using phpmyadmin or tools like that?

thanks in advance!

[Don Chambers]

is there any 'plugin' of easy way to move mysql db to another server without using phpmyadmin or tools like that?

thanks in advance!

None that I am aware of.

[garvinhicking]

phpMyAdmin is definitely the bast and safest way to go.

[Kominek]

thanks for help, I'll try to move it with phpmyadmin

[der_kaepten]

Sorry for using the subject, too but won't to create a new one for same action.

I moved succesfully from server A to server B. All DB-data and program etc. are there, all rights are set correct (from my point of view), all new path are set in DB.blog_config. Even when I start index.php I get only a "blank white screen" with message who long it tooks to create the page

After move/delete serendepity_config_local.inc.php a new one was created (with index.php), also new tables in a blog where created, but that's it, same result - "blank screen".

When I change i.e. password in serendepity_config_local.inc.php, get error no access to db possible, that makes for me clear that DB-access is working.

Does anyone have any idea what went wrong? I'm now searching for that since several days without success

many thanks in advance
best regards
Juergen

[Timbalu]

A "blank white screen" is something other than a runtime message...
The first usually means FATAL PHP error, please look into your webservers logfiles (access.log & error.log) to see why this happend. The second could mean you might have to screw up php.ini setting regarding maximum proceeding wait times...