OrchardCMS / OrchardCore

Orchard Core is an open-source modular and multi-tenant application framework built with ASP.NET Core, and a content management system (CMS) built on top of that framework.
https://orchardcore.net
BSD 3-Clause "New" or "Revised" License
7.41k stars 2.39k forks source link

Edit theme in admin area #3012

Closed khoshroomahdi closed 6 months ago

khoshroomahdi commented 5 years ago

Is it possible to view and edit theme files in admin area?

Skrypt commented 5 years ago

You can duplicate the current admin theme, change it's name, and set it as your default. It will give you the ability to create your own views for each of your dynamic content types in the admin. Though, if you want to override Orchard modules views and styles you will need to create a module that reference the module you want to extend. I'm not sure, since I've not been able to achieve this, but in 01 you could override all the modules views also inside your custom admin theme. That last option is something I asked @jtkech in an other issue but I don't think you can do that anymore since modules are now using "areas", unless I'm wrong.

sebastienros commented 5 years ago

The solution we have in mind is to be able to provide a theme in the App_data's tenant folder, and let you edit liquid files. Maybe this could be a complete file editor for each tenant, that would allow to upload other files. The files of a theme are immutable because they are embedded in the theme assembly.

You can already change the existing templates using the Templates module.

TFleury commented 4 years ago

This feature must also allow to edit/upload css, js, images, fonts...

sebastienros commented 4 years ago

I think we should reuse the Media/Assets page to upload css/js, as this will handle whatever storage provider is configured, so it will work on multiple nodes too. Maybe provide a custom internal folder like it's done for Attached Media such that we can provide custom permissions.

TFleury commented 4 years ago

This requires allowing css/js/fonts file extensions that are not (by default) in the media module. It could be a security issue.

If we use the Media module, theme files and medias storage strategy will be bound. But they are different concerns.

sebastienros commented 4 years ago

Maybe same storage provider as media, but a different folder and with a different static file provider

TFleury commented 4 years ago

I think more about a per-tenant theme files store in which you can have client side assets (css, js, ...) and templates (liquid only). So it could be easy to clone a theme (just copy all files), or deploy with a zip file.

It could be used by conventional themes (i.e.: You can change the primary color setting and it rebuilds the css based on it).

Skrypt commented 4 years ago

Just like Shopify does. You can only modify Liquid files inside a "tenant". So, you pick-up a theme in their library to install it and then you can download a package of all the assets contained in that theme which includes liquid and css and some image files. But most of the time afterward you will customize that base theme with assets contained in your tenant media library. You can modify the liquid templates locally or directly in Shopify. But it won't alter the base theme if you want to keep your customizations you need to download the Theme to do a backup.

sebastienros commented 4 years ago

We can already change shape templates in the admin. We only need to be able to add custom static assets. We can add another page like we do with Assets, but in a specific folder of the media storage (_assets) so it will reuse all the existing stores (azure, local) and support caching.

TFleury commented 4 years ago

I also found 'Tenants.FileProvider' feature that can also be an option to store static assets. It just needs an Azure implementation.

deanmarcussen commented 4 years ago

Would recommend implementing as part of the media storage, in a seperate folder _assets as suggested.

The tenants file provider feature only provides files through the static file middleware, which does not support async, as it uses the aspnetcore IFileProvider interface, which is a light wrapper around local file storage.

For azure we need to be able to support an async IFileStore implementation, and handle caching locally, so the static middleware can be responsible for serving the file, all of which is done already with the media module.

Issues around accepted file types, can easily be handled, with a seperate array for accepted static files, and it is not crucial that the media resolver middleware, have any restrictions on these, it was just a feature added at the time. The media app isn't aware of the accepted files array either, it is just handled in the Controller. So could easily be adapted to use a different array for a different path.