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.
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
I personally use the lithium autoloader for lithium itself + all lithium libraries. For all the other ones I'm using composer. davidpersson
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
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
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
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
@davidpersson it is really bad when you link from packagist to wrong website. Anyway it is upto you :) . harikt
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
Oh, I didn't see that. Bummer =( tmaiaroto
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
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
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