URL issues when building a new site but uses some of our old pages


(Nic Hubbard) #1

Matrix Version: 5.4.3.1

We are working to build a brand new Pacific Union College website hosted on the same Matrix install as our current/old site. Because we are a small team we plan to launch the new site in parts, while leaving some deep content on the old design until we can get those updated. This leads me to some questions:

  • The new site is under a site asset (with added path), and the old site is under a site asset.
  • Many of the new parts of the site will replace old parts, but they need to use the same URL.

Basically I need the new pages to overwrite the old pages that are being replaced, and in a quick seamless way when we launch. Then I also need to be able to still access old pages that haven’t been replaced, which will have the old design.

Building the new site under the old Site asset doesn’t seem like an option due to the complexity of designs/paint layouts, overrides and cascading of things that would be happening. It would be a nightmare.

How have others done this?


(Aleks Bochniak) #2

We’ve done this by cloning the VM for the original site and building the new site over the top of the old site in the clone VM. On go live, it was easier to switch VM images, than do a massive url update.

bit of a rough way to do it - maybe someone from Squiz can suggest a tool they use to do this?


(Nic Hubbard) #3

Thanks.

Yeah, I would love to hear if Squiz has ever done this. It is one thing to completely replace a site, but another to keep parts of the old side around at the same URLs then slowly replace those.


(David Schoen) #4

The handful I’ve been involved in we always managed it by moving entire domain names at once (there’s some relatively safe SQL if you’re moving hostnames).

If you could link all the legacy content that’s going to stick around under the new site that might make for a working process on the first transition at least. If the remaining transitions are all smaller sites, it might be ok to just drag them around in the tree manually?


(Nic Hubbard) #5

One of the big problems I have though is the URLs. The new site I am building has added “version5” to the URL. But when those go Live I need to remove that so that. This sounds like it will be the major problem since there is another site (old) with just the www.puc.edu URL which is what the new site will need.


(Nic Hubbard) #6

Could an Apache rewrite work here?


(David Schoen) #7

Apache rewrites (assuming you mean rewrite in place and not redirect) often end up extremely complicated and leave odd ball cases that don’t quite work right - because Matrix is producing absolute URLs the URLs have to be written on the way back out of Matrix as well as on the way in.

It can be made to work, but I don’t remember anyone trying it many years and many of the attempts didn’t last long.

If you can have a new site configured on version5.puc.edu it’s possible to actually swap www.puc.edu -> old.puc.edu and version5.puc.edu -> www.puc.edu in a single transaction (i.e from the front end it’s atomic, although caches still need to be flushed separately).

It requires messing around with URLs underneath Matrix, so I don’t think we’d be able to support it particularly but if you’re careful about testing it somewhere other than production first it’s relatively safe as long everything is moving at the hostname and not path level. I’ve managed at least a few rebrands this way, one with nearly 100 hostnames shifting around in the transaction. I’ll share the SQL if you want it, but don’t want to muddy this more if you’re not going to go down that path.


(Nic Hubbard) #8

I am not particularly good with SQL, so I am not sure I would want to do this.

I think I am going to have to end up just changing URLs in Matrix when the time comes. Is there a faster way to do this than a HIPO job?


(Marcus Fong) #9

If you’re changing URLs on a whole site, there’s the replace_url.php script:

https://matrix.squiz.net/manuals/server-administrator/chapters/replace-url-script

It also uses SQL under the hood, which makes it considerably faster than a URL change and Update Lookups HIPO in the Matrix backend.