Lithium101 is an unofficial community resource for the Lithium PHP framework indexing articles, tutorials, code snippets and libraries.
Tracking 261 plugins, categorised and sorted. If you are the plugin owner you can edit the status and category.
So far there are 54 Lithium related snippets. It's super easy to add your gists as snippets on the site, if there is anything you think might be interesting or helpful take a minute to share it.
In my opinion we should aim for HHVM compatibility while the way being the goal. It'll be hard to get there in 1/2 days. But each step in that direction is good and brings us closer to the goal. davidpersson
There's also #933 which may give some pointers. davidpersson
Last time I tested there was a problem with a method implemented in a subclass of a class that used interfaces. That method had a slightly different signature, which doesn't seem to be a problem with vanilla PHP but with HHVM. https://travis-ci.org/UnionOfRAD/lithium/jobs/22779036 davidpersson
My test case, with a custom stream and including files, seemed to work just fine. I can throw something together probably sometime this weekend. Is this the main reason our tests aren't running? blainesch
I agree @tmaiaroto, extension support is lacking with HHVM. I know I'd personally use HHVM as soon as the support for MongoDB is better (10 Gen is working on it: https://github.com/10gen-labs/mongo-hhvm-driver). As an example, I know Laravel passes 100% of the tests; but I'm not certain of what apps might actually be running HHVM. Like @tmaiaroto said, it all comes down to convenience. Is the gain of using HHVM worth the time to implement? There's always room for improvement in a framework or app's codebase. But, what happens after you've reached your optimization limits? Then, it's down to the compiler or interpreter. Pux looks interesting, and I'd imagine that the HHVM contributors and maintainers keep an eye on things like this. If it's widely used, it's in their best interest to make sure it works. I know Zend has made a pretty big move in PHP performance with 5.5 and OPcache replacing APC. Between 5.5, HHVM, Composer, and FIG; there's a concentrated effort within the PHP community to keep PHP mature and relevant. ericcholis
But what happens if you use any special PHP extensions? Just because the framework is compatible doesn't mean many folks will be able to actually use HHVM due to their own code or other libraries or extensions. What % of us are going to build Lithium apps for HHVM? HHVM sounds neat, but I'm not personally drinking the Kool-Aid until it works more universally and without worry/lots of work. It's a convenience thing. Of course if it boils down to a few minor changes then cool. But I don't know, you start going down that road and you start asking yourself why not just a different language? Speaking of performance concerns... I've been thinking about things like: https://github.com/c9s/Pux for a while. Would that work under HHVM? I'd be curious to see Lithium router performance under HHVM vs. Pux. Routing and bootstrap are among the most taxing areas of any framework and there's soooo much more to be done about performance in a PHP compatible way before jumping to HHVM. Just my two cents. tmaiaroto
@blainesch The streams idea is good. That's how the original template implementation worked. Do you have time to take a crack at that? nateabele
Instead of `eval` would could do a few tricks like saving to a temporary file and including it... maybe we can even use streams? blainesch
If there are a small number of simple, specific fixes that will make it run, I don't mind updating the codebase. nateabele
I agree @jails, HHVM seems to be coming along quickly. Following modern PHP standards should put Lithium in line with HHVM (and vice versa) eventually. ericcholis
Right now HHVM doesn't run any li3 test: https://github.com/UnionOfRAD/lithium/blob/dev/.travis.yml#L29 But imo the question is: "should we code only HHVM compatible code, or PHP code ?" In the last case, I guess we only need to wait for a 100% support of PHP by HHVM. jails
I'm all for it, but I'm not sure we'll pass. I think we still use `extract()` in a few places, and I know `Mocker` uses `eval()`, so that might be a non-starter. nateabele
A pr to point to `lithified.css` sounds like a good idea. blainesch
I forked and amended that. Fix is so trivial, not sure if I should create a pull request. Thanks for tracing that missing css! The whole li3 project seems so quiet. I hope it's because it was done so well that there isn't need for much amendments! It *is* done very well, far as I can tell. Docs not exactly made for newbies, though. hannwong
Yes, it was deleted [here](https://github.com/UnionOfRAD/framework/commit/a088b204b6bb8f2a4afdb34ae5a25919414946f0) as part of the base 'framework'. It appears to have been moved to `lithified.css`. https://github.com/UnionOfRAD/framework/tree/master/app/webroot/css blainesch