New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question : View component (Craft 3.4.0) #6015
Comments
I know you said you looked into template roots, but I do think would be a good solution here. You could register one single template root called |
Thanks, I thought that too, and tried it :
Which throws an error (View.php on line 887), the path now being an array. And also it means I can't override any given system template with this. Could be useful to have a theme to override some of the back end/plugins templates. Actually I think all this could be resolved if we could specificy an empty key pointing to an array for the roots templates, something like that :
Would you be open to that ? I can look into it if you think it has a chance of making it to the code base. Or would that be too big of a change ? |
Good points. I just made the following changes for 3.5:
(In other words, made your example possible.) Craft 3.5 is currently in Beta. To update to it now, change your |
Wonderful, thanks |
@brandonkelly |
@piotrpog No, because Craft’s own template path will be matched before it looks at custom template roots. |
Hiya,
I'm a beginner at Craft and I'm giving it a good go to see if it would fit my work's needs.
So far it's been fantastic, thanks for all the efforts, really easy to get into it, seems to be spot on for us.
One thing I struggled with is to modify the template engine. Use case : I want to create a plugin that allows me to have different themes and switch from one to the other in the back end according to some rules (one rule could be a different site, or it could be per page, per type of browser (mobile, tablet) etc ...)
Theming would be a way for me to have inheritance between views and packaging, which at the end of the day makes development faster.
I tried the template root way and quickly realised it can't work, somehow every folder must be keyed with a subfolder, I want the view engine to look in a new folder entirely.
I want to do exactly what's done in the View class when considering different sites (method
_resolveTemplateInternal
), just I want that folder to be configurable, not hard coded with the site's handle.So I tried extending the View class and replaced it in the config (I'm not sure how to do that with a plugin yet), and I made it work, but only after changing all private functions/attributes of the View class to protected so I could extend them. Which is dirty, but I just wanted to see if it could work.
So I was wondering if those private functions/attributes were private on purpose, do you not want them changed ? Or am I looking at the problem in a wrong way ?
Or instead giving us more entry points with events during the template paths resolving process ?
Or allowing whole new folders in the template root variables ?
Or any other suggestions ?
Thanks for your time
The text was updated successfully, but these errors were encountered: