Yes, wildcards. Op google vind je genoeg hoe je Wildcards doet met htaccess. Meer heb je niet nodig.

Yes, op de host betaalplugin.nl plaats je het volgende in de htaccess:

Redirect Permanent /bedrijven/marketing-metrics/ https://marketing-metrics.betaalplugin.nl/

op https://marketing-metrics.betaalplugin.nl/ regel je eventuele verdere redirects, denk aan http naar https.

Dat wordt voor mij ook iets te complex, je zou het jezelf makkelijk kunnen maken door een redirect middels PHP te doen.

header("Location: https://{$subdomain}.betaalplugin.nl/");

again, wildcards zoals ik al zei. Als je dat had opgezocht had je direct het volgende gevonden.
https://stackoverflow.com/questions/1533…th-get-variable

Hm, de oplossing van @darkshifty heeft in principe wel wat, ik zou in ieder geval niet allerlei aparte -en expliciete- rewriterules opstellen voor aparte pagina's. Maak dan één rewriterule die op het domein (*.)betaalplugin.nl werkt, en kijk dan of het subdomein overeen komt met een bestaande pagina en serveer anders een 404 pagina ofzo. En stuur dit alles naar één voordeur (single point of entry). Op die manier kanaliseer je alles nog steeds door een index-pagina.

Maar persoonlijk zou ik deze aanpak eigenlijk niet volgen. Kom je hier namelijk niet vreselijk in de knoei met SEO enzo? En wellicht komen pagina-statistieken op die manier ook in allerlei verschillende emmers terecht als je al het bezoek uitsplitst over allerlei subdomeinen, aangenomen dat je er meerdere hebt?

Wat is er mis met de oorspronkelijke vorm?

Tenzij het marketing-metrics subdomein een apart deel van de website betreft met een specifiek doel (bijvoorbeeld een soort van backend/portal voor klanten ofzo) en op die manier echt een soort van bestaansrecht heeft omdat die dingen doet die echt afwijkt van de rest van het betaalplugin.nl domein zou ik de site niet opsplitsen in allerlei subdomeinen.

EDIT: wat @Syntax voorstelt kan ook, maar wederom, ik zou de wildcard vervolgens niet in je querystring stoppen. Het is helemaal niet nodig om de "$_GET namespace" te vervuilen met onzichtbare variabelen. Deze waarde kun je prima uit een $_SERVER-variabele hengelen zonder $_GET te vervuilen.

Citaat van Frenzo.Brouwer

Update; heb het voor de helft werkend dankzij de link van @Syntaxx maar het probleem is nu dus dat ik een internal server error krijg..

Apache Configuration

RewriteCond %{HTTP_HOST} !^www\.
RewriteCond %{REQUEST_URI} !bedrijven\
RewriteCond %{HTTP_HOST} ^(.+?)\.betaalplugin\.nl$
RewriteRule .* /bedrijven-%1 [L]

Als ssl aan staat, zorg er best voor dat je http naar https doorstuurt. Wat zeggen de logs over we 500 error?

Dit kan wat mij betreft allemaal zonder serverconfiguratie en met slechts een enkele rewriterule die gewoon alles doorstuurt naar een index.php die het verder uitpluist. Zo verplaats je het probleem naar programmacode / programmeerbare logica. Is dat niet veel eenvoudiger?

Hangt er wel een beetje vanaf wat de rest van het domein allemaal doet, maar los daarvan verdient één centrale verkeersregelaar eigenlijk altijd de voorkeur boven tig verschillende stukken configuratie die bovendien allemaal op een verschillende plaats staan en ook apart ingeregeld dienen te worden. Simpelweg uit oogpunt van overzicht / simpliciteit.

Citaat van FangorN

Dit kan wat mij betreft allemaal zonder serverconfiguratie en met slechts een enkele rewriterule die gewoon alles doorstuurt naar een index.php die het verder uitpluist. Zo verplaats je het probleem naar programmacode / programmeerbare logica. Is dat niet veel eenvoudiger?

Hangt er wel een beetje vanaf wat de rest van het domein allemaal doet, maar los daarvan verdient één centrale verkeersregelaar eigenlijk altijd de voorkeur boven tig verschillende stukken configuratie die bovendien allemaal op een verschillende plaats staan en ook apart ingeregeld dienen te worden. Simpelweg uit oogpunt van overzicht / simpliciteit.

Eensch. Maar als iemand die graag ook denkt aan optimalisaties is in theorie een apache/nginx/etc rewrite wel efficiënter. En je zal iets moeten implementeren op een veilige manier met ook een duidelijke structuur om het op te vangen. Als de code al zo'n basis heeft, lekker gebruiken inderdaad. Anders, als het enkel zo blijft, dan misschien die rewriterules gebruiken.

Overigens, ook al eens gekeken naar zo'n generator online? Die werken vaak best priems.

Zelfs als verschillende subdomeinen compleet verschillende pakketten gebruiken dan zou je index.php nog steeds als een soort van routing-portaal / superbootstrapper kunnen gebruiken met een simpel switch-statement:

<?php
$found = false;


switch ($_SERVER['SERVER_NAME']) {
    case 'www.domain.com': // website
    case 'cdn.domain.com': // CDN
    case 'blog.domain.com': // WordPress
    // et cetera
        $found = true;
    break;
}


if ($found) {
    // laad de config file behorend bij het subdomein
    require_once '/path/to/bootstrap/'.$_SERVER['SERVER_NAME'].'.php';
} else {
    header('HTTP/1.0 500 Internal Server Error');
    die('error: subdomain not found');
}
?>

En in /path/to/bootstrap/ stop je je configuratiebestanden. Bijvoorbeeld de config voor WordPress wordt dan /path/to/bootstrap/blog.domain.com.php etc. In de individuele cases van het switch-statement kun je eventueel nog meer constanten en/of environment variabelen instellen, of de configuratiebestanden specfieke namen en paden geven met behulp van een extra $path variabele ofzo.

EDIT: het enige wat je hiervoor nodig hebt is een enkele rewriterule die alles naar dit index.php bestand doorstuurt.