I might be wrong, but as far as I know all url-functions create placeholders which are post-processed after all rendering (in order to cache robustly). Thus, there is no url in your result, but a placeholder value - hence your regex will never match.
Like jsi suggests, this could be a criterion for you to use relative URLs on your site, and prefix these URLs with the protocol and server address, but make sure to do this prefixing outside (separately) of the XPath function call that generates the URL, or else the whole logic will be replaced when the content URL is generated by the portal function.
Alternatively: Construct a content URL manually. There are two types of content URL formats:
Traditional content URL, created manually from the XML data available beneath the element in the content data
You have to be very explicit in your XPath query when generating the path to the content location, as it’s important that it belongs to the correct site and probably a few other snags that must be taken care of. I’ve never done this myself, but it should work.
Content without any home (or ignoring content home)… a permalink. This will always work, but is a bit ugly.
The nice thing about generating a permalink is that it redirects to a content URL if the content in fact already has a home on that site. Or at least, that’s my vague recollection of what it does… Try it, and see if it works for you.
Just a followup on what we ended up with here.
We are now using method 1 with method 2 as fallback when contentlocation is not available.
When using contentlocation we also have to check if the type is a menuitem or not. If not, the name should be added to the end of the url.