Advice needed for building out a new client site

[TemplateRepo]

I’m about to build out a new site for a client, let’s called them ClientX.

Their domain is clientx.ie, but at the moment another company controls this domain, we’ll just point it to the new site on our server once it’s ready to go.

We will build the site on a subdomain: clientx.mycompanydomain.com This is standard for how we work.

This site is going to be almost 100% Alloy. I’ve used Alloy a lot now, but I’m still not 100% sure on how things like URL’s and domain, and in particular domain changes, will affect things between building it on clientx.mycompanydomain.com and then the final domain name that’ll be clientx.ie.

Can anyone (Adam?) offer any advice?

I should say once the site is out of dev and ready to go live we won’t be moving it from clientx.mycompanydomain.com just pointing clientx.ie to it.

I can’t answer too many questions about how the domain will be pointed to the new site and/or how our server is setup as it’s not an area I get involved with, I outsource that. But, I will ask any questions needed of the guys who look after that end of things for us.

Thanks.

[Panans]

@TemplateRepo , I test my new websites on a subdomain on my own server or on the clients server. When using Alloy all of the Embeds and Blog entries lose their links once placed on the final destination (root) for their URL’s are very specific. Once you place your project in its final place, you’ll probably have to redo the Embeds.

Maybe there is a way around it (in the source code), but I haven’t found it. Anyway, the content of the Embeds/Blogs can quickly be redone via copy/paste. The Embed Stacks themselves however have to made over and again placed in your project.

It is what it is.

Hans

[elixirgraphics]

@TemplateRepo

This site is going to be almost 100% Alloy.

This could be a bit overkill. I would think there’s a lot on the pages of the site that will never (should never) change. You won’t want to make those Alloy items. Don’t forget, Alloy is not a full-blown CMS. It is a Blog tool with some content helpers for oft changed content.

@TemplateRepo

I’ve used Alloy a lot now, but I’m still not 100% sure on how things like URL’s and domain, and in particular domain changes, will affect things between building it on clientx.mycompanydomain.com and then the final domain name that’ll be clientx.ie.

Will this be a 403 redirect? If it is you shouldn’t have any problems I wouldn’t think. I’ve not tried it, but you might do some experimentation before your final move.

Alloy was designed to be built and used where it will live. This is because that is how the majority of users in the RW community build their sites. More advanced users like yourselves like to build in one location and go live elsewhere, transferring the site over from a staging location to its final home.

Alloy uses the information you supply in your project file’s General and Publishing settings, as well as the domain it lives on to build out URLs in most cases. An example of this is when you upload an image in the Editor for a Blog Post – The Editor builds the URL based off of those settings, and the Editor’s location on the server (its current URL in the browser) to construct the URL of that image that will be inserted into the Markdown file for the Blog Post.

As @Panans points out Embeds work similarly. The instant you start dragging an Embed from the Editor to your project file, the Editor builds an absolute URL that points directly to that Embed and inserts it into the stack that is built on your page. This ensures that the Embed in your project knows exactly where that Markdown file exists on your server.

[TemplateRepo]

@elixirgraphics

This could be a bit overkill.

Five Editor pages overkill enough for ya

But ya, I do get what you are saying, but I have built out a really excellent little CMS template site that clients love, and once you get your head around how it works, it’s really easy to maintain/update. Building it in the first instance is not for the light hearted though. It took me a long time to get it all working correctly and being able to repeat that over and over again, for different sites (four clients presently using it now, this will be the fifth). Should add that in all previous instance the domain/site was either already hosted on my server, or it was a new domain so we didn’t have to worry about building in on a sub.

That aside…

This particular site won’t move, as such, it’ll always be in clientx.mycompanydomain.com. Initially, during the build this is how I will access it, and publish it etc. It’s only when it’s ready to go live will my server guy edit the DNS/nameservers for the domain to point to it. And even when this is done you can still access it via clientx.mycompanydomain.com. Although when I do the final publish the publishing domain will change to the actual one, not the sub.

Does that make a difference?

[elixirgraphics]

@TemplateRepo

Five Editor pages overkill enough for ya

That is insane. So you have 5 different blogs on the site?

@TemplateRepo

Does that make a difference?

As I mentioned above – the URLs will be generated from the domain your site is on when you upload images, drag Embeds to your project, etc. as well as the information you provide in the project file settings. If that changes and those URLs it has generated from your uploads, embeds, etc will be inaccessible going forward after your final move, then things will break, and you will have to redo those Embeds, uploads, etc. as it isn’t designed to work in that fashion, as it uses absolute URLs. If you can wait until things are moved to start embedding, and uploading images you may save yourself a lot of time.

[TemplateRepo]

@elixirgraphics

That is insane. So you have 5 different blogs on the site?

LOL. Yes, and no. This site will have a blog, news, services and FAQ page, which are all Alloy blogs. The homepage is also an Alloy blog, but it doesn’t work like an Alloy blog, not exactly. Imagine a page with about seven blog posts, with a picture, and a bit of text, but no “read more” link. That’s the home page.

Header banners and titles are embeds and the page footers are made up of droplets. I might be getting my droplets and embeds mixed up there!

I realise this all sounds mad, but it all works really well. Each editor page has a little “Editor” menu on it, so users can easily navigate to the correct editor page.

Before making this available to clients I tested it on a few of my more challenged clients, they all worked it out and were updating content in no time. So I pushed it and now offer it as part of portfolio.

I’m never posted a link to it here, as I didn’t want to encourage less adventurous users to try it, but if you want to see it in action I’m happy to fire up some links.

As for the absolute links. Building out the structure then waiting for the final domain to come over might be the way to go, it’ll just mean a day or two “downtime” as new content is added. Cheers.

[Panans]

@elixirgraphics , @TemplateRepo , Amen to that. Alloy works great, but you don’t want to exaggerate. For a Belgian client (3 official languages) I did Embeds for his agenda. Four main subjects in three languages means 12 Embeds on that page. On another he speaks about workshops and wanted Embeds above a fixed image and beneath the image. In three languages, again 6 Embeds. He also has a page where people can pay for workshops. The titles change regularly, so again 6 Embeds for that page. And a nice blog of course

Once approved, I moved the site to its final place on the server and redid all of the Embeds and the Blog. But it works like clockwork and the client couldn’t be happier.

Hans

[jacksona]

I’d love to see it, if possible, please!

[TemplateRepo]

I’m really reluctant to put up links, as I don’t want to be the one to encourage using Alloy well outside it’s remit, and so cause proplems for people.

So here is a nearly full length screenshot of the homepage of one of the demos I build for this little template.

This is the home page, but it’s really an Alloy blog page.

Each content area is a blog post. It has a nice picture and some text, as you wou;d have in most homepage content areas. That link in the posts isn’t to “read more” but to the part of the site relating to the picture and text. It’s inserted manually. The user just uses the regular blog post link feature in the editor and a bit of javascript turns it into a styled link.

The header is a banner with an embed (or is it droplet, can never remember) for the iage and the title.

This is the editor section, it should be fairly self-explanitory.

This is the FAQ page, which you can see is just a regular blog page, but styled for FAQ’d not blogs. (Looks like I’ve forgotton to add a header image).

The collections page, again, just a bunch of blog posts. Tis time though when you click “read more” the full “blog” post does open. The idea here is that the intro to each collection (or service, or whatever) is put as the blog post snippet, then the full info as the full blog post. Make sense?

It’s all pretty simple stuff really, it’s just a case of thinking about things a bit laterally, and working out how best to use the Alloy tools to reach your end-game.

I shoud add, on pages that use the Alloy lblog like the homepage (as content zones not posts) , the user doesn’t add new posts, they simply edit what is already there. They can shuffle the order in which the “posts” appear though by changing the dates of the posts.

[TemplateRepo]

Just as a footnote to my original question, about building out the mental Alloy site on a subdomain, the solution is obvious, it just took me a while to see it.

I’ll build out the site without using embeds and droplets initially, just regular stacks content. Then, one the domain is pointed to the subdomain, I’ll quickly replace the regular stacks with embeds and droplets, then republish.

It’ll add a bit of work to the build, but not much.

Posting this in case any searches for a similar scenario and wants to see the solution I used.

[Panans]

@TemplateRepo , I believe this is indeed the most efficient way. Publish with original content and make the embeds once the site is in its place. Hardly anyone will notice.

Thanks for your ‘out of the box’ approach. Good thinking!

Hans