jjozwiak commented 6 months ago

Bug report

What I did

I upgraded to backpack pro 2.0.20 to fix the Easy MDE field issue where content only loaded when clicking into the field fixed here - #5353

While this fixed the original issue, now the icons on this field are not loading because basset appears to be prepending a path to the CDN url:

https://example.com/storage/basset/cdnjs.cloudflare.com/ajax/libs/font-awesome/6.2.1/webfonts/fa-solid-900.woff2

What I expected to happen

Icons to load

What happened

Icon font files not loading because of incorrect path. Note I'm not experiencing this locally.

What I've already tried to fix it

Tried running php artisan basset:fresh but this didn't help.

Is it a bug in the latest version of Backpack?

After I run composer update backpack/crud the bug... is it still there?

Yes.

Backpack, Laravel, PHP, DB version

When I run php artisan backpack:version the output is:

PHP 8.1.24 (cli) (built: Sep 29 2023 01:25:08) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.24, Copyright (c) Zend Technologies
    with Zend OPcache v8.1.24, Copyright (c), by Zend Technologies

### LARAVEL VERSION:
10.42.0.0

### BACKPACK PACKAGE VERSIONS:
backpack/basset: 1.2.2
backpack/crud: 6.6.0
backpack/filemanager: 3.0.7
backpack/generators: dev-rename-make-commands
backpack/permissionmanager: 7.1.1
backpack/pro: 2.0.20
backpack/revise-operation: 2.0.0
backpack/theme-coreuiv2: 1.2.2
backpack/theme-coreuiv4: 1.1.1
backpack/theme-tabler: 1.2.0

welcome[bot] commented 6 months ago

Hello there! Thanks for opening your first issue on this repo!

Just a heads-up: Here at Backpack we use Github Issues only for tracking bugs. Talk about new features is also acceptable. This helps a lot in keeping our focus on improving Backpack. If you issue is not a bug/feature, please help us out by closing the issue yourself and posting in the appropriate medium (see below). If you're not sure where it fits, it's ok, a community member will probably reply to help you with that.

Backpack communication channels:

Bug Reports, Feature Requests - Github Issues (here);
Quick help (How do I do X) - Gitter Chatroom;
Long questions (I have done X and Y and it won't do Z wtf) - Stackoverflow, using the backpack-for-laravel tag;
Showing off something you've made, asking for opinion on Backpack/Laravel matters - Reddit;

Please keep in mind Backpack offers no official / paid support. Whatever help you receive here, on Gitter, Slack or Stackoverflow is thanks to our awesome awesome community members, who give up some of their time to help their peers. If you want to join our community, just start pitching in. We take pride in being a welcoming bunch.

Thank you!

-- Justin Case The Backpack Robot

pxpm commented 6 months ago

Hey @jjozwiak I think that's the expected behavior.

After you run php artisan basset:cache, your assets will be put on the disk, and served from there, not from the cdn.

I would advise you to try php artisan basset:clear && php artisan basset:cache so they run separately.

Also the php artisan basset:check should pass, making sure .env is properly configured.

If it doesn't help, please provide some more details on how I can reproduce the issue.

Cheers

jjozwiak commented 6 months ago

Hi @pxpm

Thanks for your help. After looking into this I discovered the basset commands weren't working due to permissions issues on the server.

However, what was interesting is that even without running the basset commands it was creating a local copy of the font-awesome css file but not the webfonts. I guess assets like webfonts only get copied locally when running php artisan basset:cache ?

Anyway once I get this permissions issue resolved I should be able to get the fonts to cache and I'll be back in business.

Thanks again!

pxpm commented 6 months ago

Indeed @jjozwiak

Basset works the following ways: 1 - you call basset:cache that scan your files and cache the needed assets beforehand. 2 - you don't cache beforehand, and every time basset finds a @basset() block while rendering, it will cache and serve the cached asset 3 - You can completely disable basset by using BASSET_DEV_MODE=true in your .env. In this case we will ALLWAYS use the cdn urls.

It's possible that it never got to the webfonts loading script ?

Anyway, I am closing this issue for now, if you figure out the permission issue and it's still failing, please open a new issue and we will take a look at it 🙏