Canvas: Publishing assets for customization

[albertoelias123]

Is it possible to modify the /canvas navbar?
I would like to modify the component navbar to add a link to the internal area of ​​my application.
Is there any way to publish the views related to /canvas or to change at least the navbar?

[austintoddj]

The navbar is not editable at this time. What link were you wanting to add if it was?

[albertoelias123]

A link to my application's home page, something similar to:
<a class="dropdown-item" href="{{ route('home') }}"> Application Name </a>
I would add this link to the menu dropdown. I did this for /blog but as I don't have access to the /canvas navbar I couldn't

[austintoddj]

Good to know, thanks for the info.

Because this topic has been brought up multiple times...

• https://github.com/cnvs/canvas/issues/490
• https://github.com/cnvs/canvas/issues/604

... I'm going to go ahead and work on a solution. My thought right now is that I'd add an optional config variable where you can specify the path of your frontend. If that exists, then Canvas can use that to add links to various parts of the navigation or posts. I'll tag this when I push the feature.

[albertoelias123]

Another, perhaps simpler approach is to allow resources to be published (optionally) or at least views, so we could customize other aspects as well.

[austintoddj]

The problem with publishing views is that an upgrade path becomes very un-wieldy. If someone were to customize the views, any future upgrades would be difficult since it would mean overwriting much of the customization.

[joveice]

I would love to edit the assets to make it fit more into the main site. Even if that would make upgrading harder, since it was my decision I don't see that as a problem.

[ediblemanager]

Publishable assets gets my vote: anyone who wants to edit will be doing so knowing they are moving from the core and surely will expect upgrades to be more involved.

[austintoddj]

That sounds reasonable enough.

That being said, I'm not actually aware of any packages that do this. Supporting the base installation, (ie. assets being read from the vendor directory) as well as a customizable app experience seems problematic, since you'd have the freedom to write/compile the assets and those would, theoretically, _not_ compile into the vendor directory.

How do you propose supporting both those scenarios?

[ediblemanager]

Isn't the normal practice for the package to firstly use it's own assets, stored within vendor, then use any published assets if the command has been run?

Would another option be to allow for specifying options in settings for each visual component that can be edited? Not that you'd want to give every component over, but perhaps the main ones (nav, body, footer)? Couple this with being able to publish the "vanilla" versions you provide and it becomes pretty powerful (though with the same restriction I mentioned earlier of upgrades being more involved).

Caveat: I've never developed a package, so might be missing something fundamental here.

[austintoddj]

From what I understand in the docs, that logic pertains to the blade files. You _are_ able to override package views, however the only "view" for Canvas is a layout file, and it's simply a wrapper for the Vue SPA.

I don't believe there's a way to override the packaged CSS/JS with Laravel at this time. That being said, I could be wrong and would love to have anyone inform me otherwise.

I'm not totally against the idea of customizing certain aspects or components of the app, however it'll just take some thoughtful brainstorming before pushing something like that out.

[albertoelias123]

Searching i found a possible solution... look this, [Public Assets] (https://laravel.com/docs/7.x/packages#public-assets) @austintoddj .
As i understand it, the problem would be publish the assets of package (Vue CSS/JS).
Using the service provider's publishes method is possible copy the files to "development director" and would be optional feature.
Whoever wishes this, run the command php artisan vendor:publish --tag=canvasVue. When package update, the developer run the same command with the parameter --force to overwrite the assets and then just modify again according your need.

I would be happy to implement this feature, for now I will update my fork and test this.

Another future possibility that I thought was just as you separated part of the package with Studio, we can do the same with the Front-end of the internal part. I thought of a structure similar to:

• cnvs / canvas (Back-end) -> Laravel files
• cnvs / studio (Front-end Public) -> Vue files, from the viewing side, as is already done
• cnvs / editor (Front-end Private) -> Vue files, from the internal area

We can also allow the developer to publish the assets of any of the packages and modify them.
This also allows for a future implementation of Themes for Canvas (A developer can make his modified package available from the "studio" or "editor"), for that it would be enough to use these packages as a standard to be followed.

P.S.: I'm Brazilian, sorry for grammatical errors

[baradhili]

alternatively could we have a config item to set the name of the layout blade? That way we should be able to at least fit it into a page framework keeping our own navbar etc...

[austintoddj]

Closing since the original question has been answered.