Symfony - What is required to create a plugin? - php

I've been going through the Symfony documentation in order to find out how to create a plugin. However, the two tutorials seem to give a lot of extra information (for example models etc).
What I'd like to know is, what is the absolute minimum requirement in order to get a controller and template working from a plugin directory?
For example, just an index action and a corresponding 'Hello World' template.
Also, is the routing for this automatic or do I have to manually change something?
Any advice appreciated.
Thanks.

To do what youre askign you would need the following:
MyPlugin/
modules/
my_module/
actions/
actions.class.php
templates/
indexSuccess.php
You would then need to enable the plugin in you ProjectConfiguration and also enable the module in your settings.yml for any apps you want to use it.
Routing is not automatic. You need to add routes manually to routing.yml or you can create a listener and appends/prepends the routes when routing.load_configuration is fired. USing the second option would also imply creating a PluginConfiguration class where you listeners connect to the event via the event dispatcher.
Basically a Plugin follows the same basic structure as an application - except pretty much everything is optional. Whether or not you need to do somethign really depends on what your plugin does. Also you might want to take a look at using sfTaskExtraPlugin it has a task for generating a basic plugin skeleton and a plugin module skeleton.

some examples
enable the plugin in you ProjectConfiguration
go to 'core\config\ProjectConfiguration.class.php' and add next code in setup()
$this->enablePlugins('MyPlugin');
enable the module in your settings.yml
all:
.settings:
enabled_modules: [my_module]

Related

Proper dev. approach for overriding Twig templates

I recently decided to take a look at Sylius, since I love the idea of a developer-friendly Symfony2 project.
I tried to look through the various documentation articles, but I didn't seem to be able to find the answer for a very fundamental question that I have: what is the recommended way to start development on a new web-store, which will include (at the very least), the ability to implement one's own HTML template designs, and still be able to easily upgrade Sylius to future versions?
The best approach that I was able to come up with is to create a new bundle (in my case, named WebBundle) which is based on the default SyliusWebBundle. Here's the problem. In order to get the bare minimum of allowing Sylius to use the templates in my bundle, rather than the default one, I had to go through many hoops. Here are several things I have done so far:
Copied the contents of the original Controller directory from SyliusWebBundle. Changed return values to use WebBundle rather than SyliusWebBundle a part of the string in the argument to $this->render(), as well as the class namespaces.
Copied the YAML files in the Resources/config/routing directory from SyliusWebBundle to my bundle. Changed SyliusWebBundle references in the YAML files, similar to the above.
Added new sections to app/config/config.yml, specifically this part (intended to override the contents of addCheckoutSection() in Sylius\Bundle\CoreBundle\DependencyInjection\Configuration):
sylius_core:
# ...
checkout:
steps:
security:
template: 'WebBundle:Frontend/Checkout/Step:security.html.twig'
addressing:
template: 'WebBundle:Frontend/Checkout/Step:addressing.html.twig'
shipping:
template: 'WebBundle:Frontend/Checkout/Step:shipping.html.twig'
payment:
template: 'WebBundle:Frontend/Checkout/Step:payment.html.twig'
finalize:
template: 'WebBundle:Frontend/Checkout/Step:finalize.html.twig'
I have a lot more work in changing all the default controller references in the YAML files in Resources/config/routing/frontend directory, but before I proceed onward, I need to know if this is the correct approach, or if I'm going down the wrong path.
My goal is to make the store as easy to upgrade as possible with new releases of Sylius, so I'd like to avoid modifying core library files, and instead selectively overriding functionality using my own bundles, as needed.
However, Sylius currently doesn't yet appear to be "geared" towards this approach, unless I missed something.
The fact that I had to override functionality from more than one bundle (CoreBundle as well as WebBundle, per the above YAML section), made me pause with my current approach. I hope someone might be able to steer me in the right direction.
you can override all templates in the app folder (this is part of symfony and works with all bundles):
app/Resources/SyliusWebBundle/views/Frontend/Checkout/Step/
security.html.twig
addressing.html.twig
shipping.html.twig
payment.html.twig
finalize.html.twig

CodeIgniter: where should I put custom utils?

I'm using CodeIgniter and I have a few utils that I want each controller (that is, each controller file) to have access to.
The question is: where to put these?
I thought of helpers, but the CI documentation talks only about extending existing helpers, not making your own. I'm sure that doesn't mean I can't make my own helpers, but it does mean I don't know how they should be built (procedural? Methods of the global CI instance? etc)
I also considered hooks, but this is a poor fit I think as I'm not extending core functionality.
Or is there some other way I'm missing?
It's been a while since I've done this but I believe I used two approaches.
Creating a new, custom helper that goes into /application/helpers, following steps noted from this answer: CodeIgniter: Create new helper?
Creating a new library class into /application/libraries which I also activate in the autoload configuration found in /applications/config/autoload.php. This way it's always available to my controllers when I need it. CI has good documentation on this one (http://ellislab.com/codeigniter/user-guide/general/creating_libraries.html).
I did it simply by adding a file to the application/helpers folder (maybe I created that folder - I can't remember) and then loading them in the usual way.

Symfony2 bundle as a plugin

Consider situation where I have some default bundle that hypothetically create some empty page with menu on left and some content (if there is any). Then I create a new bundle and I normally turn it on in AppKernel. Now should magic start: bundle by his own (no need to add any options in default bundle etc.) hooks up and creates his menu entry (and if chosen, renders his content). How should I do this, is there any proper way to do this? What if I want to have multiple "hooks", for example, adding also new form in user profile edit, or adding new tab on some other place?
I'm thinking about looking for some "initialize bundle event" that I could listen to and pass data thru it. But maybe there is better solution. I would love to see your ideas :)
Looking at the initializeBundles method of the Kernel, it doesn't look easy or intended to dynamically add bundles during the bootup process.
However, the AppKernel.php file is on the forefront, it is an override of Kernel and can be customized to supply a dynamic set of bundles to the implemented registerBundles method.
You will need to make sure the imported content is properly added to the autoloader, but avoid modifying the distribution source at runtime, try to make it as imported as possible.
I don't want to go into great detail on the technicalities as I have not done this myself and it will require a lot of experimentation. I do know that Drupal 8 uses Symfony2 and has its own plugin system, but I don't think it takes bundles as plugins.
If you manage to pull this off I suspect it will allow 100% integration between the application and the plugins, but just be aware that it also allows 100% overriding access to said plugins.

Override Laravel 4 Package view

I want to create my custom CMS and I'd like to create a user package in which I will have a controller with showProfile() function. But the problem is I'd like to easily edit this profile view. So I want to know if there is a way to create cascade view. Like if there is no file in app/views/ then vendor/vendor/package/src/views will be loaded. I hope you got this idea :)
EDIT:
I managed to make it work. I had to register new namespace for views in my ServiceProvider.
I put this code to ServiceProvider:
\View::addNamespace('cmscore',array(app_path()./'views/packages/zaalbarxx/cmscore');
Where zaalbarxx/cmscore is vendor/package and cmscore is a namespace I can use later in controller like View::make('cmscore::index'). I added this code in boot() method BEFORE $this->package() so this way app/views are prioritized over package/views. Works brilliant.
It is already possible, however the structure would be it look into vendor/package-name/src/views by default, but if there is the equivalent in app/views/packages/package-name/ that would be chosen.
As stated, you should be able to load package views already.
However, you can add more view locations in the array found in app/config/view.php.
Additionally view paths can be added at run-time with the addLocation() method found in the FileViewFinder class.
Using that method that in a service provider would look like:
$app['view.finder']->addLocation('/path/to/views');
Or anywhere in your app:
App::make('view.finder')->addLocation('/path/to/views');
Also note, I answered this question on cacheing view output recently, which might help you see how extending some portions of the View package might work if you choose to go down that route.
You don't need to program this behavior in, if you read the laravel code you will see that this is built in...
Packages by default will first look in and
app/views/packages/package-name/ (all in lowercase! even if package or author have caps! goes unnoticed on windows and then on linux you will bump your head against the wall! )
and if the customer app view doesn't exist the package views will load from the package itself inside:
vendor/author/package-name/src/views

Creating a simple custom view in SugarCRM

I am trying to use the MVC architecture of sugarcrm to add a new action and with that a new view.
I have managed to create a controller with the action and also a class view, the only thing I can't figure out is how to create a simple html page.
Do I really have to use the metada way of sugarcrm?? I just want a simple form with two or three fields.
Are there alternatives to the metadata or do I really have to use it to create my simple page????
You will want to stay within the metadata framework to create your new page if possible. However, once you are in the view controllers, you can echo out anything you wish and still stay "upgrade safe" by overriding the display() function. But, the right way to do what you are wanting to accomplish above is to not only override the display() function but also create a new tpl file (custom/modules//tpls/view.tpl) and then perform whatever you need to perform PHP wise and then assign the variables via the smarty templating engine (I know this sounds complicated - but it's not. It's actually pretty straightforward once you understand Smarty).
One other thing - make sure you are doing all of this (including your controllers and view files) in the custom/modules directory. As this will also keep things upgrade safe. And keep you free from all kinds of headaches in the future. :)
Here is a link to the SugarCRM Developer's Guide online and also a link to their Developer's website. SugarCRM has a pretty good community of developers on the forums so feel free to ask questions there as well.
Developer's Guide:
http://developers.sugarcrm.com/docs/OS/5.2/-docs-Developer_Guides-Developer_Guide_5.2-toc.html
Developer's Site:
http://developers.sugarcrm.com/
Hope this all helps!
Try to do following:
create a new module
put your page into custom/modules/
using URL index.php?module=&action= (without php extension, of course) you can access to your page.
If you'd like to have different action name and page name then you should add the file action_file_map.php
into your module directory and specify inside the mapping:
$action_file_map['action_name'] = 'path_to_your_page';
Note that action_name must be all lowercase - the SugarController won't be able to to match mixed-case actions (true as of SugarCRM 6.1.2).

Categories