Embedded Image

[jenolan]

The optional logo at the top of the display is loaded inline (ie img src="data:image/png;base64...>) this is really bad as every page load resend all that data when if the image were copied into the /public/img/logo.png it would be cached by the browser!

[jenolan]

Why it is bad ;)

[jbrooksuk]

Now that we've dropped Heroku, this is far likelier.

[jenolan]

I was tinkering, this is a bit nasty but should work... index.blade.php unable to test due to bandwidth limiting

    @if($bannerImage = Setting::get('app_banner'))
    <div class="row app-banner">
        <div class="col-md-12 text-center">
            <?php $bannerType = Setting::get('app_banner_type') ?>
            @if($appUrl = Setting::get('app_domain'))
            <a href="{{ $appUrl }}"><img src="data:{{ $bannerType }};base64, {{ $bannerImage}}" class="banner-image img-responsive"></a>
            @else
            <img src="data:{{ $bannerType }};base64, {{ $bannerImage}}" class="banner-image img-responsive">
            @endif
        </div>
    </div>
    @else
        @if(file_exists('./img/logo.png'))
        <div class="row app-banner">
            <div class="col-md-12 text-center" id="app-banner-img">
                @if($appUrl = Setting::get('app_domain'))
                <a href="{{ $appUrl }}"><img src="/img/logo.png" class="banner-image img-responsive"></a>
                @else
                <img src="/img/logo.png" class="banner-image img-responsive">
                @endif
            </div>
        </div>
        @endif
    @endif

[jbrooksuk]

I have another idea.

Within public we have a storage directory where all files are ignored. We save the file there, then if someone is to git pull the logo remains there.

[jenolan]

On my up-to-date system there is no storage in public it is in the root. Surely the 'easy' way would be to dump it into /img as logo.png when an update happens or the image is updated re-drop it into the directory. Easy peasy.

[jbrooksuk]

There isn't a public/storage directory currently, but there can be, because we really don't want to have people keep uploading their logo :smile:

[jenolan]

That's why I suggest, leave it 'stored' as-is. On upgrade or when the image changes simply dump it to /img/logo.png. Same effect no need for an extra artifact no user upload necessary and no embedded image.

[GrahamCampbell]

There's no reason why we can't get php to serve the image. it doesn't have to be physically stored there for the webserver to dish out.

[jenolan]

True but that means setting it up to send the correct headers, respond with not modified and so forth. For this it seems way easier just to create the image file in the existing image directory and let apache et al do the work.

[jenolan]

If you could put a note in for https://github.com/jenolan/Cachet.Upgrade what it does...

• Updates Cachet from Git
• Runs db upgrade
• SSL added to .htaccess (optional)
• Logo copied to ~/Cachet/public/img/logo.png & Template altered to use the image (optional)

[GrahamCampbell]

True but that means setting it up to send the correct headers, respond with not modified and so forth.

That's fine. Your server should be able to do that. The fact an image came from php should make no difference to the headers it applies.

[AchoArnold]

Hey @jbrooksuk . I'll love to pick this up if possible. From the chat you guys had, I didn't quite figure out which approach will be best. Do we just store the banner image in `public/storage/img/banner.png' during the upload as @jenolan suggested or do we compile the image using PHP and serve it directly at runtime using something like https://stackoverflow.com/a/15153931/2561122

CC @GrahamCampbell

[GrahamCampbell]

Having PHP serve the image would be fine, but not using that code example there. Just return a response object.

[jbrooksuk]

Thank you for your input on Cachet 2.x. We are shifting our attention and resources to Cachet 3.x and will no longer be supporting the 2.x version. If your feedback or issue is relevant to the 3.x series, we encourage you to engage with the new branch.

For more information on the Cachet rebuild and our plans for 3.x, you can read the announcement here.

We appreciate your understanding and look forward to your contributions to the new version.