I'm attempting to create a multisite in Laravel, so one codebase but with several sites operating from it. Each site will have similar functionality, so can reuse code, but each site will use a different theme - which I imagine would be as simple as having different themes in the views folder and mapping them depending on the domain that the customer has come through.
I want to be able to access Site X from www.sitex.com, Site Y from www.sitey.com etc, while having only one laravel install and not resorting to any vhosts tomfoolery.
Would any of you be so kind as to advise me on a solution, or to point me in the right direction? I've had next to no luck finding anything so far!
Thanks
If your routing is not going to be too complex you could potentially get away with having numerous public folders
laravel
app
bootstrap
sitex.com
sitey.com
vendor
Then each of your site will be it's own virtualhost with no funky alias rules like so (for security, make sure there is no access to the laravel root dir):
DocumentRoot "/var/www/laravel/sitex.com"
Lastly, you would put a variable in bootstrap/paths.php where the public path will be
'public' => __DIR__.'/../'.preg_match('/\w+.com/',$_SERVER['SERVER_NAME']),
This should work for the majority of deployments even with subdomain routing because bootstrap gets initiated from the index.php file in each of the public folders. If you want to use artisan to load up the built in php server, you will need to provide --host or it will not work. There will be a few limitations on this set up that I have encountered so if someone else knows of a better way I would love to learn how myself.
Related
Essentially, I'm looking to have a PHP development workflow that needs to be modular, but using a Single Page Application technology.
I understand it is recommended to separate the back-end from the front-end. Develop them separately. But is there a way to group all related code into one module (or folder), meaning all backend code with its own views presentation inside the same folder?
It's like MVC, but the "V" contains fragments of vuejs (or angular) files, which extends from a master file somewhere in your project.
For example
Assume we are building a modular CMS, where you can upload "plugins" (really, PHP modules), extending the CMS' functionality:
-project[root-folder]
----core[folder] # contains all infrastracture code, api routes, master view file, magic, etc.
----modules[folder] # uploadable modules goes here
--------User[folder] # sample module; follows the MVC pattern
------------Controllers[folder] # contains files, e.g. UserController.php
------------Models[folder] # contains User.php
------------views[folder] # where vue components is housed
----------------users/index.php # contains vue code
----------------users/create.php # etc...
----------------users/js/user.js
----------------users/css/user.css
--------Blog[folder] # another module
----index.php # the master view or just the bootstrap file
----gulpfile.js
Then inside the core/ folder, there is a master layout that binds all views together.
Will a folder structure like this be viable?
Obvious problem there is you can't use .vue files (as that would mean, every time you upload a new module, you need to run gulp or re-compile).
Hoping for your feedback. Thanks.
This question will strike a lot of folk as bizarre and twisted. That's the reaction I got when I asked it in the context of .net mvc. I'm with you 100%.
I'm too new to js frontend development (and too ignorant of PHP) to have much advice. It's going to be tricky. Ajax calls to PHP code will need to go to paths below the src directory. But then you want to stop your frontend resources being served from these same paths. Both PHP and gulp will want to use file paths for urls, but at least for Gulp this can be controlled.
I'll follow this with interest. My ambition is to keep in the same folder things you're likely to want to delete together, and for those things to be able to call each other with short, relative paths. The ideal would be to be able to specify the module route independently of the path on disk, and to have this route work for both frontend bundled resources and services. Good luck !
I came across this question whilst searching for an approach for exactly the same problem. I'm building a "platform" rather than an application with a plugin system along the lines of Wordpress. I have the additional issue of the platform itself being a 'multitenancy' environment, too - so any plugins cannot interfere with the core "Dashboard" that holds these things together.
So; posting for a few reasons, two years on...
Did you get anywhere and would you care to share any thoughts?
I came across a quite extensive article for PHP Phalcon that has certainly given me a few ideas. Sharing incase it helps you/others:
https://blog.antsand.com/singlepost/index/5619/How-to-integrate-php-(Phalcon)-and-Vue.js-components
There's a line buried in the series that says "As a rule of thumb. Structure your code, based on the application and NOT on the programming language and frameworks." I'm not sure how wise or not this is, but it certainly gave me something to crack on with.
So right now, I have a module folder a bit like:
/mymodule
/Controller
/Model/
/Template
thing.vue
/Assets
/js
/css
MyModule.php
Assets are handled via a framework route (i.e, /assets/{path:.*} )
Templates are handled via the (PHP) module install script to make sure webpack knows where they live.
Still at proof-of-concept stage but rightly or wrongly, it seems to work well enough!
Our main website uses symfony 1, and by the time I started working on the code it seems impossible to upgrade (too much custom code from previous developer). Now we are adding a large addition to what the company offers. Instead of using a really old framework I wanted to use CodeIgniter, also since I'm very familiar with it. My real question:
What is a proper way of setting up a website to use multiple frameworks. The new features will be separate from the original website, but it will still need a few tables of the database.
I was going to have apache handle where the root directory was depending on the url and just do everything normally. The main website is example.com and the new feature will be abc.example.com
I'm really looking for people who have done this and some tips and warning they had.
PHP will run the framework based on which directory is loaded on the server. For instance, on most apache servers the root directory for example.com would be /www. Which means all of the code for Symphony would be in /www/*.
When you setup the path of your subdomain, just put it outside of the /www folder. Then, when you go to abc.example.com apache won't try to load the original site along with the Symphony framework.
I think it will be fine for both frameworks to share the same database tables. I'm not entirely sure how you plan for these two applications to work, but as long as you don't change the column names and types you should be okay.
If you don't want the applications to share the data in the original table, then look into using mysqldump or something of the like to copy the data over to a new table.
I have decided to start coding using OOP and a PHP framework. I have successfully installed Yii on a development server and created a webapp. Now, I would like to move the protected folder to a level outside the document root for security reasons. My question is how to do this when there are multiple subdomains that I will also be using Yii with.
I have experience with PHP, but not in an OOP style and this is my initial step into OOP and frameworks. Also, I have a LAMP system installed on Ubuntu for development.
My path structure is below, which matches the production server. I have a top level site and multiple other top level sites and subdomain sites for one of the top level sites.
top level site - /home/mark/public_html/{website one files}
top level site - /home/mark/public_html/website-two.com/{website-two files}
top level site - /home/mark/public_html/website-three.com/{website-three files}
my sub domains - /home/mark/public_html/sub1.website-three.com/{sub files}
my sub domains - /home/mark/public_html/sub2.website-three.com/{sub2 files}
my sub domains - /home/mark/public_html/sub3.website-three.com/{sub3 files}
I have Yii installed at: /home/mark/Yii
I have created a webapp at: /home/mark/public_html/sub1.website-three.com and access the Yii webapp locally at http://sub1.website-three/ ....I don't use http://localhost since I have virtual hosts and sub domains. All of this works, and will be creating more webapps at other subdomains under website-three.
Can I rename the protected folder to sub_protected and place it at /home/mark, and then for my next webapp, name the protected folder sub2_protected and so on? Should I use a different path structure??? Also, I believe I will need to edit the protected/config/main.php for each site to reflect the changes???
Any assistance would be greatly appreciated. Can't wait to get this configured so I can dive further into Yii ...looks very intriguing so far.
You can name the protected folder whatever you want and put it anywhere on your file system that your webserver user has access to, so, yes /home/mark/sub*n*_protected scheme would work.
However, particularly if your sites are similar and have any shared code, it might be more efficient to use one protected folder and set up an array of urlManager rules in your main config file and load the appropriate rules base on the host name. You can then have dedicated controllers for each host as well as views directories. I've often done this for mobile versions where you can also add mobile detection to the mix.
If the sites are distinct, using separate protected directories might sense as well. E.g., I'll use a separate protected directory for admin tools based on the Gii-generated scaffolding.
If the sites are very similar, you also might want to check out Themes:
http://www.yiiframework.com/doc/guide/1.1/en/topics.theming
Sure you can place protected folder under the document root.
Just use for website one next code in your config:
return array(
'basePath'=>dirname(__FILE__).DIRECTORY_SEPARATOR.'..'.DIRECTORY_SEPARATOR.'..',
and your protected folder will be looked at
/home/mark/protected
I'm having a bit of an application structure design dilemma.
I have created a web app that creates online surveys. It all works fine, but I would now like to create a new site that does different types of online surveys. This new site will be pretty much 95% similar in terms of layout, logic, functions, etc.
Rather than duplicate all the code from the current web app, I'd like the new app to share in the "fountain of knowledge" created by the current app - so to speak.
Can anyone enlighten me with their experiences of doing this sort of thing? Their best practices?
As a rough guide, I'm currently thinking of using symlinks for all the major logic files (library.php, functions.php, etc), and then deciding which logic to use based on which URL the user logged-in from.
Does that sound like a good or bad idea?
Would it be any better or worse to divide the whole system in to 3 sites, with the site in the middle containing all the common elements and logic? This middle site would have no independent use - it would be used from either of the 2 applications looking for functionality and assets, etc.
Any help and experience on this matter is very much appreciated indeed.
I'm very wary of going down a dead-end solution.
Kind Regards,
Seb
Good solution if:
you host your website yourself and creating symlinks between differents virtual hosts is not a problem
you won't have to make significative changes between the 2 websites
But instead of using symlinks, I could take advantage of PHP's include_path directive and put the common libraries in this path. This way, just write your includes relative to this path, the files will be accessible from any site you want on the same server.
The second advantage of using include_path is you can bypass any open_basedir directives which wouldn't allow you to include files which are not in the same virtual host base dir.
This is how I'd do it...
Create a core library.
Create you 2 site directories.
Create site specific code folders in
each site.
Create core library folders in each
site that simlink to the main core
library created.
I run multiple websites all running off of a single installation of CodeIgniter on my server (separate application directories and a single system directory). This has been working fabulously and I don't see any reason to change it at this point.
I find myself writing library classes to extend/override CI all of the time and many times if I find a bug or improve effeciency I have to go back to several websites to make the same adjustments at risk of a typo that breaks one of the websites. Because of this it requires that I change each file and then test that site for bugs.
I have been pondering a solution of using a single libraries directory in a central location and symlinking all of my websites to that central directory. Then when I make a file change it will immediately propagate to all of the downstream websites. It will still require that I test each one for errors, but I won't have to make the changes multiple times. Anything that is specific to a single website will either be a non-shared file (still in the linked directory just not used elsewhere) or can be put in a local helper.
Also, I keep separate 'system' directories by CI version so I can migrate my websites independently if necessary--this central libraries file would be attached to a specific version to reduce possible breaks.
Does anyone see potential issues or pitfalls from taking this approach? Has anyone accomplished this in another direction that I should consider?
Thanks in advance!
I think this actually makes sense :] Go for it. Even on official CodeIgniter page, they mention it's possible.
Also, I don't see one reason why there should be any problem.
Edit: they touch the problem of multiple sites here: http://codeigniter.com/user_guide/general/managing_apps.html
also:
http://codeigniter.com/wiki/Multiple_Applications/
http://www.exclusivetutorials.com/setting-multiple-websites-in-codeigniter-installation/
How to Handle Multiple Projects in CodeIgniter?
http://codeigniter.com/forums/viewthread/56436/
I have a single system directory and separate application directories for my CI apps. In order to share libraries and some view templates between my apps, I have created a "Common" directory, in the same folder as the CI system and with the same structure as a regular app folder and used symlinks, but you can modify the Loader class so that it looks in the Common folder too. My setup looks something like this:
/var/CodeIgniter/
/var/Common/
/var/Common/config/
/var/Common/controllers/
...
/var/Common/libraries/
...
/var/www/someapp/
/var/www/someotherapp/
...
I'm not sure how you handle publishing your sites (assuming you actually do any of that), but I'd look into version control. For example, in SVN you can make external to another svn directory (or file) and then just update the current svn directory which grabs the external file. This approach gains one benefit from the others, which is when you modify the common library, the others aren't immediately affected. This prevents unwanted breaks before you have time to go test all the sites using the common library. You can then just update each site's folder whenever you are ready to test the changes. This is "more work", but it prevents code duplication AND unwanted breaks.
I wrote a MY_Loader to do exactly that.
http://ellislab.com/forums/viewthread/136321/