Yii Framework 2.0.0 GA | Hacker News Reader

Yii Framework 2.0.0 GA

yiiframework.com

96 pointsthefsb52 comments

> Yii 2.0 helps you to write more secure code. It has built-in support to prevent SQL injections, XSS attacks ...

This is just a minor complaint, but it's so pervasive among web frameworks that I must complain yet again.

According to the documentation for Yii 2.0, the recommended way to output a variable to a web page is:

    <?= Html::encode($var) ?>

Not the PHP standard:

    <?= $var ?>

Because if you do the latter, you will be vulnerable to XSS.

But why does every framework (and many template engines) insist on telling you to call a specific function in the template in order to get XSS protection? HTML escaping should be turned on by default, by whatever means possible.

The simplest template syntax should also be the most secure, not the other way around. Because sooner or later, somebody is going to forget to call that function.

Auto-escaping also saves a lot of clutter in templates, since there are usually only a few places in any given page (usually the content of a post) where HTML content needs to be printed unescaped (but filtered, of course).

Some frameworks escape everything by default and only allow you to print raw HTML if you add a "noescape" flag. This is better, but some of them only do this if you turn on some sort of "autoescape" flag at the top. This is just as bad, since it is insecure by default.

One might point out that not all escaping is the same, since different escaping rules apply in different contexts. But do we really have no way to detect, when parsing and compiling a template, which context we're currently in?

XSS protection in modern template engines should be opt-out, not opt-in. Otherwise they have no right to claim XSS protection as a feature.

Twig, at least, escapes by default. Laravel's Blade templates don't, unless that's changed recently.

But the price you pay for that of course is no longer working directly in PHP but a templating language with its own syntax (for instance, array shorthand in Twig templates [] has worked since I don't know when but only recently has PHP gotten around to supporting it) which has to be parsed, and partially compiled into PHP classes.

Yeah, frameworks that use raw PHP files as views at least have that as an excuse. But the cost of using a simple template engine with good caching support seems to be minimal compared to the benefit of XSS prevention. CodeIgniter, for example, can convert short tags to full PHP tags if short tags are turned off in php.ini. They might as well wrap htmlspecialchars() around every {$var} while they're at it.

Non-PHP frameworks, on the other hand, really have no excuse.

In Laravel Version 5 (due in a month or two), escaping will be on by default.

Yep, and to do none escaped you have to use {!! $foo !!} which at least makes it obvious at a glance as {{{ $foo }}} {{ $foo }} got lost easily.

> but only recently has PHP gotten around to supporting it

You're talking about the `[]` short-hand for arrays, right? That was released in version 5.4, in March 2012, I wouldn't really say that's "recent", at least in my opinion.

It is still relatively recent, if you consider how many older PHP installs are out there. I've had to write around this on a few projects, when I found out my client's server had no idea what the array shorthand or namespaces were.

The cost for auto-escaping everything is too high:

1. You're no longer using PHP. btw., Yii supports Twig that escapes everything by default. 2. Performancewise it's quite a bit hit.

1. Yeah, that's a valid excuse, but only if your framework is written in PHP. So Yii has an excuse, but Django does not.

2. You'll have to escape virtually all the strings that go into the template anyway. So the peformance hit of escaping is almost the same, assuming you don't re-compile the template every single time (which no sane template system does).

I have a lot of fondness for Yii as it introduced me to MVC and moved me from a designer into a developer. When I went on to learn Ruby and Rails everything seemed to click together and I recognised quite a lot of what Yii had taken from Rails.

That said, I get the sweats when I have to wade into an old Yii-powered app that I wrote. Entirely faults of PHP (lack of symbols, array(...) declarations, semicolon-itis) and my lack of experience back then (no testing, fat controllers). I do miss the simplicity of deploying a Yii app, and its speed compared to Rails. The creator, Qiang, is a PHP whizz.

>Entirely faults of PHP (lack of symbols, array(...) declarations, semicolon-itis)

Sorry, but those are entirely trivial syntactic issues, and not very interesting at that either...

Symbols are not a syntactic issue. They are an optimization issue. They do not have the creation overhead of objects and they exist across the application in memory without the lookup overhead of a constant (PHP's closest cousin to a symbol).

Lisp, Erlang, and Prolog (sure some other languages I've missed) have direct equivalents to Ruby symbols; they are sometimes referred to as symbols other times as atoms.

Saying they are a trivial syntactic issue just means you don't understand what symbols are.

It's a bit silly to worry about the overhead of strings over symbols when the PHP environment itself is not persistent across requests.

It adds up. One request may produce millions of such strings. Ruby and especially RoR without cheap symbol lookups would be as fast as a dead fish.

You're not supposed to have "millions of symbols" in Ruby (or LISP for that matter) either.

I mean, you technically could, but it's not what they are used for.

That seems to be missing the whole point of symbols/atoms. They are uniquely identified with an O(1) lookup time and persist in memory after the initial creation. Symbols persist across multiple requests; this is a big part of why they are so beneficial.

I'm not disagreeing with you, but

> Symbols persist across multiple requests; this is a big part of why they are so beneficial.

That is still not really useful, PHP throws the entire execution context away after the request has finished. There is no sharing nor anything to persist unless you're doing so with an external data-store.

Wait, isn't that just if it's used/configured as a CGI? If you use it as a webserver module (Apache/IIS/Lightspeed), the execution environment can persist in a similar way to an app domain, right?

Nope, it's still cleared at the end of the request (as it should be, this is not a bug or mis-feature, and is actually one of the things PHP got right for scalable apps).

What doesn't happen compared to CGI, IIRC, is loading the whole PHP engine from the start for every invocation. But no request specific memory is ever shared between invocations.

The only way to set PHP up as a daemon with shared execution and shared processes responding to requests is to use something like ReactPHP[0] -- even with mod_php, php5-fpm or similar, the execution context is still thrown away. The only difference between that and CGI is that the compiled byte code can be cached and the start-up costs are minimised as the bare interpreter process is kept around.

Shared-nothing turns out to be really nice for scaling web apps. One of the few things PHP got right from the get-go.

[0] http://reactphp.org

Girvo, I was not saying that within the context of how PHP operates symbols/atoms would be beneficial.

The parent stated, "Sorry, but those are entirely trivial syntactic issues, and not very interesting at that either..."

My point was that symbols/atoms are much more than just a syntactic difference and that they are in fact quite interesting. Chicago Boss, an Erlang framework, takes these ideas to an extreme to push the limits of shared immutable memory on a web server.

http://www.chicagoboss.org/about.htm

I'm not a big fan of the way he trashes pretty much every alternative at the beginning of his description; there are many web frameworks built on many different languages that the market has proved out are sufficiently scalable.

It is however an interesting and different approach that I think we can both agree goes far beyond "trivial syntactic issues".

Ruby only needs symbols because it made the questionable choice of using mutable strings with by-object semantics. PHP does not have this problem. It will automatically intern literal strings, thus giving you the performance and memory usage benefits of symbols, but without the crutch of requiring a special syntax for them.

I think that special symbol syntax is nice, since it has additional semantic meaning in the form of "this data type here is used to represent a flag, not a piece of text".

Granted, Ruby's use of symbols is not as pretty as other languages...

Out of all the PHP frameworks I've used (CakePHP, Kohana, Laravel, Symfony) I have to say Yii is the one of the best.

It's hard to describe why, I think mostly because it feels like it was built and designed by one person who had a lot of experience with other frameworks and knew PHP inside and out.

I agree. The only issue I had with it is that it returns records in an array instead of a Rowset object like Zend Framework. But it contains much less of the verbosity than Zend and is much easier to use and separates things like validation and authorization in a much more elegant way.

Never was a fan of Yii myself. The one PHP framework I really do like though is the Fat-Free Framework.

FFF is pretty rad, as is Slim framework. I like Slim so much I've been cloning it for Hack[0]. With the next week off work, I'm looking forward to getting it close to parity!

[0] https://github.com/LeanFramework/Lean

Cool. My personal preference is towards these leaner micro-frameworks in general. I've looked at Slim, seems cool, but never worked with it. Good luck on your project.

>Yii 2.0 helps you to write more secure code. It has built-in support to prevent SQL injections, XSS attacks, CSRF attacks, cookie tampering, etc. Security experts Tom Worster and Anthony Ferrara even helped us review and rewrite some of the security-related code.

+1 for opinionated security at the framework/platform level rather at the programmer level, such that security features can be evolved, refined, debugged over time and pushed back upstream, rather than reimplemented from scratch each new project.

I'm a Yii fan but it takes some time learning the "yii" way of doing things i.e. structure, naming conventions. I decided to move on though because the community and module ecosystem are small.

Same as me. I relied on it heavily around 2010, but their glacial development made Symfony a better choice in 2012.

You've meant "were small in 2008"?

If you're serious about web development in PHP try Yii, chances are good you'll fall in love! If not love at first sight, give it second chance. It's really good inside :)

You can jump start using the new app templates:

1) https://github.com/yiisoft/yii2-app-basic - simple app

2) https://github.com/yiisoft/yii2-app-advanced - if you need multiple interfaces (frontend/backend/api)

If your namespaces are all lowercase after adopting PSR standards, you haven't really adopted the PSR standards.

Why?

PSR-4 does not require any case for namespaces:

> Alphabetic characters in the fully qualified class name MAY be any combination of lower case and upper case. http://www.php-fig.org/psr/psr-4/

none of the PSRs specify that the namespace name should be capitalized.

Currently I working into the Cakephp and Django framework. Now I wanna to work in yii. which is the best between Yii and laravel in large concept application. anyone tell which is best framework for large application in Cakephp, Yii, laravel. please describe.

What do you mean by large _concept_ application? If you mean large or famous projects in production, Yii 2.0 was just released so there aren't many.

For 1.1 there are some:

https://www.facebook-studio.com/, http://2gis.ru/, http://itop.fm/, https://www.humhub.org/, http://www.x2engine.com/, http://zurmo.org/, https://www.rebilly.com/, http://buildwithcraft.com/

Yii 1 is one of the best framework i used.

Currently i'm working with Yii 1. Its good to know that Yii 2 is released. Thanks to all Yii Team!!

This is great news.A lot of thanks to YII Dev team for making the magic happen!

YII is awesome and speedy framework to build. I love to work. I yet to start 2.0.0

Really it is awesome and very quick.. I love to work

vs. Laravel? anyone?

A matter of taste. Try both and see which one you like best for yourself.

Agreed. They are both solid frameworks and I've used both fairly heavily. I personally find Laravel more 'natural'. I have to refer back to the documentation in Yii far more often.

I would also here some experts opinions on this. How do they compare on a higher level. Say a RESTful API with JSON+HAL, HATEOAS approach, Versioning, etc. the full thing for a bigger usecase like Twitter, Tumblr, Facebook, etc.

Comparing to Facebook and Twitter is a useless comparison, because their scale causes so many edge cases. If you have that kind of scale, you can afford to hire the best in every area and build everything from scratch. Better to compare to a typical medium-sized website in a similar sector - e.g. a blog like cuteoverload.com or ecommerce site like tigerdirect.com.

I can persuade you to use any of these two frameworks providing lots of arguments but I prefer not to do so. Try both yourself else you'll be wondering if you've made the right choice while working with one.

Yii, feels more complicated, and rough around the edges to me...than laravel... There's just a lot of things that make sense to me in Laravel.

Yii is actually incredibly polished, it's not rough around the edges at all. It is not particularly easy on newcomers though, which is the main reason it's not more widely known.

If you put the effort in to learn it thoroughly, you'll be rewarded with an incredibly productive platform that is great not just for getting apps out of the door super quickly, but also provides a secure, scalable foundation which is easy to grow and maintain.

Reply on news.ycombinator.com