Better Support For Extensions With Yii 2?

Hi everyone,

I was just browsing through the (official) Yii extensions repository and thought: what a mess. There are currently a lot of issues:


[*] There aren’t any coding standards for writing extensions.

[*] Source Code is hosted anywhere. Some people really release on others have ancient versions in the database here and refer to some Github or GoogleCode page where the source locates.

[*] Issues and problems are the same story. Some are in the comment section for the extensions, some are in the forums here, some are on GitHub issue tracker, …

[*] Contribution is hardly possible. Most extensions are released under a license that allows contribution, however on this site it is made extremely hard. As (I think) only the creator of the extension can make changes to it, some (good) extensions can’t be driven further, because the creator is gone, not active anymore, or doesn’t want to maintain it anymore.

[*] Many extensions for the same job. Just look at category "mail" in the extensions repository. Nearly each extension does the same thing. Two of the three most popular extensions (mailer + yiimailer) are actually wrappers for the very same class. I think this is mainly because of #4 (participation is hard).

[*] Most of us don’t earn money directly with Yii itself, so few want to maintain extensions forever. Maybe a few volunteers or parts of Yii core team can maintain them, so that bugs that are known for years don’t stay unfixed. Right now after downloading an extension I first read all the comments if there are bugs that haven’t been fixed yet. Maintaining extensions with little activity also takes no effort, but if someone wants so submit a Patch/Pull Request it would be cool it could be applied.

[*] Enforce basic information such as demos (at least screenshots or something) and put it in a more prominent place. Especially in UI (which currently make up about 40%) this should be a must.

[*]Composer support. This has been discussed a lot for Yii 2 core and it should also be there for extensions. This even alleviates #7 a little bit, since testing on your own can be a lot faster.

[*] Politics. Mention extensions somewhere in the guide or some place. Take a extension like Giix for example. You can make your extension perfectly fine without it, so you probably won’t search for something like that. When you stumble upon it some day, you probably have created all the models and CRUD. This practically makes Giix only usable from project 2 onwards. Why don’t tell this to people BEFORE they struggle to make their applications with plain gii?


Open for discussion. Obviously,not all of you will agree on everything, but most people will agree that some changes should (must) be made.

P.S.: Yes, I know, there is However, I think many people do not as it isn’t actively promoted anywhere here. (Probably because it’s inoffical. Also see #9) This actually would help on quite a few points.

I highly doubt anybody will come with a good solutions to points 1, 3, 4, 5, 6 and 7. Those are really generic topics that bother every project and require discipline from the extension authors. You just need to help users to quickly judge which extension seems better than the others.

I’ve developed 4 extensions by now and can speak from my own experience.

Yesterday I just finished my first demo, after a year of publishing my first extension. This is really harder to do that I thought, I mean in time matter.

I decided to make my extensions after doing them for myself and then thinking that’s pretty cool and others could benefit from them. But there’s a long way from ‘mine’ to ‘generic’. I think most extensions are born this way. They start in a semi-usable state, wait for feedback and if there is to little they freeze in that state. But we can’t filter it too hard, because that will kill the good ideas.

I must say that github+composer combo feels almost perfect and updating extension page on Yii is a drag after that.

That’s an idea for a Wiki article, but I do feel it’s gonna get lost after few new ones appear.

As for number 9 I really don’t think that ‘struggling’ here is the bad part. At least you learn how the framework works. You also learn what makes up a good CRUD, what you miss after building your first one. Even if you build your own generator and later discover giix or anything else you can compare them and learn a lot more.

I stumbled on giix pretty fast and built my own anyway.

Getting handled only the good stuff makes you lazy. If you have to compare solutions you learn what you really need. You learn how to read code fast. You learn about bad and good practice. Your own code will improve.

In conclusion, I think the only thing that could and should be done is to make a good catalog and a guide. What we are missing now is a guide and maybe some improvements to the catalog.

Yeah, we’re aware of these and will try to solve them after 2.0 release.

  1. I will write extension developer guide.

  2. Source still be hosted anywhere but extensions will be installed via Composer.

  3. We will suggest github/bitbucket and will direct users there for issues.

  4. Have you tried contacting original author? I did and it went well in most cases.

  5. We can’t stop people from creating duplicating code but I’ll mention it in the guide.

  6. We can’t do so. That will require too much time and we’re working on Yii in our spare non-paid time as well. There will be some officially supported extensions though.

  7. Will add suggestions to guidelines.

  8. Planned.

  9. Plain Gii is fine, isn’t it? ;) I plan mentioning extensions in the guide if appropriate.

I know extension developing is a hard task and I also see that generic solutions are quite hard to do. This is why I think contribution is so much needed. I think there is actually no extension here that forks another one. If it’s a good idea but inactive, someone might do a new extension: usually starting from scratch.

Sure, not every one wants to create extensions, but you can make it more attractive. If you can save time because you get a nice fully-fledged calendar from the extensions, you could use it to do (for example) an RBAC/auth-extension. The main argument here is that if you write an extension it is not only reusable for other, but also for yourself. Overall again saving you time.


  1. No, actually I didn’t. Also I did not run across this recently, but I’ve seen it quite a few times.

  2. I think that goes hand in hand with better information about extensions. Since extension development takes some time, most people won’t do another extension, if they know such thing already exists.

  3. Then volunteers or something. It’s just a pity to see (good) extensions go inactive and all the participation is in vain. And seriously: If I want to use an extension and found 1 small bug in it, but the extension is inactive, what can I do?


[*] Simply post it in the comments.

[*] Fork the extension, fix the bug and be the new maintainer. This is a lot more work, they themselves have no advantage, so people don’t do this, but do #1.


  1. Yes. I just wanted to point out that there are a couple of extension (debug-toolbar would be another) that you want to find in the early stages of your project and not when you finish is.

Oh and that Composer/GitHub thingy is nice to hear. :)

@Tropi: Glad you raised the topic.

Hopefully I’ll find some time for a detailed answer, but in the meantime I am throwing this link in here, so it may not be forgotten ;)

It contains some rules and guidelines for extension development.

Note: my wiki fork is a proposal.

@samdark: One more thing … please find a way to just use one place to maintain your extension info, the repo itself.

It’s such a pain to always update the extension page.

I also thought about a some kind of checklist or codestyle-rating for extensions, the more rules you follow the more points the extension gets.


That’s the whole idea that website should ask for repo URL only and grab the rest from and composer.json.

Checklist is an interesting idea.

Conventions for naming of the repo, composer package and PHP namespace would also be nice.

Eg. Foo Vendor publishes Bar-Package

Repo URL: no restrictions


Composer Package: lowercase, do not use yii-

eg. foo-vendor/bar-package

Namespace: headlessCamelCase

eg fooVendor/barPackage

Composer Package and Namespace SHOULD match, so they can be auto-converted.


I don’t agree that the composer package should not contain a yii prefix. Composer is public, not limited to Yii. How others should know that a specific project wont work with other frameworks? And if somebody is looking only for stuff specific to Yii? A name is really a good first filter.

I see the problem with keeping it in sync with namespace though.

It is to be discussed … composer has a type field which could be set to yii2-extension to filter the results.

Otherwise you’d have “yii-” in every vendor folder in your Yii application, which is also not ideal.

I’m thinking if I should create links to the vendor directory contents and stop using it directly. I got used to keeping everything at its place, like modules and extensions in a separate directory. So I could just remove the prefix in the link name.

Hmmm, I see no benefit. Separating modules and extensions was not good decision anyway - IMHO.