Rebuild new Alloy site alongside existing site?

This is an interesting problem for me, and I can’t quite think of a solution.

I have an existing site that I’m rebuilding using Alloy. My challenge is that the pages on the new site will be mostly the same as the old (/servicing/ /aboutus/ etc.) and I need the old site to exist until the new Alloy powered site is ready to go and I “flip the switch”.

The challenge is that (as far as I can work out) Alloy needs to be built on each page in its full location, I can’t build it on a subdomain, then move it over.

I’m thinking through a few options but interested to hear how others may have approached this in the past?

I should add the direction I think is the best, and might work…

  1. In the new Alloy project put the homepage in a folder. This should “protect” the existing home page if I publish the new Alloy page to the root of the main domain. I think!
  2. Slightly change the name of all the new sites pages. So “workshop” can become “servicing” etc. Then put redirects in place one the new site goes live.

I think this might work, but what about the /resources/ and /rw_common/ folders? Will these still in this scenerio?

Thanks.

You can build it on a sub domain and move it over. You’ll need to update the URLs in the blog posts that are created by image uploading in the Editor afterwards. Or wait until the site is online to add blog posts.

You’re going to eventually have to republish to the new location to ensure the URLs in the General and Publishing settings are configured correctly for the site they’re being published to.

Oh that’s good, I must have misunderstodd things.

What about embeds and droplets? Will they need to be “relinked”?

Alloy creates absolute URLs for images, toppers, Droplets, etc when you upload them. The absolute URLs allowed me to make the blog posts portable so-to-speak. If you ever needed to move the blog the URLs would still point to the previous image locations so things would not break.

Absolute URLs seem to be more reliable for me as well within the RapidWeaver API. That said I have thoughts on making it possible to opt to use relative URLs, but it will likely take a good deal of work to get it done and keep the possibility of absolute URLs as well. That though is for a time in the future.

The absolute URLs that get created for image uploads will remain pointing to your subdomain when you move things over. It should all still work, you just don’t want to delete the images folder on the subdomain until you update your posts to link to the new final domain.

As far as updating the posts goes – you could download the Posts folder and use something like VS Code to search the folder for the sub domain in each file and replace it with the new, final domain name. This way you’re updating not only images in the body of the posts but the toppers as well.

Droplets themselves don’t have a specific URL, so they should be fine. They’ll be much like Blog Posts. Image URLs created on the sub domain will need to be updated for the final domain location. You could use normal text, images, etc for your sub domain and then build and insert droplets on the live site.

Embeds are another story however. Their URL is generated when you drag-and-drop it from the Editor into RapidWeaver. There’s no way to change this. As @jacksona points out you could simply build your content normally on your sub domain, and after you move it to the live site then start building Embeds and dropping them into the project.

In the case of Emebds I don’t think a relative URL will suffice. I’m going off the top of my head here, but I believe when I wrote this it needed an absolute URL for a reason. I think there’s a way to improve this in the future, but currently this is how it works.

Hope this helps.

1 Like

Thanks for that. What do you think to my idea above…

I think from my end that is the easiest way forward, and will only need a few redirects as it’s only got about seven pages. But I’m concerned about the RW folders, like rw_common etc. Would it be feasible to effectively publish two different sites to the same domain root and with some careful page naming (and putting the home page of one inside a folder) would it all work?

I could I guess just try it!

I say give it a try. I can’t say I can envision exactly what you’re describing, but it might be because I’m working several support tickets at once right now, which is not your fault.

I’m gonna set up a little test with a demo site later and see what happens. Essentially I’m going to publish two completely different projects to the same root folder, but with the two projects using different page foldees the homepage on one being in a folder. Then I’ll see if they will both work.

I suspect they won’t, as they will both be sharing the same RW_common folder, which I suspect is a really bad idea, but we’ll see.

Publishing a project to a sub-folder will be fine. They will not share RW_common folders as they’re separate projects. I do it all of the time. That is how each preview site for themes, stacks, etc is published under the same domain on my own sites.

Ya, sub-folders I do too, I was trying to get everything into the root, but with the home for one site at / and the home for the other at /homepage/

So let’s say site one has the following pages…

Home at /
Services at /services/
products at /products/

I thought adding a 2nd site to the same structure with the homepage in a folder but the pages in the root…

Home at /homepage/
Pageone at /pagesone/
Pagetwo at /page/two/

But I just tried it, and it didn’t. All RW does is push the pages into the /homepage/sub-folder. So it ain’t gonna work.

I know that most likely still makes no sense. In my head, it does, but lots of things makes sense there but none in the real world!

I haven’t tried what you’re outlining. Best way to know is to try it. If it is only a test, you’ve got nothing to lose except a little time. :clock1::clock2::clock3::clock4::clock6::clock7::clock9::clock10::clock11::clock12:

OK, one other idea for a easy(ish) solution…

Publish new Alloy site to root folder. This will get the editor pages in place. Now, republish the old site, which will get things back the way they are at the moment, but with the editor and uploads etc. pages in the correct location.

Next, publish the new site to /newsite/ and build away.

Once it’s all ready to go with all the droplets, embeds and blogs in place republish the new site back to the root, then sweep thru the code looking for /newsite/ and removing it.

Would that work?

Not sure I understand the extra step of publishing to the root folder. The URLs are created when you setup Alloy. The URLs are created each time upload an image or do the other things I outlined in my previous post. It is possible that you might be overthinking things.

It’s OK, I’ve finally got a moment to actually think this thru, and I’ve realised, yep, I’m massively over-thinking it.

I’m sorted. Thanks.

When you do your test I would be very interested to hear which direction you go.

I do want to improve this workflow in the future. But working within the confines of two different APIs that control files and their locations and such can be tricky.

Not a bother. I’m just setting it all up now, once done and tested I’ll Pm you the details.

1 Like