Set Unique Site URL on Trigger

Originally posted this in clients only, but don't think that's the right place…


Gday everyone, if an asset builder is configured to set up a new site, and a trigger is applied to the creation of a new site to get it configured nicely once created, is there a way to get the Apply URL element of the trigger to apply a unique URL each time a site is created?



Example: Content owner completes Asset Builder to create a new web. Trigger applies a temporary system-friendly URL to the site based on the name of the new site asset_name. So lets say you already have www.justice.tas.gov.au in your system URLs, and you create a new site called HR. Your new site is applied www.justice.tas.gov.au/hr or something similar once built (I'd suggest hr.justice.tas.gov.au, but it needs to first be in the system URLs and it'd require a new DNS record, something our editors wouldn't be able to do). This is only to enable the creator to begin editing the site instead of having to wait for an admin to apply a URL, and allows the admin to come in and apply a new URL whenever. I've tried keywords in the apply URL part of the trigger but they do not work.



Any help or alternative suggestions is really appreciated at this stage!

I don't believe there is a way to do this because the site asset requires more interaction on the part of the user than simply setting a webpath on an asset (ie, picking http/https and also resolving conflicts between urls, or urls that don't exist in system configuration, DNS resolution outside the matrix system, apache configuration). Generally this is the domain of the System Administrator to setup. If what you are trying to do is based off an existing url, then you obviously don't need all those steps, but this isn't the case in a large number of systems…


What you may need to consider is perhaps using the import/export scripts on the server in order to quickly setup the 'framework' for a new site, this appears to be what you are trying to achieve with the asset builder. Obviously this takes the frontend part out of the equation, but I don't see another way with existing functionality.