Sylius: Plugin Coding Spree

[pjedrzejewski]

As a part of my ongoing work on better organizing our community, I want to introduce the concept of Efforts. More details in the PR: #8107.

Effort Leads: @pamil, @CoderMaggie

Hello folks!

Plugin Coding Spree is an effort to improve foundations for the Sylius plugin development and define conventions that will allow sharing our work and avoid duplication. Symfony gives us an excellent foundation for plugin development and combined with our strong testing culture it really gives us potential to redefine how Sylius is extended. What is more, we are not limited to bundles, some functionality/automation can be even pushed outside the core, using APIs.

I'd like to split this Effort into 3 separate areas:

Code

We already have several extension points that can be used in plugins, but we should think about improving them or introducing a bit more. Of course, most problems will appear when we develop more plugins, but we should already consider some things. So far we have:

• Template overriding;
• Template events (plugins can add before/after blocks);
• Menu events (plugins can add admin/shop menu items & sections to forms);
• ResourceController events to customize responses/redirects, etc.;
• State Machine Callbacks to customize the business logic;
• Translations can be added/overridden in plugins;
• Grids have both events and can be configured;
• All kinds of standard Symfony-way customization - overriding/decorating services, form extensions, controllers;

So far this has been quite good, the only area I see big possible improvement is template events for forms. If your plugin adds a form field, there is not always an easy way to render it.

• [ ] Discuss possible improvements & note missing extension points in this Effort

Documentation

We have a very basic section "Sylius Plugins", but we definitely need to document the idea of plugins, conventions, how to develop them and how to share them with community. (Via Sylius website) That being said, I see potential duplication with "Customization Guide". Perhaps we could merge these two into "Extending Sylius", because it does not matter that much if you put your code in AppBundle vs. Plugin. The Customization Guide already describes all possibilities described above, so there is no point in duplicating that. We should also include some examples of plugins developed so far:

• https://github.com/pjedrzejewski/PdosWebhooksPlugin
• https://github.com/bitbag-commerce/mailchimp-plugin
• https://github.com/coding-berlin/ExtraPromotionsPlugin
• https://github.com/webburza/sylius-wishlist-bundle

• https://github.com/stefandoorn/sitemap-plugin

• [x] Consider merging Customization Guide & Plugin Guide into one "Extending Sylius" chapter or something similar

• [ ] Define and document conventions (repo, package and bundle names, service id prefixes, etc.)

Organization

We are updating Sylius.org website and it will include initial MVP of plugin marketplace (just plugin listing).

• [x] Add plugin listing to Sylius.org;
• [x] Add ability to submit plugins via website;
• [x] Define plugin acceptance criteria;
• [x] Document the process;
• [x] Release a blog post;

Summary

There are a couple of things to discuss, so let me hear your thoughts! After some brainstorming, I will update all this and split it into separate issues.

Happy Friday! :)

[stefandoorn]

Hi @pjedrzejewski. I think this is a good step forwards.

I have one additional for the section 'code'. Currently it's possible to extend entities and repositories, etc. It becomes hard if you want to do this in a plugin, or in several plugins, and developers also have their own customisations. This makes it harder to provide a kind of 'out-of-the-box' plugin. A solution is e.g. to provide traits in the plugin which the developer should implement themselves.

Another thing that crossed my mind - but I didn't test it - is classes that are defined as service with a specific tag, that in a compiler pass are registered on the entity / repository. Then on calling such methods, the __call magic method picks them up and figures out where to call the correct method. But, I think this becomes complicated and maybe not even possible (I think it's hard to combine with Doctrine). So, maybe providing traits is the best in plugins to make things work. Not sure how that makes it very easy testable inside the own plugin.

Regarding the naming, I'm still not a fan of leaving out the 'sylius' name in repositories and plugin namings. I worked on implementing a google tag manager plugin (https://github.com/stefandoorn/google-tag-manager-plugin) and ran into naming issues because the base bundle I used (also OS) was named the same..

Regarding plugins, I think it would be great if there could be QA and screenings from the core Sylius team to improve quality. If they meet certain criteria (also, not too strict, it shouldn't scare people away) plus the core team sometimes contributes even to them to make them better, or reviews them, helps to improve them. That will probably will gather lots of credits in the community and it will create proper plugins that connect seamlessly with Sylius.

[stefandoorn]

P.S. I think lots of people are relatively new to Behat. More emphasises on how to use this properly in plugin development might help also higher adoption of this. It's rather hard to get it working localhost especially. Once working, the coding itself is fairly ok. But getting started was for me at least an huge hassle in my project and didn't even try it in a plugin yet..

[stefandoorn]

Another thing. Sylius is fairly new, using latest technologies and plugin development is only just starting. I'm mainly willing to use PHP >= 7.1 language features, but Sylius does support PHP 5.6. It's a bit painful now to support 5.6 in a plugin and in 6 months to move to PHP 7.x e.g. PHP 5.6 has only active support for the next 4 months (http://php.net/supported-versions.php) so probably it will finish around the time Sylius v1.0 will drop.

It's probably a hard decision, but I would really think about dropping PHP 5.6 en move over to PHP 7. Preferably 7.1, as in 7.0 the optional return types (return null instead of assigned return types) are missing.

[kurakin-oleksandr]

I totally agree with @stefandoorn about upgrading PHP to 7.1.

I didn't understand about overriding entities and repositories. As I know there is no problem to to it via standard Symfony's features.

[kurakin-oleksandr]

@pjedrzejewski I've launched platform for Sylius extensions and within it you already can submit own plugins. After moderation they will appear on website.

Please visit and check it: http://lead-ext.com

We can define group of moderators to verify plugins in admin.
Pros: such system is already created and mainly tested with QA.

Community can focus on acceptance criteria of plugins and documentation

[pamil]

@stefandoorn @kurakin-oleksandr I'm about to open a specific RFC issue about dropping support for PHP 5.6 and/or 7.0, stay tuned! 🎉

[pamil]

Here it is, #8114 :)

[stale[bot]]

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in a week if no further activity occurs. Thank you for your contributions.