Laravel Multiple Sites - php

I need to set up two sites running from the same codebase in Laravel 4.2, I have done this before but I need some slightly different requirements this time.
Some of the assets CSS, JS and images would be the same but some would need to be overridden, I am happy to just have two public folders, with all front end assets duplicated, but if there are other suggestions that could make it easier that would be great.
My other requirement is that I would like to add a new PSR include route for site 2 that could override classes from site 1, when necessary. So I could call class user as below, site 1 would call the first class, site 2 would call the second class.
app/models/user.php
app/models/site-2/user.php

Well, you could set up both domains to use same Laravel project directory and then you could create middleware which would check for current domain name:
$currentDomain = $_SERVER['SERVER_NAME'];
Then you may just check for domain and decide what routes, controllers, models, views to use right now. I think this approach will solve you needs.

Related

Different folder for views - Laravel 5.4

I'm trying to make a reusable Dashboard for my apps, so I decided to put everything in a folder like app/Dashboard. I've managed to have routes, controller, middlewares, etc. But, now I'd like to have views also in that folder. I added the path in config/view.php, the problem with that is that if I have two views with the same name in app/Dashboard/Views and in the default resources/views, of course the view in the default path would be loaded.
Do you have a better idea? Can I do something like return view('dashboard:login') in my controller using only the Laravel standard tools?
Look at this part of the documentation https://laravel.com/docs/5.5/packages#views. You are almost right, but you need to use two colons
return view('dashboard::login');

Display all current URL's in yii project

I have inherited a PHP YII project and I'm trying to figure out what it has and does. I was wondering if it's possible to display all URLs that the project routes to.
Examples would be
index.php
<controller.php>/index
<controller.php>/search
<controller.php>/add
For all controllers and all views.
You must look to configs of UrlManager/rules. Here describes all rules for process requests. Than you will know what controllers and modules (even their actions) are using. Another way I don't know

What's The Proper Way To Set The Public HTML Folder Using Yii Boilerplate?

I can't find the documentation specifying how to set the public html directory. I am trying to keep all other files and folders in the site root. Since there is a frontend and backend public html folder, I don't see how this is possible.
My Site:
/site/perl/
/site/www/ <-How do you get just the 2 public folders here?
/site/.ssh
Yii Boilerplate:
runpostdeploy
yiic
/backend/
- /config
- /www/index.php
/frontend/
- /config
- /www/index.php
/common/
/console/
/tests/
Is the whole boilerplate project supposed to reside in the sites public html folder? I thought it was bad practice to do this.
*** U P D A T E ***
Spent most the day trying to figure out this problem. The closest thing I was able to find, was a comment on one of the Yii Framwork forum posts. For now, I'm running Boilerplate with subdomains like they recommend in this comment.
http://www.yiiframework.com/wiki/155/the-directory-structure-of-the-yii-project-site/#c9444
I'm not sure if this is the correct way. But it works.
You should set your site public director to frontend/www/. The idea behind Yii Boilerplate backend/www is to have separate domain for admin options (if needed), instead of having separate module. This way you'd be able to easily have separate CWebUser, Yii::app() etc. By the docs:
backend: the backend application which will be mainly used by site administrators to manage the whole system (avoiding admin modules at frontend application to avoid confusion)
I believe if you have two application, then you need two address.
You can do with sub-dir like this:
www.site-name.com -> ../frontend/www/index.php
www.site-name.com/admin -> ../backend/www/index.php
Or you can use subdomain like this:
www.site-name.com -> ../frontend/www/index.php
admin.site-name.com -> ../backend/www/index.php
It's like Wordpress, if you need enter admin page, you access through address www.site-name.com/wp-admin
But, be sure you don't use the 'admin' path in your frontend if you use this alias to backend.
Spent most the day trying to figure out this problem. The closest thing I was able to find, was a comment on one of the Yii Framwork forum posts. For now, I'm running Boilerplate with subdomains like they recommend in this comment.
http://www.yiiframework.com/wiki/155/the-directory-structure-of-the-yii-project-site/#c9444
I'm not sure if this is the correct way. But it works.

Advice on creating codeigniter app to serve custom microsites

I'm building a codeigniter application that will serve custom microsites. Essentially each microsite will be a collection of seven different views all loaded by a single controller's methods. To 'Theme' each microsite there will be different folders containing different versions of these view files (and their associated css, js and image files) and the controller will know which folder of views to load based on information stored in the database for each microsite record.
The problem with this approach is when a single microsite needs to have a custom page that is unique from all the other microsites. Since they're all controlled by one controller, we run into the limitation that either all the microsites need to support this page.
To futher explain what I'm referring to imagine these urls:
http://www.fakewebsite.com/index.php/microsite/index/david_site
http://www.fakewebsite.com/index.php/microsite/index/frank_site
In both of these links the controller is 'microsite' and the method is 'index'
'index' knows what template to return based off it's first argument which is either 'david_site' or 'frank_site' in the above example.
I can't say if this is possible with Codeigniter, but I assume so:
So what's now your problem? That you have too much code in the controllers? Move code from the controllers into the models. Then the code is more re-useable and you can have small controllers on each microsite with fat models that are shared anyway.
Sounds not really good so far, right? Still there's one controller per each site. Well, make each microsite's controller extend from a base controller. So all code's still in one place but for some controller methods they can extend that base controller on a per-site basis.
So the front-end controller then will provide the right controller class per site as it does for the themes - if I understood your question right.
Can you have a default "theme" for that controller, which would accommodate most of your microsites, and then if you need to create custom themes on top you can change it?
So like this
http://www.fakewebsite.com/microsite/david_site/ <-- default theme
http://www.fakewebsite.com/microsite/frank_site/ <-- default theme
http://www.fakewebsite.com/microsite/john_site/customtheme/ <-- custom theme
As I understand the question, you're asking how to load a different view file for only specific "microsites", but you're using the same controller and codebase for all of them.
In your views directory, have 1 directory for default themes, and and then for each "microsite" you want to do something custom with, create another directory which will contain the unique files, then when loading files - check if the unique exists first.
Hasty example that assumes default files are in the root of views/:
// I assume we know which site we're loading
$theme = 'david_site';
// Whatever the current view's name should be
$view = 'page3';
// Path to our custom file if it exists
$custom = APPPATH.'views/'.$theme.'/'.$view;
// Does a custom view exist?
if (file_exists($custom))
{
$view_file = $theme.'/'.$view;
}
else
{
// Use the default
$view_file = $view;
}
$this->load->view($view_file);
As far as I know, there's nothing like view_file_exists() in CI, so we're just using plain old file_exists() with the full path.
It would be worth writing a function for this of course, but hopefully this helps. You could even apply it to loading libraries, models, etc. - or even extend the Loader class to do it automatically (probably overkill).
CI2 already has a version of this feature in the ENVIRONMENT constant, although this usage is not its intention - but that is basically what it does.

kohana v3: using different templates for different subdomains

I have a kohana v3 app. 2 subdomains pointing to this app. what I have to setup that kohana uses a different template if the app called with subdomain2.example.com?
at the moment all calls (from subdomain1 and subdomain2) use the standard template: 'templates/default'
thank you!
daniel
First, get the subdomain name from $_SERVER['SERVER_NAME']:
list($subdomain) = explode('.', $_SERVER['SERVER_NAME'], 2);
Then choose what template to use based on the subdomain:
// Replace this with a switch() statement if you want to choose another way
$this->template = 'templates/'.$subdomain;
The above code should be placed in the Controller::before() method before you call parent::before(). This assumes that you are using the Controller_Template or an extension of it.
may anybody can help me: kohana v3: using different templates for different subdomains
danzzz, there are a few ways... (i dont have time to go into detail.. so i'll give a quick go here..) .. A) use URL rewriting to map bla.site.com to site.com/bla (and www.bla.com+bla.com to bla.com/www) ... use that first param as the trigger... then load a different module at the top of the stack so it can override anything from a lower module - this assumes anything that is overridable is kept in a module, otherwise, you can use it as a trigger any
where in the code...
and B) is really the same thing, but using that param as the view name or similar...
whenever i have something like that, i tend to leave my application folder empty, and have an application module near the top of the module stack.. that way, i can load a "skin" module higher up and have the cascading FS do all the hard work...
keep in mind that "skin" modules etc will need a strict set of rules and interfaces, if you make a change to the app, you need to know all the skins still work...

Categories