I have created a project using plugin skeleton.
Now how can I have a theme working simultaneously with the plugin?
I can create a theme bundle or add view under app
Sylius documentation says -
loading order (priority descending):
App templates:
<Theme>/views (NEW!)
app/Resources/views
Bundle templates:
<Theme>/<Bundle name>/views (NEW!)
app/Resources/<Bundle name>/views
<Bundle>/Resources/views
I can have a theme bundle registered and work simultaneously with plugin in tests/app/AppKernel.php
It depends a bit on your use-case. I'll try to identify some.
1. Sharing plugin with others
In case you want to share your plugin/bundle with others (open source e.g.), it would be best to have the plugin specific views inside your plugin. It allows other developers to override them inside their own theme or inside their app/Resources folder. In case they just like the views, they don't have to do anything besides loading the plugin.
2. Sharing views with other projects
Let's say you want to use your plugin in several own projects, but it might be that some views need to be adjusted. You will still put the default views inside the plugin as mentioned above, but if some need slight adjustments in that project or in some projects, you override them inside that theme. A theme can also be loaded from a repository, therefore making it possible for you to open-source the theme or use it internally in multiple projects.
3. No sharing
In this case I think it's up to your own preference where you place them. Myself I would still save them with the plugin and override them in a theme. In case my very specific app still needs to behave differently, the app/Resources is a last resort. Placing views inside the plugin or inside the theme will allow you to (in case you place them inside a repository) easily also loading them in another project. Besides that, you share responsibilities by grouping functionality together.
Recap
Basically it depends on your needs, but in case you want to share your plugin and/or theme with others, definitely place the files inside the plugin first, and any adjustments inside the theme.
Is it only for internal use? In that case it's up to your preference, but I would still keep in mind maintainability and reusability, therefore placing them together with the part that introduced the accompanying functionality.
Related
I downloaded a free wordpress template, after customized it and use it , I want to purchase a premium template the same as i used for free. My question is, the free template and it's content will remain or I should start to customize the new template.
You shouldn't customize the theme's files at all, because you will run into this exact problem: every upgrade means you have to re-do the customization.
Instead, build a child theme, and make your child theme only overwrite the minimum required. This way, you will benefit from updates (especially security updates) of the parent theme, and will have very little work to do after upgrade, while you're still able to customize the code where needed.
If possible, use hooks, filters, and css, and you will have even less work even after major updates.
I have an application build with Symfony 3.3 and Twig that will be distributed to more customers. I'm using parameters.yml to customize its behavior and it seems to work well.
Where I have an issue is with twig templates: although the customers will use most of the templates as they are, they'll need to customize some parts like CSS styles, general layout and do occasional design overrides.
The options I have identified are:
Have a full set of templates for each customer. The issue is that the upgrades will be a nightmare as we have to patch each template and account for differences
Customize templates via YML files. The problem is that it gets too complicated soon and the number of parameters is potentially huge
Deliver a set of templates in app/Resources/views and allow the customer to override any of the templates by creating another file with the same name in another folder
Deliver a set of templates in AppBundle/Resources/views and let customers override them in app/Resources/views
Create the application as a Symfony bundle (ie. MyAppBundle) and deploy the application to each customer by including the MyAppBundle via composer. I like this solution a lot, but I do not know whether it is possible to implement is easily.
Do you have any suggestion on how to approach this problem?
I think the best way in your case is to think about the main parts and the customer parts and then build blocks and overwrite all parts that are relevant for the customer for example the CSS or anything else. If you know that there are special part you can build macros for example.
With the Block concept you can predefine the template but the customer has the ability to overwrite that part you've defined with it's own.
With Twig you have a lot of possibilities to solve such a problem.
Drupal 8 use that Theming concept.
https://www.chapterthree.com/blog/twig-concepts-drupal-8-themes-part-ii
Perhaps you can take a look how they have solved that and you can find a good solution for your problem.
I have a client who has asked me to develop a WordPress theme based on an existing one. My first thought was to create a child theme, but - his clients will need to have custom themes based on the one he's asking me for.
I know "grandchild themes" are a bad practice - I don't like them, either. I can create a new parent theme based on the original theme, and then, he'll have child themes of this to be released to his clients.
In order to let the final users easily upgrade their child themes, would it be appropriate to make a branch of the existing theme using Subversion? I'm not very familiar with version control, so I'm not sure if this is the best choice. What I need is to have every theme up to date whenever the one it relies on releases a new version.
None of these themes will be listed at WordPress.org, I think.
Sorry for my bad English.
Thanks a lot.
AFAICS, you want to implement vendor branches. Using vendor branches allows you to keep your child themes synced with parents.
I have never developed Wordpress website from scratch or from default template or from parent theme or from starter theme. I mean, I have maintained already created WP websites.
However, now I want to try to create WP from the beginning. I have mock up of website that is something liek booklet, this means, that it has many pages (about 40) and all pages differes with content - some has images, some has additional graphics, some has text etc. Website consists mainly of static pages with different layout.
What are your suggestions for newby... Previosly i have read much about underscore and thematic and I like both. Are tehre suitable for my purpsoes?
I always use undersores.me as a starter theme for the following reasons:
I don't have to dig trough the parent theme documentation for hooks and filters
It is not bloated with unnecessary functions
Download package is customized with your theme name and slug, meaning that functions have appropriate prefixes/names
Here's the situation: There's a WordPress plugin in place that enables a mobile-friendly theme if a mobile User Agent is found (with the usual details and logic, not important).
This mobile theme is copied from the plugin directory, into another, and overwritten when updates to the plugin come out.
I need to provide some extra custom functions for the theme, but don't want to put all of the code directly in the mobile plugin/theme, because it may get overwritten.
I think the best thing might be to put my special/custom functions into their own plugin, and deal with the theme-specific changes as they come up - that way there's less to diff/compare when updates come out.
What do you think is the best approach with something like this? Is there a safe alternative to creating my own plugin, where I can store some custom code?
You could make a wordpress child theme, so that if the parent theme gets updated all your changes remain intact. From the above link:
...the functions.php of a child theme does not override its counterpart from the parent. Instead, it is loaded in addition to the parent’s functions.php. (Specifically, it is loaded right before the parent’s file.)
That should allow you to do what you need to do.