Skip to content
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

Load custom "sprinkles.json" file #813

Closed
mgpro94 opened this issue Nov 8, 2017 · 11 comments
Closed

Load custom "sprinkles.json" file #813

mgpro94 opened this issue Nov 8, 2017 · 11 comments
Labels
architecture Related to the framework architecture needs discussion A decision needs to be taken by the dev team
Milestone

Comments

@mgpro94
Copy link

mgpro94 commented Nov 8, 2017

@alexweissman
Follow the conversation here: https://forums.userfrosting.com/t/can-i-load-different-sprinkle-for-each-domain/97

we agreed to add a way to load custom "sprinkles.json"..

as i suggested:

file: public/index.php

switch($_S ERVER[‘HTTP_HOST’]) {
      case “domain_1.com”:        $sprinkles_file = “sprinkles_domain1.json”;       break;
      case “domain_2.com”:        $sprinkles_file = “sprinkles_domain2.json”;       break;
      default:                    $sprinkles_file = “sprinkles.json”;               break;
}

$uf = new UserFrosting($sprinkles_file);

file: app/system/UserFrosting.php

class UserFrosting
{
      private $sprinkles_file;

      public function __construct($sprinkles_file = "sprinkles.json")
      {
            $this->sprinkles_file = $sprinkles_file;
            /* old code */
      }

      public function setupSprinkles($isWeb = true)
      {
            /* old code */

            $schemaPath = \UserFrosting\APP_DIR . $this->sprinkles_file;

            /* old code */
      }
}
@Silic0nS0ldier
Copy link
Member

An interesting scenario. Would require more than just conditional loading of sprinkles.json though. At least if this functionality is to land in UF in any reliable fashion.

Off the top of my head, for this to be done we need:

  1. A way for PHP and JS to know the possible sprinkle configurations.
  2. Each configuration to have its assets built, and placed in some folder inside public.
  3. The generated asset URLs need to consider the extra folder.

@alexweissman
Copy link
Member

I think, at the very least, we should remove the hardcoded sprinkles.json string and make it a constant defined in defines.php.

@alexweissman alexweissman added this to the v4.1.14 milestone Dec 5, 2017
@lcharette
Copy link
Member

+1

The constants can be overwritten by sprinkle defined one? But then I guess it would be loaded after that info is require. Or maybe it could it be overwrittable by the env settings?

@alexweissman
Copy link
Member

Nothing that fancy. People who need to change the default sprinkles.json will likely be manually instantiating UserFrosting anyway. So, we just need to factor the default name as a constant, and add a UserFrosting::setSprinkleSchemaFile method, or something like that.

Could even use loaders to support JSON or YAML.

@lcharette
Copy link
Member

It could also be changed using Bakery somehow...

@mgpro94
Copy link
Author

mgpro94 commented Dec 6, 2017

i think to give the option to change the default definition by UserFrosting::setSprinkleSchemaFile method would be the best

if you defined this by env settings or bakery this would be the same as static file name
you should be able to change the file in run time

@lcharette
Copy link
Member

Problem is if you have to edit app/system/UserFrosting.php, you are editing core code, which is bad. And we can't have it in a sprinkle, since it needs to be done before the sprinkles are actually loaded.

Nevertheless, your issue is different than the fact the sprinkle file is hardcoded. Having a different set of sprinkle depending of the domain is nonsense for me. If there's really a difference between the two domains, it should be handled inside a sprinkle. Even better, I would go for two different install, one for each domain, even if they have to share the same db. What is the reason you need to load a different sprinkle based on the domain name?

@mgpro94
Copy link
Author

mgpro94 commented Dec 6, 2017

i made two base sprinkles of my system (one is template and another is functionality)
each domain has a different land page but with the same functions and management..
only differences is settings and minor changes on template

when this will scale up with more domain.. this will be hard for me to update every host..

if i can manage with sprinkles will be loaded by domain (or any other way) in the index.php file
(and this is before the sprinkles loaded)
this will be much more easier for me

I dont see why my example (in the post) is wrong or not good ?

@alexweissman
Copy link
Member

I actually did originally envision a multi-tenant situation (what @mgpro94 is describing) as one possible use case for Sprinkles. In fact, I actually designed the Sprinkle system based on some "proto-sprinkles" I was using in a multi-tenant project of my own, where each site had a separate "proto-sprinkle" in the same installation.

I ultimately ditched that approach in favor of using a common Sprinkle shared among separate installations of UF, but I don't think @mgpro94's use case is so far-fetched.

@alexweissman alexweissman added the architecture Related to the framework architecture label Dec 13, 2017
@alexweissman alexweissman removed this from the v4.1.14 milestone Dec 13, 2017
@lcharette
Copy link
Member

Actually, this could also be resolve and/or be in conflict with #747 & #728.

@lcharette lcharette added the needs discussion A decision needs to be taken by the dev team label Mar 29, 2018
@lcharette lcharette added this to the 5.0 milestone Mar 29, 2018
@lcharette
Copy link
Member

This is now possible with UF5. Simply create two Recipe, and load the correct one in index/bakery.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
architecture Related to the framework architecture needs discussion A decision needs to be taken by the dev team
Projects
None yet
Development

No branches or pull requests

4 participants