I recently finished my website's transition to Laravel and all that is left is the current forum software, vBulletin.
Right now, my website consists of various Blade files (all extending the main layout).
For the forum to work, I had to place all vBulletin files in a /forum directory inside /public and access them directly (having to add an exception in .htaccess file). So, by accessing them directly (by visiting example.com/public/forum/index.php for example), I am loosing all the Laravel functionality. But I also want to use some methods and controllers I have already defined in my Laravel site. Get the current user, his profile picture and other stuff.
Moreover, how can I use the Blade files outside of Laravel? For example, I would like to have a common header (which is already in its own header.blade.php file). How can I accomplish that instead of creating a new header.php file and have all blade syntax converted to html/php?
The question(s) above may be specific for vBulletin, but could be expanded to any application:
How do we use an external application inside Laravel, utilising Blade syntax and all the Classes / Controllers already implemented?
Thanks in advance,
Ilias
Related
I am currently working on site built by another developer on CodeIgniter. I do not have the GitHub repository since there is no way to reach the previous developer. All I have now is the project files stored in the file system of the host. I found the view folder of the project and see a bunch of PHP files on it. The codes of each PHP files look similar, I am having trouble knowing which PHP files generate which page.
My question is, on the browser, is there a way to know which PHP files generate the HTML of the page that I am currently viewing?
In CodeIgniter, Controllers are the routes generally. Look in the controllers directory. For example User controller with update method will result in /user/update route. Moreover, the developer might have specified custom routes too. You will have to check application/config/routes.php too. Once you will locate the correct controllers, you can find the views used by the related controllers (or routes). I hope this helps.
You cannot use the "view" files to quickly figure out what URL displays that file. It's entirely possible that any given "view" file is used on multiple pages. It's also quite likely that any given URL will use multiple "view" files.
You should instead examine the files under /application/controllers and look for lines of code making a call to $this->load->view('some_file_name_here'); There may or may not be a subdirectory as part of the file name - depends on how the original dev organized things.
The CodeIgniter documentation is excellent and is found HERE. Start with the General Topics. In particular, the following general topics (in the order shown) may be highly useful and help you make sense of what the other answers are talking about.
Controllers
Views
CodeIgniter URLs
URI Routing
Models
A read-through of the tutorial will be helpful too after checking out the above.
Use the Libraries section of the docs to get details on the various parts of the framework you're likely to run into in your explorations.
You know wordpress template system. I'm writing a simple script with Laravel. I'm very beginner at Laravel. I need to more than one template and it must be selectable at admin panel.
I created subfolders at views doc like that:
project/resources/views
defaulttemplate
othertemplate
othertemplate2
I keep template's doc name in the database when one is selected. I want to run the site selected template.
How to I can do it?
Firstly, Wordpress has a million lines of code and it's open source. You have to observe their codes from github repo if you have ever never implemented an templating engine as same as Wordpress or any kind of equivalent applications. It's not best practice however you can simply create a new namespace for the view from the app container.
You can boot your namespace definition on AppServiceProvider
app("view")->addNamespace("theme",base_path('themes/'.DEFAULT_TEMPLATE_FOLDER_NAME));
Within this way, you can pass different folders as a view. you have to call your view files via themes:: namespace.
Let's assume you have a default folder in the themes folder as a default template and there is index.blade.php inside of it. You have to call it as a return view('themes::index') in the controller. If DEFAULT_TEMPLATE_FOLDER_NAME changed, the themes:: namespace will point to changed destination due to App Service Provider. It's a simplest version of wordpress-like templating. For the best case, you have to observe different kind of open source projects.
I've taken over management of a large complex site with multiple laravel installations of various ages. Some are in use some are only partially so for some routes (complex htaccess redirects abound).
I'm new to Laravel so this is a bit of a headache for me.
Is there an easy way to have laravel include the source path and filename of the controller, model and view it has used when rendering a view so I can find what files on the server are responsible for what 'pages' on the site?
TY
If you have a relative small site (i.e. a handfull of pages) you can visit each page with Laravel debugbar activated. In my office we use this for a while now and we are pretty positive about it. There is a special 'views' tab that enables you to see which views are included when you visit a certain page. It has some nice options, you can even view queries!
Example from our development environment with APP_DEBUG=true in the .env file:
In addition to the debugbar, you can also consider a package that shows route information for you by listing all routes that are called and showing the names of controllers, methods and request type in an other colour. We use Pretty routes since it is more convenient for us to read all 'routes' in the browser than in the terminal.
When starting from the app/ directory, the path of any of these classes is the same as the namespace they are in.
So if you have a model App\Models\User, this will be located in app/models/User.php.
As for the views, you start in the resources/views/ directory, replace dots in the view name by / and add .blade.php.
So, a view named website.index is located in resources/views/website/index.blade.php.
This is kind of an advanced answer that requires some Linux skills, but with the built in commando strace you can see which resources are opened: which php file, which database calls etc. This way you can analyze what is used when.
A very good tutorial can be found here:
https://hackernoon.com/debugging-a-php-application-with-strace-4d0ae59f880b
another great article on strace with PHP: https://ma.ttias.be/linux-application-script-debugging-with-strace/
I would also suggest to use all kind of filters and grep to filter the output to something meaningful.
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 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.