I would like to structure the website not using url-folders, but rather subdomains:
not my.com/xyz/page1
but rather xyz.my.com/page1
they would share the same design, same layouts and reuse large part of the codebase.
Is it possible to configure URL manager so that both main domain and a subdomain are served using the same codebase?
P.S. Yii version is 1.1.
We use this setup at work actually. What you do is parse your url in the index.php file. Break it up. Based on the first word up until the dot... that can be the name of your folder in the protected/config folder. Make a copy of all of the files currently in the config folder and put it into this new one. So the file structure is /config/subdomain/allfiles here... and /config/subdomain2/allfiles... etc etc. And make sure that the yii app gets made using the correct config by oarsing the url and using the subdomain to locate the folder. You can use different params... dbs, etc etc. But the same code.. and file base for all.
Related
I understand this sort of breaks the structured point of Laravel, but there is method to my madness. I plan on using a single install of laravel to host several websites that are database driven. At the moment all of the sites share the same layout and I have a system to store some custom CSS in the DB to give each site a different color scheme. I want to change this so they can use completely different views. So site A loads views/theme1/app.blade.php and site B loads views/theme2/app.blade.php.
I have implemented this by using the following to return a view.
$theme = getDomainThemeName();
return view($theme.'/home');
This is also working, but i am now left with the task of dynamically loading the assets. I am using bootstrap the generate the themes and making a few tweaks to the HTML to create the app.blade.php file. I have 2 potential solutions to this but i would much rather a way to server the css files from the views directory. This means the following mapping.
http://website.com/css/style.css =>
/resources/views/theme1/css/style.css
Can something like this be done? Another option would be to use php to read the css file and insert it into the app using a yield. It works, but it means i cant use browser caching to cache the assets. I was also thinking i could just create sub directories in the public folder. public/theme1/css/style.css. This makes the most logical sense, but it means i have to fragment the theme system. Id like to be able to unzip a theme in the views directory and it just works.
I am using Laravel 5, i have root access to the server too. Running PHP 5.4 on centos 7.
I think the best approach is having next structure:
/public/css/style.css
/public/css/theme1/custom1.css
/resources/views/common.blade.php
/resources/views/theme1/main.blade.php
And then loading conditionally with php each site theme.
It may not be any trouble with caching.
I'm creating a new plugin for WordPress that requires an outside website to use a web service. For instance, if there are two sites, A and B, the plugin will be installed on A with all associated data stored in the WordPress database for Site A. Site B will use the web service to grab data in XML format from Site A.
Is this possible? What would be the most secure way of pulling this off?
I could just have the web service as a PHP file in my plugin, but that's going to require the outside domain to hit something like:
http://www.example.com/wp-content/plugins/plugin-folder/web-service.php. It seems like a bad idea to expose the level of depth of the WordPress setup.
I could have my plugin create a few files in the root so that the web service call would be to http://www.example.com/web-service.php, but having my plugin install stuff outside of the plugin directory also seems like a bad practice.
Another thought: Could I put the file in my plugin folder, but add a line in file .htaccess to make http://www.example.com/web-service.php go to it?
What is the best, most secure way to go about this?
I would set up a rewrite rule in .htaccess to let the user get to your code without knowing where it is. I don't think there is an easy way to add specific routes to the WordPress front controller, but you could see if there is an action or filter to do that.
Here's a post on adding routes: How can I create custom URL routes?
In my personal opinion, if I installed a WP plugin and you created a new file in my root directory, I would either delete the file or the plugin all together. I would also try to avoid adding a .htaccess file. This would again make me suspicious.
What I would do is, upon install ping a file on Site B (your site) that captures the location of the plugin folder on Site A (their site), because WP might be installed inside of a directory and not at the root. Then you know where the "web-service.php" file is located. Then you can just hit that file whenever you need. There is no reason for .htaccess rules, or creation of new files.
Just a suggestion :)
I'm refactoring an old project developed in procedural PHP, with a new object oriented approach with Zend.
The website have two main section:
- Miscellaneous pages, lots of old pages still online on the main domain (www)
- A forum section, the part i refactorised with Zend on a forum subdomain
The goal is to refactor the whole website on a main Zend project which would cover the two subdomains.
Now i have to refactor some of the pages of the main domain, and because the domains have separated virtualhosts: the www domain is set to a specific directory and the forum domain is set to another directory (the Zend one), each one with custom URL rewriting.
The obvious solution would be to merge the old pages directories with the forum directory, but i can't because it would break the folder architecture of Zend.
The ideal solution would be to add a regexp clause in the main domain's vitualhost to redirect some urls of the www to the directory of the Zend project directory, but i haven't find a way to do it yet.
Is there a other way? I also can create some temporary subdomain to host the refactored pages but it's not an elegant solution.
I don't get it.
Why don't you make a clean refactor on your local env, then deploy it and make the DNS migration ? Why would you make old and new pieces of code cohabit ? You said it : "The goal is to refactor the whole website on a main Zend project which would cover the two subdomains". Then go on ! Refactor, deploy, and redirect the old domain names to the new one !
Finally, i choose a mixed solution, i'll use temporary subdomains for some parts until i could refactor in one time the rest of the old pages.
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 my main site kansasoutlawwrestling.com which will be using Codeigniter, and then I am also creating a CMS for myself that is a separate entity which will be located at kansasoutlawwrestling.com/kowmanager.
My CMS will use different CSS, javascript, and image files, so I'm wondering if I should just have two different installs of CI. I tried looking at PyroCMS, but there's way too many folders and I was having a problem understanding its file structure. What is the proper set up for this is?
The basic structure of Codeigniter is that you have 2 folders and 1 file in your root folder:
root/application/
root/system/
root/index.php
Now, obviously, you might have many more files and folders in there as well, but these are the basics upon which every Codeigniter app runs.
What do each of these do? To begin with, every page request starts at index.php. This page set's up some configurations and some constants, and then hands over the reigns to Codeigniter.
Where is "Codeigniter" located? That would be the system folder. This folder should never be touched, by you or anyone else. Everything pertaining to your app is stored within the application folder. This includes all your configurations, your controllers, your models, your views, even your library extensions (although you could store other stuff outside this folder, like images/css/js/fonts etc.).
So, the correct way to set up shop would be:
root/application/
root/system/
root/index.php
root/kowmanager/application
root/kowmanager/index.php
But, you have to inform your kowmanager's index.php that the system folder is not located in the same directory. So, within the index.php (inside of kowmanager), at around line 25, you should see this:
$system_path = "system";
Simply change it to:
$system_path = "../system";
and you're done.
Now both your apps (your main site and you CMS) will be sharing the same Codeigniter base. When the time comes to update CI, you'll do that once within the main system folder...
I've done several Codeigniter CMS's and taken both routes:
Integrated (shared application files and assets)
Separate installation (only shared system files, if any)
At first I liked the convenience of the integrated approach: when I needed a custom library or icon file for the front and back end, it was available without duplication. I've since changed my mind.
My opinion now, after 4 years or so of working on these, is that the benefits of having an integrated CMS is short-lived.
90% of the code is in the back end, so you end up with lots of helpers, libraries, etc. that are only used for administration.
Any shared resources that you need to tweak can end up working great on one side, but breaking the other, or being overkill/useless.
Models tend to be bloated for use on the front-end when they are full of code that's only used for the back end.
Shared templates, js, and css files almost never work. The control panel probably doesn't need to work in IE{insert version here}, but your front end should.
It makes updates and upgrades to either end sketchy, unless you know exactly what you need to update and what not to touch, and where you may have made customizations for a particular site's front end that should not be altered.
Auth logic is much easier when your admins and regular users aren't in the same bucket
Separate installations are easier to set up, and they can be "tacked on" to an existing site rather than having to integrate it.
My advice: Go with a separate installation.
If I were you, I would probably not go the separate applications path. If you're sharing things like code that renders a page or logs a user in, you'll be repeating it for both installs. Obviously two separate installs would only require one system folder of which you'd share as nothing changes in system. If it were me, I'd probably just set up a route in your config/routes.php file.
Something like the following (presuming you have a controller called 'kowmanager' inside a folder called 'kowmanager' in your controllers folder):
// This would redirect all calls to kansasoutlawwrestling.com/kowmanager
// to the kowmanager controller.
$route['kowmanager'] = "kowmanager/kowmanager";
// Redirects all kowmanager/method requests to the kowmanager folder
// and a particular controller
$route['kowmanager/(:any)'] = "kowmanager/$1";
// Redirects all kowmanager/method requests to the kowmanager folder and a
// particular controller and method inside controller.
$route['kowmanager/(:any)/(:any)'] = "kowmanager/$1/$2";
Might not be the best option, but it means you won't repeat the same code twice and you've essentially created two applications inside one. There are numerous other ways of doing this including some rewrites in your .htaccess file.
If you want the easier option, go separate installs and be mindful of code repetition. Stick to the DRY (Don't Repeat Yourself) methodology.