How can I use git to make multiple sites based off of the same "core"?

@chrisf79 I wouldn’t really have separate repositories for exactly the reasons you list: if there’s a framework update, or you need to fix a bug, you then need to apply that update/bug fix to multiple repositories on multiple servers (or to multiple applications running on one or more servers).

It sounds like a SaaS approach might be better if you’re looking for a single codebase to manage multiple websites. I’ve done this before as I had a similar situation where I had my own CMS, where I built the same type of website for different clients, and then had multiple versions of the same codebase on multiple different servers, and maintaining these sites was an absolute pain. So I then consolidated them into a single Laravel-based application.

So, in your database, you could have a websites table, and then add a foreign key to your tables to associate records (such as property listings) to a particular site. You could then use Laravel’s (poorly named) “subdomain” routing to route based on the full domain:

Route::domain('{website:hostname}')->group(function () {
    // Website property routes...
    Route::resource('properties', PropertyController::class)->only(['index', 'show']);

    // Other website routes...
});

This will look up a Website model based on the hostname attribute, i.e. golfrealestate.com. This will then inject a Website model instance as the first parameter of your controller actions, allowing you to retrieve records scoped to that website:

class PropertyController extends Controller
{
    public function index(Website $website)
    {
        $properties = $website->properties()->latest()->paginate();

        return view('website::property.index', compact('properties'));
    }

    public function show(Website $website, Property $property)
    {
        return view('website::property.show', compact('property'));
    }
}

You might be wondering what that website:: prefix is in view names, and that would be the second part of making websites customisable. It’s a Blade namespace, and basically allows Blade to look in multiple directories for a named view, so you can use this to have “default” templates, but then per-site overrides if you need them. So, you could have middleware that registers the view namespace that looks like this:

class RegisterWebsiteViewNamespace
{
    public function __construct(#[RouteParameter('website')] protected Website $website)
    {
    }

    public function handle(Request $request, Closure $next)
    {
        View::addNamespace('website', [
            resource_path(sprintf('views/vendor/websites/%s', $this->website->id));
            resource_path('views/website'),
        ]);

        return $next($request);
    }
}

This needs to be done in middleware as we need access to the current Website instance after it’s been resolved. But what it will do is add a namespace called website that will then check for a named view in the following order:

1. In the website-specific directory, i.e. resources/views/vendor/websites/1
2. Fall back to “default” view in resources/views/website

I’ve built a number of applications this way and they all work well. You don’t need packages, and you don‘t need awful global scopes that work fine for your front-end routes, but are then a pain in the ass to work around when you don’t want them to be applied, i.e. in admin panels, queue jobs, Artisan commands, etc.

It is my question as well. Has anyone tried to make the whole Laravel project into only a package? It seems to be a risk as we need a defined command(Use $this->commands([...]) in ServiceProvider), manually register with Livewire::component(),... Hope someone can give me experience!

Hi, I did this for a job 6 years ago, albeit we were using Zend Framework, but the ideas are similar. You need to dynamically vary where to find things based on which child site you were trying to render. We used a server config directive in each sites apache configuration to key which site the code should render.

Keep in mind you may need to have site specific configs and cache, as well. For example, if each site has it's own database each one must have it's own config. You'll probably want to have separate .env files, one for each.

We used simple 3 letter unique keys. It worked well and wasn't difficult to maintain or enhance.

I have the BE Laravel source code. Currently, I will make a separate git repository as some features will be different for different sites. Currently, I do not think that if/else, switch,... code for each website is good, as it will make the common code messy

But the problem here is that when I have a new feature or fix some code, I will have to bring the code to every repository. So I plan to make my whole project like a package. Any different will be overwritten on the site repository. But seem to make the whole project a package which is not easy, as it will use a lot of things: Livewire, command,...

Hope someone can give me advice. Thanks in advance!