This appears to be the scariest topic relating to Symfony2, as after a week of searching and testing, I am still unable to find an answer to this.
In short, I am building an application that will have several subdomains, and I would like a different configuraton for all of them, while sharing multiple bundles from /src, and more importantly, import central config and routes (As well as each app's own)
I went down the road of creating individual /app directories, AppKernal.php files and bootstrap files. The main issue with this is detailed in another question, which has recieved no answers (not that I blame anyone TBH :D).
Symfony2 multiple config and routing files for subdomain routing
I have found discussion on the matter, Fabian even takes part in this:
https://groups.google.com/forum/?fromgroups=#!topic/symfony-devs/yneojUuFiqw
And this discussion on a PR to github to provide support in version 2.2 (still 6mo away I hear)
https://github.com/symfony/symfony/pull/3378
Is there anyone out there who has done this before? Is the process easy enough to explain? Is there any information available to assist with this?
I'm pretty much at the stage where it appears this simply is not possible. Which I find really strange for a system as touted as Symfony, especially when it appears Symfony1.4 did this rather easily.
Update
Thanks for your responses. The challenge is, there is a hierarchy of configs. These configs in turn import their own routing.yml files.
For instance: the domain http://testing.api.mydomain.com would include the following configs:
config_api.yml -> config_testing.yml -> config_dev.yml -> config.yml
All import their own routing.yml file. But only the one in config_api.yml is loaded. It seems framework: router: config option overrides previous usages in other config files, rather than extends.
In all fairness, the location of the app code is inconsequential. Having a hierarchical configuration with hierarchical routes seems to be the gotacha.
Cheers
Multiple applications projects can be achieved by splitting your code in multiple Kernels.
You can then benefit:
multiple web roots (useful for differents domains)
shared & specific config (via imports)
clean separation of Bundles...
I have described the whole process here: http://jolicode.com/blog/multiple-applications-with-symfony2 and you can find an example distribution here: https://github.com/damienalexandre/symfony-standard
Sorry for necroing...
I just want to say that I have looked into multiple application structure for Symfony2 as well. Since version 2.4, when routing supported hostname based routing, there has been no need for multiple apps.
All you now need to do is separate your "apps" into different bundles, say AcmeSiteBundle and AcmeApiBundle, then in app/config/routing.yml:
acme_site:
host: "www.{domain}"
resource: "#AcmeSiteBundle/Resources/config/routing.yml"
prefix: /
defaults:
domain: "%domain%"
requirements:
domain: "%domain%"
acme_api:
host: "api.{domain}"
resource: "#AcmeApiBundle/Resources/config/routing.yml"
prefix: /
defaults:
domain: "%domain%"
requirements:
domain: "%domain%"
Remember to have domain parameter set in app/config/parameters.yml
parameters:
.....
domain: example.com
You can create different configuration using the testing/Dev example :
Step 1
Create as many web/app.php file as you have subdomain.
web/app_subdomainx.php
Step 2
In each app_subdomain_X.php file change configuration :
$kernel = new AppKernel('subdomainx', false);
Step 3
create configuration file matching your environment
config_subdomainx.yml
security_subdomainx.yml
Step 4
acces you specific domain through
/web/app_subdomainx.php
PS :
Keep config.yml for common configuration (like db connection) and include config.yml into config_subdomainx.yml
imports:
- { resource: config.yml }
you can try to find something on github. I've found the following Bundle which should do this. Imikay RouterBundle
Basically Fabien is right, there's no reason to have more than one application, if you really have a need for a different application it's probably a different project. Bundles and libraries can be easily shared like any other bundle you see on the web.
Then you can have the small part of the set up belonging to each thing you call "app" in the app part of each project.
If they share the entirety of the code then it's just a matter of configuration hierarchy for each sub-domain, which could be your case considering you want to share some part of the config.
Symfony has many ways of allowing you to reutilise code which are very nice, but the framework is not meant to have many applications, if you want to try to hack it, go ahead, but then you're not using the framework anymore. And that's why you can't find examples, not because it's scary, it'd not be that hard to modify, it'd just be ugly, IMO.
Maybe you can try this bundle, that handle multiple domain website on same app and database:
https://github.com/AppVentus/MultiDomainBundle.
Related
I'm starting to develop a project that will be quite big (hear lots of files) and I want to have an organization that's different from Symfony's default one: instead of having one dir for all my controllers, another for all my forms, etc, I want to have one dir per functionality, ie a directory for my homepage which will contain the controller, the templates, another dir for the blog page with the controller, forms and templates, and so on.
I tried what was explained in this (old) answer, and it didn't work : my routes weren't recognized, and a php bin/console debug:router showed they weren't listed anymore.
I feel I will have something to adapt in my routes.yaml file, which looks like this for now, and which explains why it doesn't work because it explicitely searches in the src\Controller directory:
controllers:
resource:
path: ../src/Controller/
namespace: App\Controller
type: attribute
I looked in the documentation I found, but I didn't find anything useful (I think I will have to remove the path and change it to something else, but I don't know what yet.
The above solutions are only for differentiating controller and template files. But For Entity, Events, and Forms it will not work.
It seems like you want to separate files for each module or functionality. For example, settings.yaml, controller, entity, forms, events, etc...
For that Symfony provides a Bundle feature. You can create a new Bundle in Symfony and use it as a separate feature. For more details please read this link
I usually see resource: contain a file path, but here I have a multiline string with yaml instead:
shop_admin_taxon:
resource: |
alias: sylius.taxon
section: shop
templates: AdminBundle:Taxon/Crud
except: ['show', 'index']
redirect: update
grid: shop_admin_taxon
type: sylius.resource
prefix: /
I didn't get any error messagaes about this code when it worked on Symfony 3.2.7 in another project. But now Symfony 3.4 gives me the following error when trying to read this configuration:
The file "alias: sylius.taxon section: shop templates: AdminBundle:Taxon" does not exist.
That's actually expected (since as far as I know you pass a resource locator to resource: and not the actual resource configuration), but why did it work?
Symfony is complex beast and allows a lot of tinkering with it's internals. The routing component is no exception of this and you can see usages which modify or even dynamically create routes on the fly.
This in particular looks like a Sylius extension to routing. If you are curious how precisely it works have a look at the relevant Symfony documentation page. The functionality is being provided by the SyliusResourceBundle with a custom loader.
With all this in mind it looks like you have a broken Sylius install as the custom routing loader is not working. It could be some version mismatch introduced by composer update (e.g. remove component A due to incompatibility with newer version of component B), or bundles not being enabled, or something similar. Make sure all Sylius bundles are installed and enabled
Let's say I have created a news portal bundle "NewsBundle" with articles, tags, events, lots of relations, quite huge and complex.
Now I want to copy this numerous times and create a Fashion News Portal, Car News Portal, Dog News portal and so on each available though an own domain. The portals differ only in templates, translations and assets. As I want to implement complex reporting, I want all the stuff in a single database and would flag all entities with the respective portal.
My question: How so I organize the code?
First I figured out, I could use routing to have the same application but different bundles for each domain.
Then I found out, that I could extend my master bundle. But it seems as this works only once.
As I did all the routing with annotations, it look like it does not work to inherit the routes from the master?
One of the hardest questions is where to put the portal switch. Somewhere I need to set a variable that tells whether its the fashion or dogs portal, so I can filter the content in all repositories accordingly.
I did that in the app.php which is for sure worst practise.
In the end I want to be able to roll out new portals easily without duplicate code.
Any ideas are much appreciated.
Greetings from Hamburg,
Boris
You need to keep your NewsBundle in your application, and to have a number of bundles revolving around it, one for each portal you intend to create.
There is no real need for bundle inheritance here. Your portal bundles depends on the NewsBundle but don't inherit from it.
Routing configuration, templating, and other behaviours related to a specific portal should go in the related bundle. There is a Resources folder in each bundle ; this is where you will need to put specific routing, translation, configuration and templates.
app/config/routing.yml is the central routing conf file where you will need to reference all other routing.yml file.
As for the switch, well, I can't answer that in detail but I think it should be set up in your server application apache or nginx (or other...).
Your problem can be solved via different environments. Each of your portal is a different environment. You can set up your web server to point different front-controllers depending on the domain requested.
Example:
For domain news.domain.com your front-controller would be web/app_news.php. And it will contain line:
$kernel = new AppKernel('news', false);
It will automatically load config from app/config/config_news.yml. In that config you can specify all specific parameters for your portal. You need then just implement your special loader for resources like translations that will load resources from the path specified in config_news.yml.
I don't understand the difference between these two ways of setting global constants in Symfony2. Is it only about being able to set default values and types in config.yml (+configuration.php) ?
parameters.yml file is the place for all constants that are environment dependent. If you use composer to deploy your app it will ask you about their values. You can also define paramteters.yml.dist to provide some defaults values. If you use parameters.yml you have all parameters needed to setup an application (for example on production server) in one place.
Nope, nope, nope.
parameters.yml is for passwords and server specific parameters such as database connection information.
The main difference between config.yml (and all the other config files) and parameters.yml is that parameters.yml should never be checked in to your source control system. Doing so will expose your passwords and other private information to whomever has access to your source code.
It is the way to separate some independent data in files. You can put in your config.yml all the data located in another config-files (parameters.yml, routing.yml, security.yml and so on). But it will be hard to maintain the whole project even if you are the single developer on the project.
All config data should be splitted according to their domain. Settings for email - in email-settings file, settings for integrating payment system - in payment-settings file, services - in services-config file.
If you have some personal information in the config files you can add this file to .gitignore and define some default values to the your_config.yml.dist. Then you can set up your composer to run some script to fill your_config.yml file like it has been made in symfony standard edition.
I have regrouped the following information from a few examples in the SonataAdminBundle documentation. Please correct me if there are some errors, but here is what I get in the case of a BlogBundle:
As you can see, in general, each bundle contains both frontend and backend classes.
It seems very messy to mix both frontend and backend in the same folders somtetimes (see Controllers), but to be honest I can't think of an other way...
I actually started handling backend in a separate bundle but then realised that it was also too messy.
So in practice, do people really follow this architecture? Is this the only/best way to handle backend when using SonataAdminBundle?
This beautiful post here is using a different approach...any ideas what I should do to make sure the code doesn't get too messy.
Simple: use folders within locations of mixed content. I put frontend components directly in their respective folders, and add Admin folders for backend files.
You can refer to e.g. a controller in the Admin subfolder like this BlogBundle:Admin\Concert:index, essentially the same works for templates.
On configuration, you could create a config-frontend.yml and a config-backend.yml file, then include it in the original config.yml file. I don't do that though.