I understand that this question may be vague, I will try my best to explain my problem and hopefully can get lots of insights from the experienced and hopefully this will not be closed.
I'm writing a PHP web app framework based on Symfony 2's components and bundles, my question may not relate to that however. The framework is intended to be open to 3rd party plugins, these plugins will have their own config files (yaml) and the person who install these plugins should be able to override these settings locally.
I also have to make sure that each time the person perform the plugin upgrade operation, it should be easy to loop over the list of "upgrade patches" to upgrade the plugin's settings while still retaining the local settings.
I imagine I can have a local, app's specific plugins.yml file which store something like this:
pluginA:
somesettings: value
somesettings2: value2
This app's specific settings file will allow user to override any default settings. And then each plugin can contain an "upgrade" class that will contain all the patches for each version, the framework will identify the current installed path and will loop through each "upgrade patch" and perform actions until it reach the most current version.
Does this sound like a good option, or if there is something else I should look into? How do I have configuration settings that can be overridden can be upgraded easily? Please let me know if you need more details.
It seems to me that you are looking to achieve something that actually core Symfony allows to do - i. e. to let other users override / implement custom parts of an already existing bundle.
If so, maybe this answer can give a good idea on how to achieve that using the ClassLoader Component (Symfony 2.0) or Composer (Symfony 2.1):
How can I override Core Symfony2 Classes?
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.
Learning Symfony2 and Sylius at the same time here. Thanks for your patience.
What brought me to this question is the desire to override some of Sylius's default functionally. The first of which I am focusing on is tax behavior. I want to accommodate specific tax rates for several different on the ground stores. As I understand it, if I want to be able to update future changes in Sylius, I don't want to modify code in sylius/src/Sylus/* correct? I think I understand how to make the overrides, but I cannot seem to generate my own bundle with Sylius.
ubuntu#ubuntu-VirtualBox:/var/www/sylius$ php app/console generate:bundle
[InvalidArgumentException]
Command "generate:bundle" is not defined.
I can run the same command in a generic Symfony2 install I have, and it works.
Am I doing something wrong / something is broken, or has bundle generation been removed from Sylius and it is expected that bundles be written all manually?
Thanks, and any links to further reading on this are appreciated.
You need to install SensioGeneratorBundle if you want this feature. This bundle is not included in standard Sylius distribution. Installation and their usage is pretty straightforward ;)
Yup, I think you shouldn't edit core bundles but instead override whatever you want - see here how to achieve that. Sylius is built with good design so overriding could be easily achieved by simply having your own DI class parameter instead of core class.
Cheers!
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.
I'm working myself through creating an app using Zend Framework 2 and one of the features I really liked was having the ability to set PHP settings based on the environment (mostly enabling the error displays in the devel environment). As far as I can tell from my limited research this feature doesn't yet (or won't) exist and you have to create a custom solution for it.
Am I wrong or is this the only solution as of ZF 2.0.2?
You're correct, as of 2.0.2, there is no "built-in" solution for this in ZF2. If you're using PHP config files, you can simply put the ini_set() calls there. I've outlined methods for doing environment specific configuration files on my blog: http://blog.evan.pro/environment-specific-configuration-in-zend-framework-2
At a quick glance, the solution on the link you provided should still work as of 2.0.2. Personally, I'd just put the ini_set() calls in my configs, as I said, instead of attaching an extra listener to the bootstrap event, an extra check for the config key, and a foreach loop, but that's the beauty of ZF2: If you're looking for an easy way to provide PHP settings via the config, there's a module for that!
It is generally adviced to store module assets inside the module's directory, inside moduleName/public (or whatever you want to name the asset's directory).
Zend Framework 2 unfortunately doesn't support asset publishing for module assets by default. According to MWOP, there was nothing planned ~1 month ago and I guess there still is no real plan (they had probably a lot of work to get the stable version ready). (But, some day, they are going to address this issue.)
As my ZF2 app is growing and growing, I reached the point where I need to have module-specific assets. At the moment, I maintain them inside the module directories and copy them to the application's public directory. You can imagine that this method is error-prone and exhausting.
How do you handle this problem? Is there maybe a simple solution to this issue with little coding effort? My project plan doesn't allow me to create a complex asset handling on my own. Is there a recommendable, lightweight asset framework compatible to ZF2? I've already considered creating symlinks but I don't think this would be the best solution because it would require some additional web server configuration (FollowSymlinks) and additional maintenance work (the app is developed locally and deployed on a remote server).
Thanks in advance.
This has been discussed before in many places and it comes down to three ways to manage this.
Copy and Paste the assets into the public/ directory
Use symlinks
Use an asset loading module like assetic
A simple solution would be to make the copying of assets part of you build process.
Another question was already asked How to merge Zend Framework 2 module public directories for info.
I know this is pretty old, but I wanted to add this information for other readers.
Now there's also a module for this, which has been fully tested and is being used (and even depended on) by many modules.
Check it out here: https://github.com/RWOverdijk/AssetManager
Hope this helps.
There is also fourth option. Use a directory Alias in VirtualHost configuration.