Ok first off apologies if this seems like a silly question but I'm actually having a hard time finding the answer, even on Ellislab's website and Google.

In ExpressionEngine 2.x it used Codeigniter as the framework. There was a directory containing the framework files and you could use features of Codeigniter within EE projects.

I'm just building a site on EE 3.3.1 and can't see any such directory in 'system' or it's subdirectories. Is there an underlying framework that can be used?

The reason I ask is because a lot of plugins don't seem to have been updated for EE 3.x compatability. I'm wanting to develop something to send an email and in 2.x I would have used Codeiginters features to do this.

So, is EE 3.x using Codeigniter and if not is there a framework that can be accessed, e.g. by using PHP in templates and then getting an instance of the framework?

Edit (15 Nov 2016) - this post seems quite frequently viewed. If anyone has any examples or information about how they've written custom PHP on an ExpressionEngine 3.x site please post it as an answer. The lack of a documented framework, or having to rely on one that might get removed, is a major issue for anyone doing custom PHP development on EE 3.x sites. Ellislab should really comment on this.

2 Answers 2


Yes and No.

Starting from v3, EE is gradually moving away from CI. This isn't happening all in one go, but as major versions progress. CI is still there, but it's all tucked in the legacy directory, along with old, non-ported libraries and such.

What is EE moving to? Not another framework. So no CI, Laravel, Yii or something similar. Rather, EE will be its own framework.

So, for now, EE is using both CI for "legacy" stuff, and its own set of libraries/models/whatnot for the new stuff. As a general rule of thumb, the difference in syntax is:

// Legacy

// New

EE3 does not use Codeigniter - but it is indeed hard to find the information online: if you want confirmation contact Derek Jones at EllisLabs (e.g. via EE Slack Channel - eecms.slack.com)

EE3 is a major rewrite but a consequence is that it has broken a very large number (perhaps all) of EE2's add-ons and extensions.

EllisLab perhaps were not so good at managing this transition, and possibly launched the product too soon - some key add-ons had to wait for hooks and patches to be added to EE3.1 before they could migrate - so the transition has been bumpy.

The work required to rewrite complex add ons for EE3 is non-trivial - some vendors of well used EE2 add ons have said they are not supporting EE3 (e.g. P+T who wrote Matrix, Playa), while the work on others is promised but taking a very long time (e.g. Assets, Publisher, Structure, CE-Cache).

EllisLab has provided a good utility to migrate EE2 Matrix / Playa fields to EE2 built in equivalents fields (Grid / Relationships), but that's it for migration support from there.

There are some lists of EE3 compatible add ons around - e.g. look in EllisLab's blog list (https://ellislab.com/blog/entry/expressionengine-3-add-on-developer-update-status) or on Devot-ee.com which now has an EE3 tag you can search on - https://devot-ee.com/add-ons/filter?&f=ee3

  • Thanks for the information, very informative. In this case all I'm wanting to do is write some PHP, within a template (obviously done the usual things like set PHP parsing on it). In EE 2.x I could grab an instance of Codeigniter and enjoy the functionality it provided. I guess my question is - what's the best approach for EE 3.x? It sounds like there's no way of accessing a framework as such, so should I just go down the "vanilla" PHP route of writing everything from scratch? Seems incredibly tedious as that was largely the point in having PHP frameworks - to reduce such development.
    – Andy
    Commented May 20, 2016 at 10:07
  • 1
    Hi - I'm not expert on this - but as far as I can tell EE3 provides a useful environment for using PHP as extension to its core functions - but as with EE2 the idea of adding PHP to a template is not encouraged (due to security risk associated with power of PHP being accessible to anyone who has access to the template). A better route would be to put your PHP within your own add-on - then you can access the PHP via a tag, without exposing PHP to template editors. Commented May 20, 2016 at 12:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.