如何更換WordPress的網址？
上周講到臨時網站（Staging site）的運用時機和操作方式，那是在已有網站的情形下，複製一個臨時的網站，修改臨時網站後，再同步內容到正式網站。但是，還有一種情況，是新建一個網站，它的網址本來就是臨時的，有辦法在原地更改這個網站的網址嗎？
網址的更改，不是直接在WordPress的後台設定就好了嗎？
不是哦！其實還有許多網址是「存在資料庫」裡面，所以若要更改整個網站的網址，就意味著需要去「搜尋取代資料庫裡的網址記錄」。
雖然，也可以使用網站遷移的方式執行，但是遷移是把A站移到B站（同時有改網址的作用），還是需要費一番手腳，且需要開二個網站。
如果是在同一台主機上，不如直接改網址比較快。
更改網址的時機：
狀況一：臨時網站要改為正式網站：
例如：有一個案子，在創建時，是使用test.temp.com（臨時網址），在網站完成後，要將其改為正式網址yourdomain.com（正式網址）。
雖然，此時可以使用網站遷移的方式執行，但是遷移是把A站移到B站（同時有改網址的作用），還是需要費一番手腳。如果是在同一台主機上，不如直接改網址比較快。
狀況二：http要改為https：
例如：本來的網站沒有安裝SSL憑證，所以網址是http://yourdomain.com，在用了一段時間後，才要將網址改為https://yourdomain.com。
傑哥有遇到過這種情況，當SSL的憑證還沒申請下來，但是網站已經開始運營了一段時間，所以資料庫裡面所有的網址，都是以http:// 開頭的。此時會需要修改網址。
狀況三：將網站從www改為非www網址（反之亦然）
在少數的情況下，有時需要把含有www的網址，改為非www；或是本來是非www要加上www。此時也需要將資料庫裡面已存的網址做更改。
並且同時還要修改.htaccess或ngnix的conifg，以實現強制自動轉址。
更改網址的方法：搜尋與取代
更改資料庫類似於直接搜尋與取代資料庫中的記錄，所以取代後，是無法復原的。一旦進行取代，將無法恢復舊版本。除你你再執行一次取代（但有時也不一定能完全逆轉）。所以，強烈建議在搜尋與取代前， 一定要先執行資料庫備份或網站備份。
安裝 WordPress 搜尋取代外掛
更改資料庫中的網址，最簡單的方法是加裝外掛。例如：Better Search Replace、Search Regex。這些外掛可選擇特定的資料表進行搜尋取代，也支援「測試運行」，在真正取代前可以先查看結果，將會搜尋取代多少筆資料。
Search Regex甚至支援正則表達式，所以應用的範圍更廣。例如：
搜尋：<iframe.*?(/iframe>|/>)
取代：空
將上面的結果套用於全站，則會一次刪除所有的iframe。
使用WPvivid的外掛附加搜尋取代功能
之前傑哥有介紹過WPvivid專業版，也有改網址的工具，可在資料庫中，快速替換網域URL。也就是直接在現在的網站，把網址換掉。
這次實做過取代網址，將遇到的情境說明如下：
- 舊版網站（www.domain.com）：過期主機不續用，網站後台被鎖，無法搬遷。
- 新版網站（test.domain.com）：新主機。
此時，以test.domain.com為暫時的網址，進行網站重建與編修，完成後，取代網址的過程是這樣的：
- 將www.domain.com指向到新主機。
- 此時test.domain.com的指向也還留著。
- 進入test.domain.com的網站後台，更改所有的網址：test→www
- 更改完成，此時網站www.domain.com應已正常。
- 檢查無誤後，將test的a記錄取消。
- 以前的作法，通常的程序是：
將模擬網站打包→建立正式網站→網址指向正式網站→將測試網站的內容遷移到正式網站。 - 若用取代網址的作法：
正式網址指向模擬網站→將模擬網站網址取代為正式網站，原地改網址省下了很多步驟。
由上可知，直接改網址運用的時機得當，則可省下一部主機，且時間較為節省。
直接在資料庫中更改
當然，如果你懂得使用SQL語法，也可以直接在phpMyadmin的介面中，下達SQL指令更改。
登入phpMyadmin後，選擇SQL標籤，增加以下SQL語法：
update TABLE_NAME set FIELD_NAME = replace(FIELD_NAME, 'Text to search, 'Text to replace it with');
※大寫的地方代表資料表名稱、欄位名稱。
其實使用取代外掛，做的就是和直接下達SQL語法一樣的事情，還是使用外掛比直覺省心。
網址取代的注意事項：
取代網址後，查看原始碼，若仍然是舊的網址，這時請清除快取。若有圖檔、圖庫、相簿的外掛，也要清除該套件的快取。
取代的動作無法復原，請一定要先做資料庫備份（這裡有介紹不同網站的備份策略），以免有什麼不測時，無法挽救。
以上就是本文的全部內容。
如果你也有遇到類似的問題，歡迎參考，若有其他更好的方法，也歡迎留言討論。