Statamic V3 installation in sub-directory?

[mihaicirstea]

Hello,

We are trying to setup Statamic v3 in a subdirectory /blog/ however we ran into problems configuring it to work property.

It seems statamic doesn't know that it should run under /blog and all the assets (css, image, js) should be in this subdirectory. It seems to look for assets relative to the root (but there is no asset from statamic in the root).

We had to hardcode some things and we prefixed with /blog but when we configure nginx to load statamic from a subdirectory, it doesn't know anymore where the assets are (so we had to hardcode the path to css / js files).

Also the images from the "blog homepage" are not shown because statamic has a functionality that is resizing images on the fly, but now the urls for resize images are not matching the right route from statamic to actually resize the images and display them.

We found instructions for Installing in a Subdirectory for v2: https://v2.statamic.com/knowledge-base/subdirectory-installation but nothing for v3.

Are we correct to assume that Statamic 3 is NOT built to support this kind of installation in a different directory under a "/something"?

I would very much appreciate some advice because right now we're stuck.

PS: We can't run it the root because we already have a "catch-all" route for custom pages on our site.

Thank you.

[edalzell]

Maybe something like this? https://laravel-news.com/subfolder-install

[iulyanp]

Hi,

There is this elegant solution https://serversforhackers.com/c/nginx-php-in-subdirectory which I tried for this scenario.
It kinda works but there is one thing I didn’t figure out how to properly configure in statamic.

After I configured nginx, because my application has the domain https://mywebsite pointing to /var/www/mywebsite/ and I want to use statamic application just to build a blog with the url https://mywebsite/blog/ pointing to /var/www/mywebsite-blog/, I configured the APP_URL into .env as APP_URL = https://mywebsite/blog/.

In order to have all the urls prefixed with /blog into statamic I used the following configuration.

Statamic documentation sais to configure your "sites" like so:

    'sites' => [

        'default' => [
            'name' => config('app.name'),
            'locale' => 'en_US',
            'url' => env('APP_URL'), // this translates in my case to https://mywebsite/blog/
        ],

    ],

Note! I also had to change where the css / js files where generated so I prefix the location public/blog/css and public/blog/js and configure nginx to read them from that folder with the same alias approach.

But Statamic has this routes for images manipulation with Glide:

Site::all()->map(function ($site) {
    return URL::makeRelative($site->url());
})->unique()->each(function ($sitePrefix) {
    Route::group(['prefix' => $sitePrefix . '/' . Glide::route()], function () {
        Route::get('/asset/{container}/{path?}', 'GlideController@generateByAsset')->where('path', '.*');
        Route::get('/http/{url}/{filename?}', 'GlideController@generateByUrl');
        Route::get('{path}', 'GlideController@generateByPath')->where('path', '.*');
    });
});

As you can see it prefixes all the Glide routes with the $sitePrefix.

If you configure your nginx to work as in the post above, you will see that Glide routes will not match anymore because your url is /blog/img/asset/YXNzZXRzL29jdG9wdXMuanBn?h=570&w=1472&fit=crop&s=9d7aeed8a8fc344395dd5728d4aa5916 but nginx will end up by rewriting it to /img/asset/YXNzZXRzL29jdG9wdXMuanBn?h=570&w=1472&fit=crop&s=9d7aeed8a8fc344395dd5728d4aa5916 and the GlideController will not match.

The issue is that if you prefix all the urls with /blog in the sites.php config file, Glide routes get also prefixed with that /blog as you can see Route::group(['prefix' => $sitePrefix . '/' . Glide::route()]

[root@server mywebsite-blog]# php artisan route:list | grep -i glide
| | GET|HEAD        | blog/img/asset/{container}/{path?}  | generated::6lZ5RZNfk73qMVOM        | Statamic\Http\Controllers\GlideController@generateByAsset 
| | GET|HEAD        | blog/img/http/{url}/{filename?}     | generated::YM9PDrSdO6H5pV1M        | Statamic\Http\Controllers\GlideController@generateByUrl
| | GET|HEAD        | blog/img/{path}                     | generated::SAH2Tf4P5DXFYCZC        | Statamic\Http\Controllers\GlideController@generateByPath 

Because of this, the glide routes are not matched by the /blog/img/asset/YXNzZXRzL29jdG9wdXMuanBn?h=570&w=1472&fit=crop&s=9d7aeed8a8fc344395dd5728d4aa5916 image paths when you use alias nginx configuration and you get 404 for those images.

To make this work, maybe glide routes should not be prefixed with the $sitePrefix all the time or maybe I'm missing something and there is actually another solution to this scenario.

I would vary much appreciate any idea regarding this.

P.S.

Another issue, which I believe it's a small bug into statamic code is that the hash from the image url YXNzZXRzL29jdG9wdXMuanBn can sometimes contain = signs.

For example if you have a img/asset/donut.jpg image in the GlideUrlBuilder.php file you will pass to the asset case with the following values:

$this->itemType() -> "asset"
$this->item->containerId() -> "assets"
$this->item->path() -> "donut.jpg"
$path -> "asset/YXNzZXRzL2RvbnV0LmpwZw=="
$params -> array:3 [▼
  "h" => "570"
  "w" => "1472"
  "fit" => "crop"
]

case 'asset':
    $path = 'asset/'.base64_encode($this->item->containerId().'/'.$this->item->path());
    break;

The end result because of the base64_encode function would be:

/img/asset/YXNzZXRzL2RvbnV0LmpwZw==?h=570&w=1472&fit=crop&s=60f26b060eef8d737ec826f05946024d

But notice that this hash YXNzZXRzL2RvbnV0LmpwZw== has 2 == signs at the end.
This is causing an issue when the method generateSignature from League\Glide\Signatures\Signature is called, because the parameters used to create the signature hash will be like so:

$params -> array:4 [▼
  "/img/asset/YXNzZXRzL2RvbnV0LmpwZw" => "="
  "fit" => "crop"
  "h" => "570"
  "w" => "1472"
]

Notice that in the previous $params array you will not have the first element "/img/asset/YXNzZXRzL2RvbnV0LmpwZw" => "=" which is there only because the hash contains == signs.

Let me know if anyone else could reproduce this, I think just by replacing the = signs from the generated hash would fix the issue.

Thank you!

[mihaicirstea]

@edalzell Hi - Do you have a solution for the bug mentioned above by iulyanp in the PS> section where the hash from the image url example: YXNzZXRzL29jdG9wdXMuanBn can sometimes contain = signs?

[edalzell]

having the = is not a bug.

It's maybe a bug that Statamic can't handle this situation though. Not sure.

You can always open an issue and see what they say.

[jasonvarga]

Subdirectory support in the way that you're describing is not really common, but I guess you could make it work.

/
|-- index.php                      your real home page
|-- statamic                       put the whole statamic project in here. use an nginx rule to prevent people from access it.
|   |-- app, content, vendor, etc
|-- blog                           where statamic will be served from.
    |-- index.php                  this would have been public/index.php

In blog/index.php, change the lines that load the composer autoload file, and the bootstrap file:

require __DIR__.'/../statamic/vendor/autoload.php';
...
$app = require_once __DIR__.'/../statamic/bootstrap/app.php';

In statamic/config/statamic/sites.php, set the url to /blog/.

Where you put your assets is up to you, but you'll need to be aware that if there are places that would be relative to the root, it will be relative to the actual root, not /blog. That's just the way websites work.

[mihaicirstea]

@jasonvarga Thanks for your feedback!

I have to ask: How come Statamic is not easy to deploy to display on a /blog/ subdirectory for existing websites? Because I assumed that would be the most common way people install it...

We did all this to get around the problem of our existing website already having a "catch-all" route... therefore from the docs we understood this would prevent us from installing it in the root.

What am I missing here? Was there another way to accomplish our simple goal of our Statamic blog to be served from /blog?

[jasonvarga]

I assumed that would be the most common way people install it...

It's definitely not.

We did all this to get around the problem of our existing website already having a "catch-all" route

Is your existing website a Laravel app?

[mihaicirstea]

Is your existing website a Laravel app?

Yes

[jasonvarga]

Then you should install Statamic into that.
https://statamic.dev/installing/laravel

Then you can change your catch all route to exclude the blog subdirectory (and cp for the control panel), and Statamic should just hum along.

Route::get('{segments?}', 'YourCatchAllController@show')
  ->where('segments', '(?!blog|cp).*');

https://laravel.com/docs/9.x/routing#parameters-regular-expression-constraints