I looking for some plugin structure for Laravel based applications.
For example a forum software, a cms or a e-commerce application can benefit from a plugin structure.
My question is what is the best way to implement this plugin system so that third party plugins can extend the application. The main issue is that it should be dynamically extendible and users should be able to install these plugins easily without messing with the app code.
This question also extends to themes but thats another question. Any ideas?
Laravel is a framework, not a CMS like Wordpress or Joomla, so plugin system that fits everybody may be quite hard to create as Laravel can be used in many ways, but I can really see the benefit of easy packages in some contexts.
The Packagist has been already mentioned and it doesn't solve directly your problem but how about:
Find good usable packages from Packagist for the purposes you need
Define common plugin architecture (common API for binding things together, installer, package format, migration, updates etc) on top of Packagist packages
Create installer that fetches packages via Packagist/Composer and adds sets sane default settings and configuration for the packages and integrates them into the defined plugin architecture
Document and plan this really well and the others will soon follow
I'm a little confused about the question, but I believe what you are looking for is already implemented in Laravel 4. They are just called Packages, and can be found at http://www.packagist.org and easily installed and autoloaded into your application using Composer.
Related
I'm wondering what the best way (if there is a way) for an application to auto-discover [relevant] PHP "packages" installed by Composer.
My use case specific scenario:
I have a PHP app that includes my "framework" (for lack of a better word). This framework brings some basic functionality (routing, admin etc).
I'm slowly building in more advanced functionality, say, a blog module. This module is entirely self contained in it's own directory (but obviously has dependencies on the framework).
I'd like this blog module to be a self contained Composer package, so that I can selectively require the package in my app's root composer.json file.
Now, I need for the framework to know that it's there so that it can, for example, set the routing correctly and load up any admin functionality that the module requires.
What I've thought so far:
I'm relatively experienced in PHP, but "proper" OOP and autoloading is a little bit beyond my knowledge at the moment, so please forgive if there are inbuilt functions to do this. I don't even know what terms to Google!
I have thought I could maybe read the installed.json file which composer puts at vendor/composer/installed.php but I'm not sure how to set up my packages (e.g. blog) so they announce what they are. I'd like to future proof it so that I'm not looking for known module names (or regexing vendor or package names), but rather looking for packages to say "hey framework, I know you! You can use me!"
Maybe I can somehow instruct Composer (through the package's composer.json file) to stick in an arbitrary key/value pair in installed.json?
Any suggestions welcome, or directions as to what sort of Googling I should be doing.
Oh welcome to the world of managing dependencies on your framework.
I have some experience with auraphp, where we dealt with similar issue. You can read the blog post Composer-Assisted Two-Stage Configuration .
So what we finally ended-up adding https://github.com/auraphp/Aura.Web/blob/a3870d1a16ecd3ab6c4807165ac5196384da62cd/composer.json#L26-L36 these lines in the packages that need to understand to load by the framework.
You can also see how this bundle can also get autoloaded with the configurations.
in your composer.json
https://github.com/harikt/Aura.Asset_Bundle/blob/6ea787979390e69bf6ecb1e33ce00ed90f306e2f/composer.json#L21-L27
and the config/Common.php ( https://github.com/harikt/Aura.Asset_Bundle/blob/223126cedb460e486c4f0b242719c96c14be5385/config/Common.php ) , note we have other development modes also. For a detailed look check https://github.com/auraphp/Aura.Web_Project or https://github.com/auraphp/Aura.Framework_Project
Hope that helps a bit to look into the code and work on your own solution.
We're building a new CMS for our company using Laravel.
To help with maintaining the code we have decided to make commonly used pieces of functionality into different packages. E.g. a blog package, a gallery package etc...
What I'd ideally like is for the admin area to be able to find installed packages of a certain type and build a navigation based on what they provide.
What's the best way of accomplishing this goal - is there a way of making installed packages register themselves with the admin package? I don't really want the admin package to have to go looking for other packages.
All ideas appreciated.
Make a registration class, make a ->registerNavigation($controller, $text) item, then in the sub-packages' service provider ::boot() functions you call the registerNavigation method
sub-packages will be registered in the order they're listed in laravel's service providers.
Of course, you could have it as complex or as simple as you'd like. :)
If you make your packages plug-ins, you can do what you want. I don't think you need a design pattern, per se, apart from the fact that plug-ins are usually some variant of the Strategy pattern.
The navigation would be constructed based on the existing implementations of the plug-in interface (i.e., the existing strategies).
Reflection (if you can make it work in PHP) would get you a way to discover what things are "installed" easily. But for security it's probably better to have a more formal way to install packages (otherwise any compatible plug-in code that manages to be dropped in could theoretically get executed if you use only reflection).
I've been using CodeIgniter for a few months and recently discovered Bonfire, which looks like a great foundation for CI projects, despite the current build using almost outdated resources like Bootstrap 2.
I really love the module system in Bonfire, it seems like a very efficient method for creating completely independent subsystems. However, I wonder how compatible these modules would be with a normal CodeIgniter installation. Obviously you can't just dump the modules folder in, CI wouldn't know what to do with it, but is there any way to restructure a BF module into a third party plugin or something that can be used in CI?
Similarly, would it be possible to extract files from a CI installation and package them as a BF module (obviously with some tweaking)?
I would imagine the answer to those questions would probably be "of course not", so I just want to make my understanding clear; if I decide to develop with Bonfire, I would essentially be stuck using it without being able to revert to vanilla CodeIgniter and I would only be able to share my modules with other Bonfire users. Correct?
Basically the very first difference is that bonfire works on HMVC (Hierarchical model–view–controller) which means every module will contain its own model view and controller.
Yes it can easily be integrate with the vanilla codeIgniter you mentioned because the framework basically following the codeIgniter rules and provided a CMS with great functions.
Some features like:
Built-In Admin Area
Modular Coding
Data Maintenance
For more details check the documentation
I have a PHP Platform that I've built.
I use a copy of that project for each project I do.
I add assets and configure each project with it's own content.
Configuring a project changes some of the core files which contain
the configuration defaults.
When I update core files in the library/platform itself and I want to disseminate those changes to all of the other projects using that platform, what would be the best approach?
I think it may be worth noting that I have each project as an SVN project in Eclipse.
UPDATED DETAILS:
The platform is based on AMFPHP 1.9.
AMFPHP has a services folder.
I have to put core services in the services folder as well as
implementation specific services and therefore cannot achieve
complete separation between the "library" and the "application".
Also, the default configuration files need to be in the "platform" folder
so they can be easily distributed with it, but when configuration is
changed, those files become "implementation specific" as well.
Is there a solution that will allow me to designate certain files to update?
Take a look at the use of svn:externals. Configure each secondary project with your core libraries as an external.
Excellent question, here's the way I solved this problem with my own PHP framework.
If you have all the project-specific and core files mixed together, and platform code interspersed with your project code, it's going to be really difficult to update the core code to all of your projects.
The best way to get around this is to make it easier for svn (or git, or any other versioning software) to update your files: if they're all neatly organized, with project and core files in their respective places. Let me give you an example to clarify.
Put all of the core files of your framework in this directory:
/App/FrameworkName
Here you can place core classes, functions, and other code that won't change for all of your different projects.
Then, any project-related content, settings or pages go in:
/App/Project
Here, you have all of the data that your projects use.
With this system, if you add a feature to your platform, all you have to do is svn the latest version of your framework to /App/FrameworkName, and your project will be using up-to-date code.
My programs are usually organised in two parts. the core framework folder, and the addon folders.my framework (in house) does all the initial work then loads the addon for additional functionality.
For example, the framework deals with all the user auth , the addon provide additional crud functions the each project needs.
That way, i can keep them in separate repository. and the framework can be checked out and used for other projects.
I am looking to reduce redundancies in code shared across entire web sites. I have tinkered with several frameworks but cannot think of any that allow you to EASILY separate the framework code from the site code while sharing it to multiple sites at the same time.
What PHP frameworks can do this easily?
EDIT - I am trying to determine which frameworks are the easiest to share.. I was already guessing that nearly all could be shared, but which frameworks are geared towards sharing? It sounds like Yii recommends placing the framework code outside the site code, that is a good start.
If someone is sharing the same framework code across sites already, I would love to know about that.
It's pretty easy to do that with Fuel (http://fuelphp.com).
Each website has an index.php where some paths are defined:
/**
* Set all the paths here
*/
$app_path = '../fuel/app/';
$package_path = '../fuel/packages/';
$core_path = '../fuel/core/';
As you can see, you may share the core and packages in a central repository and create a single app and public folders to each web site.
You may even share an app with different web sites customizing stuff (let's say, the site title or the database used) by just setting a different environment in the .htaccess. That works out-of-the-box for development/stage/production sites, for example, but may be extended to anything. You may also setup central packages to use in multiple apps. Powerful, easy and just works.
Many can do this. For instance YII is supposed to be installed OUTSIDE of your www-root directory (httpdocs, /var/www/ or something like that). You can use several sites to point to that base dir.
Any framework (or part) that does not need specific settings for your site can be shared among multiple sites I guess.
I believe Zend can do what you ask, possibly even Symfony and Fuel, and I'm sure many other frameworks that allow you to pick what parts of it to use will let you do this.
However, doing so will require you to do a little more configuring to get it all running. Which is kind of why I ended up creating my own framework.
Symfony does. I love the Symfony framework, and it comes with some great frameworks. You might like the Routing and YAML ones. A person I know calls Symfony the best php framework.
Symfony components
Some of the components have their own specific sites
You can find a really good documentation here.
Symfony2 is suitable for your needs. It's a full stack framework with a lot of standalone components. It works with "bundles", a bundle is a kind of container with a complete logic (controllers, model objects, views, assets, configuration, ...). That means you write one bundle and you can reuse it without any problem.
But you can also consider symfony 1.4. One project can handles many applications so your model is shared across these applications and the same code can be reused in all applications. Note an application can be a complete website.
I can't think of any frameworks that do this natively, but you could use several SVN (or hg, etc) repositories to accomplish this. Example using CakePHP:
1 repo has the CakePHP default files. If you wish to update CakePHP,
you update this repo in the future.
1 repo per website that stores everything inside your app folder.
It's not built in functionality, but it isn't very difficult to setup either.