Lithium 101

Lithium101 is an unofficial community resource for the Lithium PHP framework indexing articles, tutorials, code snippets and libraries.

Libraries

Tracking 261 plugins, categorised and sorted. If you are the plugin owner you can edit the status and category.

Snippets

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.

Latest Activity

16 hours ago hansott started watching UnionOfRAD/lithium

UnionOfRAD/lithium currently has:

nateabele/li3_resources currently has:

2 days ago bobnelson0 started watching UnionOfRAD/lithium

UnionOfRAD/lithium currently has:

2 days ago pavelkarkh started watching UnionOfRAD/lithium

UnionOfRAD/lithium currently has:

Acl

DRAFT prototype of ACL from CakePHP any suggestion ?
5 days ago SergeyBuchchenko started watching UnionOfRAD/lithium

UnionOfRAD/lithium currently has:

6 days ago DrRoach forked UnionOfRAD/lithium

UnionOfRAD/lithium currently has:

UnionOfRAD/lithium currently has:

6 days ago DrRoach started watching UnionOfRAD/lithium

UnionOfRAD/lithium currently has:

UnionOfRAD/lithium currently has:

6 days ago DrRoach forked UnionOfRAD/lithium

UnionOfRAD/lithium currently has:

6 days ago davidpersson closed an issue in UnionOfRAD/lithium

lithium\net\http\Message::body() removes too many vars

I am using Lithium's HTTP Service class to PUT data to an API, the data in case is: ```php // To activate $data = ['active' => '1'] // To deactivate $data = ['active' => '0'] ``` When I sent the request to activate everything worked as expected, however, when I sent the request to deactivate I noticed there was no data ending up at the API at all. I traced where it was getting removed to the ```lithium\net\http\Message::body()``` function. There is a call to PHP's ```array_filter``` function that was removing any falsey values from the data array. I would have thought there would be use cases for pretty much every type of variable to be kept in the data array. So I'm not sure if filtering the array would be correct at all. My solution would be to either remove null values only: ```php $body = $this->body = array_filter( array_merge((array) $this->body, (array) $data), function ($var) { return $var !== null; } ); ``` Or to completely remove the ```array_filter``` call altogether: ```php $body = $this->body = array_merge((array) $this->body, (array) $data); ```
6 days ago davidpersson created a comment about an issue in UnionOfRAD/lithium

lithium\net\http\Message::body() removes too many vars

Thanks for the detailed bug report. This has already been fixed in the dev branch by f8a8c7d543eaf0fc83ec6b1f3d4ec58d36daa1cd. If possible please switch to that branch. davidpersson
7 days ago davidpersson created a comment about an issue in UnionOfRAD/framework

No more submodules, composer instead.

I personally use the lithium autoloader for lithium itself + all lithium libraries. For all the other ones I'm using composer. davidpersson
7 days ago jasonroyle opened an issue in UnionOfRAD/lithium

lithium\net\http\Message::body() removes too many vars

I am using Lithium's HTTP Service class to PUT data to an API, the data in case is: ```php // To activate $data = ['active' => '1'] // To deactivate $data = ['active' => '0'] ``` When I sent the request to activate everything worked as expected, however, when I sent the request to deactivate I noticed there was no data ending up at the API at all. I traced where it was getting removed to the ```lithium\net\http\Message::body()``` function. There is a call to PHP's ```array_filter``` function that was removing any falsey values from the data array. I would have thought there would be use cases for pretty much every type of variable to be kept in the data array. So I'm not sure if filtering the array would be correct at all. My solution would be to either remove null values only: ```php $body = $this->body = array_filter( array_merge((array) $this->body, (array) $data), function ($var) { return $var !== null; } ); ``` Or to completely remove the ```array_filter``` call altogether: ```php $body = $this->body = array_merge((array) $this->body, (array) $data); ```

UnionOfRAD/lithium currently has:

7 days ago tmaiaroto created a comment about an issue in UnionOfRAD/framework

No more submodules, composer instead.

Yea, I'm curious if that should be the case here or if the PHP code should be updated to look for lithium under ```libraries/unionofrad/lithium``` instead. That's kinda the thing with setting it manually without this repo...It's very easy to adjust that path without affecting anything else. It would be under your own repo. tmaiaroto
7 days ago alexbowers-tecmark created a comment about an issue in UnionOfRAD/framework

No more submodules, composer instead.

This is very similar to what it appears your blackprint uses, however; because of the way it is set up, composer pulls in with the git username / repo-name, which is not the setup that lithium likes. To combat this and make the changes easy for end-users to get started, all this does differently is run a few commands after the fact to move lithium from libraries/unionofrad/lithium to libraries/lithium which is what it expects to receive. alexbowers-tecmark
7 days ago tmaiaroto created a comment about an issue in UnionOfRAD/framework

No more submodules, composer instead.

Many folks use Composer with Lithium already. Myself included (despite not liking it, I'm not exactly going to write my own right now). I'm not sure how many people use this repo (or with Composer). This was made, more or less, to be a quick setup/intro/skeleton. Personally, my Composer always pulled from the other repo. You can see my incomplete CMS project here: https://github.com/tmaiaroto/blackprint That said, I'm not sure what possible deployment goals were in mind. Submodules may work better in certain circumstances. Obviously many build systems are able to run Composer, but I'm not sure the scope of this repository. I imagine there's a chance this will be merged depending on the goals of this repository. To be frank, I don't think this repository gets much love these days. tmaiaroto
8 days ago alexbowers-tecmark created a comment about an issue in UnionOfRAD/framework

No more submodules, composer instead.

Is there a chance of this being merged in then? Or should I keep it as a separate repository for anybody that wishes to use composer? alexbowers-tecmark
8 days ago harikt created a comment about an issue in UnionOfRAD/lithium

Fix the link. We should not market the other website.

@davidpersson it is really bad when you link from packagist to wrong website. Anyway it is upto you :) . harikt
8 days ago disem started watching UnionOfRAD/lithium

UnionOfRAD/lithium currently has:

8 days ago davidpersson created a comment about an issue in UnionOfRAD/lithium

Fix the link. We should not market the other website.

Thanks for the patch @harikt. We should indeed not market "the other website" :) However this has already been fixed in the _dev_ branch (our integration branch, see http://li3.me/development "Branching" for more info). Changes from dev will merge to master in some time. I'm closing this ticket for now. davidpersson
8 days ago tmaiaroto created a comment about an issue in UnionOfRAD/framework

No more submodules, composer instead.

Oh, I didn't see that. Bummer =( tmaiaroto
8 days ago alexbowers-tecmark created a comment about an issue in UnionOfRAD/framework

No more submodules, composer instead.

On a side note; related to bowerPHP. This is something I hadn't seen before, but I have to say, the fact that BowerPHP is pulled in by Composer doesn't give me great hopes for the project on its own. alexbowers-tecmark
8 days ago alexbowers-tecmark created a comment about an issue in UnionOfRAD/framework

No more submodules, composer instead.

I agree that the autoloader is overkill for what Lithium needs (since it has its own in use already); which is why the package I have provided has to rewrite the location of lithium to be a directory lower. This isn't really much of an issue, but it is rather annoying. But gets around needing to try to get the lithium library working. alexbowers-tecmark
8 days ago alexbowers-tecmark created a comment about an issue in UnionOfRAD/framework

No more submodules, composer instead.

Glad to have another on board. Still working on a solution to _nicely_ generate the Libraries::add() stuff from composer, though may not be possible without a lot of abstraction and assumptions. Would be nice, since then the only requirements to get something like li3_quality in would be composer alexbowers-tecmark