Moved to new domain #736

New Issue

OVERLORD · 2026-02-04T22:06:56+03:00

OVERLORD commented

2026-02-04 22:06:56 +03:00

Originally created by @andresilva-cc on GitHub (Jul 4, 2018).

I was using BookStack in a domain for some time, then I moved the application to another VM with another domain. I've done all the migration correctly, copied the uploaded images, then I realized that the images inside each page are still pointing to the old domain.

Is there a tool to change this easily? By the way, I think the correct way would be to point the images relative to the root of the website (/).

Originally created by @andresilva-cc on GitHub (Jul 4, 2018). I was using BookStack in a domain for some time, then I moved the application to another VM with another domain. I've done all the migration correctly, copied the uploaded images, then I realized that the images inside each page are still pointing to the old domain. Is there a tool to change this easily? By the way, I think the correct way would be to point the images relative to the root of the website (/).

OVERLORD added the 🐕 Support label 2026-02-04 22:06:56 +03:00

OVERLORD closed this issue

2026-02-04 22:07:00 +03:00

OVERLORD commented

2026-02-04 22:07:08 +03:00

@lommes commented on GitHub (Jul 4, 2018):

Sadly there is no tool, but this should be not very hard to fix directly in your database.

For mysql there is replace which can be used like explained here: https://stackoverflow.com/a/10177250

so something like

Update pages SET html= REPLACE(html, 'domain1.com/', 'domain2.com/');
Update pages SET text= REPLACE(text, 'domain1.com/', 'domain2.com/');

should do the trick. Maybe some longer expressions are better to make sure it only changes urls in img-tags.

Backup your database before running this, because it is untested

@lommes commented on GitHub (Jul 4, 2018): Sadly there is no tool, but this should be not very hard to fix directly in your database. For mysql there is replace which can be used like explained here: https://stackoverflow.com/a/10177250 so something like ``` Update pages SET html= REPLACE(html, 'domain1.com/', 'domain2.com/'); Update pages SET text= REPLACE(text, 'domain1.com/', 'domain2.com/'); ``` should do the trick. Maybe some longer expressions are better to make sure it only changes urls in img-tags. **Backup your database before running this, because it is untested**

OVERLORD commented

2026-02-04 22:07:13 +03:00

@andresilva-cc commented on GitHub (Jul 6, 2018):

That worked, thanks!

@andresilva-cc commented on GitHub (Jul 6, 2018): That worked, thanks!

OVERLORD commented

2026-02-04 22:07:15 +03:00

@Dsignmind commented on GitHub (May 17, 2019):

Life saver.
Thanks for this!
Company decided on a domain change and everything broke.

@Dsignmind commented on GitHub (May 17, 2019): Life saver. Thanks for this! Company decided on a domain change and everything broke.

OVERLORD commented

2026-02-04 22:07:18 +03:00

@rec commented on GitHub (Dec 7, 2019):

Wait, so the URL of the domain is hardcoded in the database?

So my current plan to test this on a staging server with a few people and then switch over seamlessly is doomed to failure?

@rec commented on GitHub (Dec 7, 2019): Wait, so the URL of the domain is hardcoded in the database? So my current plan to test this on a staging server with a few people and then switch over seamlessly is doomed to failure?

OVERLORD commented

2026-02-04 22:07:23 +03:00

@ssddanbrown commented on GitHub (Dec 7, 2019):

@rec Absolutely, unless you run a couple of replace statements on your DB after switching as per the above (There's an outstanding issue to handle this via a command in the future).

@ssddanbrown commented on GitHub (Dec 7, 2019): @rec Absolutely, unless you run a couple of replace statements on your DB after switching as per the above (There's an outstanding issue to handle this via a command in the future).

OVERLORD commented

2026-02-04 22:07:29 +03:00

@rec commented on GitHub (Dec 8, 2019):

Yes, I did read that you have to change the data in the database in order to serve on a different domain, which is why I commented.

For example, what happens if the string in question in your "find and replace" happens to appear in user-entered data?

But more, the idea that you have to run a database find and replace just to deploy seems :-o.

You have to make a change, after which you can no longer use that database in the test area to test it, so you just have to push it over the production version, and hope it works?! Can you name some other well-known system that forces you to do this?

Handling it with "a command" doesn't fix any part of the problem. The issue isn't typing a few commands - it's that you have built-in fragility with a database that's hardcoded to a fixed endpoint.

Why are you storing the domain name in the database? And not just in one place, but many? It has many disadvantages and no advantages I can see.

The domain name should be in a single configuration file, not in a bunch of places in the database.

@rec commented on GitHub (Dec 8, 2019): Yes, I did read that you have to change the data in the database in order to serve on a different domain, which is why I commented. For example, what happens if the string in question in your "find and replace" happens to appear in user-entered data? But more, the idea that you have to run a database find and replace just to deploy seems :-o. You have to make a change, after which you can no longer use that database in the test area to test it, so you just have to push it over the production version, and hope it works?! Can you name some other well-known system that forces you to do this? Handling it with "a command" doesn't fix any part of the problem. The issue isn't typing a few commands - it's that you have built-in fragility with a database that's hardcoded to a fixed endpoint. Why are you storing the domain name in the database? And not just in one place, but many? It has many disadvantages and no advantages I can see. The domain name should be in a single configuration file, not in a bunch of places in the database.

OVERLORD commented

2026-02-04 22:07:33 +03:00

@ssddanbrown commented on GitHub (Dec 9, 2019):

@rec

For example, what happens if the string in question in your "find and replace" happens to appear in user-entered data?

Then you might have a hard time, Should generally be a rare event for people though unless you're hosting other services on a sub-path of your main BookStack URL.

Can you name some other well-known system that forces you to do this?

Wordpress

Handling it with "a command" doesn't fix any part of the problem.

I mean, It has literally fixed the issue, and makes it a non-concern, for others in the exact same scenario. I've migrated wordpress instances many times using "a command" with great success.

The issue isn't typing a few commands - it's that you have built-in fragility with a database that's hardcoded to a fixed endpoint.

Why are you storing the domain name in the database? And not just in one place, but many? It has many disadvantages and no advantages I can see.

Yeah, It's a design choice I've made and one that I stand by. The main negative impact of it that I see are for users that want to host on multiple protocols (TOR and HTTPS for examples). I know it seems bad in the perspective of a dev but in reality it's just so damn practical. Keeping links absolute makes implementation & debugging a fair amount easier.

There would be two main alternative options as far as I can see:

Store relative links.
Use ids to link to specific items.

The first is probably more viable than the second although it gets complicated when sub-paths and proxies come into play. Additionally, relative links could make such location change operations harder as the find/replace pattern is way more generic and there's much higher chance of conflicts.

Using ids introduces a lot of logic complexity. Custom logic would be needed anywhere content is displayed or used, Which makes the content less portable and more complex to handle; Something I'm very much against in a user-content focused platform such as this.

@ssddanbrown commented on GitHub (Dec 9, 2019): @rec > For example, what happens if the string in question in your "find and replace" happens to appear in user-entered data? Then you might have a hard time, Should generally be a rare event for people though unless you're hosting other services on a sub-path of your main BookStack URL. > Can you name some other well-known system that forces you to do this? Wordpress > Handling it with "a command" doesn't fix any part of the problem. I mean, It has literally fixed the issue, and makes it a non-concern, for others in the exact same scenario. I've migrated wordpress instances many times using "a command" with great success. > The issue isn't typing a few commands - it's that you have built-in fragility with a database that's hardcoded to a fixed endpoint. > Why are you storing the domain name in the database? And not just in one place, but many? It has many disadvantages and no advantages I can see. Yeah, It's a design choice I've made and one that I stand by. The main negative impact of it that I see are for users that want to host on multiple protocols (TOR and HTTPS for examples). I know it seems bad in the perspective of a dev but in reality it's just so damn practical. Keeping links absolute makes implementation & debugging a fair amount easier. There would be two main alternative options as far as I can see: * Store relative links. * Use ids to link to specific items. The first is probably more viable than the second although it gets complicated when sub-paths and proxies come into play. Additionally, relative links could make such location change operations harder as the find/replace pattern is way more generic and there's much higher chance of conflicts. Using ids introduces a lot of logic complexity. Custom logic would be needed anywhere content is displayed or used, Which makes the content less portable and more complex to handle; Something I'm very much against in a user-content focused platform such as this.

OVERLORD commented

2026-02-04 22:07:36 +03:00

@canlann commented on GitHub (Mar 21, 2024):

The Issue would have to be reopened.
I did followed the Documentation and changed the URL to my new domain. It did only function half way.
Some reference links were being updated, some were not. The linux log shows successfull changes of approx. more than a thousand entries. No errors in the logs connected with the php artisan command of changing url, clearing server cache and reindexing sql database.

Result:
Moved to new domain, changed url references in sql database with php artisan. In the end the webpage updated a few routes
on the primary page ( http://url.domain and https://url.domain ), but did not update the links on pages beyond the root domain route ( e.g. http://url.domain/login has still reference links that route me to http://oldurl.domain ).

I am unsure where the solution could be, but I am suggesting that either the php artisan script has to updated to the mysql version or sql database has been updated succefully but there are source code errors in html files and so forth.

Unfortunately this way made me lose my curated bookstack server.

Hint for people with exactly the same problem:
Try to reobtain your oldurl and go to an older server image, sqldump, etc. pp.

@canlann commented on GitHub (Mar 21, 2024): The Issue would have to be reopened. I did followed the Documentation and changed the URL to my new domain. It did only function half way. Some reference links were being updated, some were not. The linux log shows successfull changes of approx. more than a thousand entries. No errors in the logs connected with the php artisan command of changing url, clearing server cache and reindexing sql database. Result: Moved to new domain, changed url references in sql database with php artisan. In the end the webpage updated a few routes on the primary page ( http://url.domain and https://url.domain ), but did not update the links on pages beyond the root domain route ( e.g. http://url.domain/login has still reference links that route me to http://oldurl.domain ). I am unsure where the solution could be, but I am suggesting that either the php artisan script has to updated to the mysql version or sql database has been updated succefully but there are source code errors in html files and so forth. Unfortunately this way made me lose my curated bookstack server. Hint for people with exactly the same problem: Try to reobtain your oldurl and go to an older server image, sqldump, etc. pp.

OVERLORD commented

2026-02-04 22:07:39 +03:00

@jhume commented on GitHub (Jun 4, 2024):

Same problem as Canlann, lots of the inner pages still have broken links (login, home link, link to books on /books page. I did a find/replace on the entire SQL file but still there are some incorrect links. Strange. Have cleared memcache etc on the server too.

I ran these commands on the server:

php artisan bookstack:update-url http://olddomain.com https://newdomain.com

php artisan cache:clear

@jhume commented on GitHub (Jun 4, 2024): Same problem as Canlann, lots of the inner pages still have broken links (login, home link, link to books on /books page. I did a find/replace on the entire SQL file but still there are some incorrect links. Strange. Have cleared memcache etc on the server too. I ran these commands on the server: php artisan bookstack:update-url http://olddomain.com https://newdomain.com php artisan cache:clear

OVERLORD commented

2026-02-04 22:07:43 +03:00

@ssddanbrown commented on GitHub (Jun 4, 2024):

@jhume You also need to update the APP_URL in your .env file (or docker environment)

@ssddanbrown commented on GitHub (Jun 4, 2024): @jhume You also need to update the `APP_URL` in your `.env` file (or docker environment)

OVERLORD commented

2026-02-04 22:07:47 +03:00

@jhume commented on GitHub (Jun 4, 2024):

Ah, I'd totally forgotten the URL was stored in the .env file. Thanks so much for your quick reply!

@jhume commented on GitHub (Jun 4, 2024): Ah, I'd totally forgotten the URL was stored in the .env file. Thanks so much for your quick reply!

OVERLORD referenced this issue

2026-02-05 10:14:35 +03:00