Having is possible in a query, but there is no documentation for it.

There is no current explanation of how to take an application and make it a plugin, or how to start a clean plugin from scratch (and how to integrate it with your existing apps).

This is a combination of several inputs to improve the manual.

Some general problems identified in the manual:

• Choice of categories/Ordering of concepts - Concepts are introduced in a fashion that did not correlate to my(Tomen's) learning curve. There is some jumping back and forth to understand everything. Others have suggested, that some categories are not focused enough, badly named or that they could be ordered better.
• Number of categories that must be traversed to get to a page
• Lack of detail in the most important areas
• Search is non-existant
• Redundancy: Concepts that are exclusive to lithium are explained on a lot of occasions. Filtering for example is used in unrelated sections where a filter is just used. This is to make sure that everyone gets the concept, but a simple link would be sufficient.

Overhaul of the general structure/flow:

Basically, i suggest to restructure the manual to give it some sort of onion structure: You first have some easy and basic parts in the beginning, like Quickstart and Getting started. I suggest to merge Configuration chapter into Getting started, since both are about getting Lithium to run in the first place.

Then we move on to the core Lithium concepts, like MVC, Request/Reponse-cycle, Filtering and stuff, wich i would like to put in a chapter named Lithium design. This chapter is for all abstract content.

Then for actually using Lithium, there are the chapters Basic tasks and Advanced tasks. Basic tasks covers everyday tasks in lithium, while Advanced tasks covers topics not everyone may be interested in.

This structure would reduce the number of top-level chapters and ease understanding of where to look up what.

• Quickstart
• Getting Started
  • Requirements
  • PHP
  • Servers
  • Install Lithium
  • Connections
  • Troubleshooting
  • FAQ
• Basic Tasks
  • Create an action (Practical overview over MVC)
  • Working with views
  • Working with controllers
  • Working with models
    • Using data sources
    • Using models
    • Validation
    • Relationships
    • Adding Functionality to models
    • Creating data sources
  • Add a route
  • Add user authentication
  • Globalization (alternatively: Internationalization)
• Lithium Design ( Feature overview: merge all the cool PHP 5.3 marketing into this)
  • File structure
    • Webroot
    • Resources
  • Config
    • Bootstrapping
    • Connections
    • Routes
  • Object
  • MVC
  • Request/Response cycle
    • Overview
    • Controllers
    • Views
    • Helpers
  • Filters
  • Libraries
  • Extensions
  • Quality Code
    • Coding Standards
    • QA: static code analysis
    • Unit Testing
• Advanced Tasks
  • Create a Plugin
  • Use third party libraries
  • Lithium in the cloud
  • Using Lithium in other applications

Other issues:

• The landing page http://lithify.me/docs contains the four categories lithium, li3_docs, li3_bot, manual. This can confuse new users who actually want to read the manual. A first step could be to make the manual appear on top, have it selected by default and comment on the reference chapters what they stand for (doc-plugin, bot-plugin, lithium-core)
• The comlete TOC should be displayed, so that the user can jump into every section at every moment.
• For buckets of good karma, implement search

continue witch @daschl discuss agborkowski/li3_rest@30ffd53#commitcomment-824106

On The Page http://lithify.me/docs/manual/configuration/servers/nginx.wiki

The Line:
try_files $uri $uri/ /index.php?$args

Should Read:
try_files $uri $uri/ /index.php?url=$uri;

This is a pretty key feature of the framework, but was constantly changing - now hopefully it can be stabilized and documented.

The point of set_state() is really more about serial/deserialization rather than testability. This needs to be changed in the arch guide.

many links from google end up in an empty page:
http://li3.me/docs/book/manual/1.x/views/views

There could be a redirect to
http://li3.me/docs/book/manual/1.x/views

Not really documented in detail, is also a killer feature of the framework.

Looking at code examples on pages such as http://li3.me/docs/manual/model, the indentations have disappeared!

The link "PHP Standards Working Group namespace standard" on New in PHP 5.3 doesn't work because the document has been moved. The new document seems to be here: https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md

We should document this as an advanced case in the Model/Data Retrieval page.

See UnionOfRAD/lithium#1276
See https://github.com/UnionOfRAD/lithium/blob/1.1/CHANGELOG.md#fixed-1 under "Fixed undetected buggy behavior in ..."

http://lithify.me/docs/manual/configuration/servers

i would like to have an manual for the builtin webserver of php: http://php.net/manual/en/features.commandline.webserver.php

Please update the manual from li3.me to the last version of this repo.

The li3.me/docs/manual version is really old. For instance check it out: http://li3.me/docs/manual/quality-code/lithium_qa.wiki and then check this: https://github.com/UnionOfRAD/manual/blob/master/en/quality-code/li3_qa.md

I highly recommend re-working the docs to organize and prioritize similar to how codeigniter does (http://codeigniter.com/user_guide/ - click on "Table of Contents" at top of page). Notes of things to emulate:

• flat: from the first page, you can jump immediately to every page in the manual.
• organized: toc is broken into several broad categories, each of which is immediately obvious in value (like "Installation", "Tutorial", "Class Reference", etc.)
• well-labeled: in the TOC, each page is also well-labeled, for example "Installation Instructions", "Controllers", "HTML Table Class", "Date Helper".
• the whole thing is searchable.

Problems with the current Lithium documentation organization:

• choice of categories
• number of categories that must be traversed to get to a page
• ordering of information
• lack of detail in the most important areas
• search is non-existant

Beginning on the very first page (http://lithify.me/docs):
On the left is "Libraries" as the header, then lithium, app, li3_docs, li3_bot, manual below it.

• What would a user expect to find under the "lithium" category? Isn't this the lithium site?
• what does "li3_docs" mean? Lithium is li3, so maybe li3_docs is the docs?
• what does "li3_bot" mean?
• what is the manual and why is it different from li3_docs?
  After a lot of probing, the user finds that the docs are actually in the last choice "manual". Since this is the "docs" section, all the other stuff should go elsewhere. I.e. clicking "docs" on the home page should go to the manual.

In the TOC of the manual, the sections are: Quickstart, Getting Started, Lithium Basics, Configuration, Writing Quality Code, Handling HTTP Requests, Working with Data, Authentication, Globalization, Extending Lithium, Lithium in the Cloud and Appendices. Of these, only "Quickstart" is intuitive.

Some specific examples of problems:

• "Getting Started" is another way of saying quickstart, but it's really the Installation section (So "Installation" is a better name.)
• "Lithium Basics" is badly named; it's really a combination of architecture, what's new, and aspect oriented programming. These aren't "basics"; these are things you may want to know after you get going. Also, the "architecture" section should be several sections, each in an appropriate category. (info on connections say in a data section; info on tests in say a test section, etc.)
• configuration section is good
• quality code: well, I'm all about that, but why is there more documentation on coding standards then there is on most of the basic functionality? And why haven't we gotten to the basic functionality yet? Bear in mind that because the TOC topics are so confusing, the whole doc is really one big serial doc. I.e. the early user really doesn't have a way to jump some place useful, so they read it one section after another (but having to dig 3 or 4 layers down to hit a page, then back up). So seeing coding standards before you understand details of building a controller is problematic.
• handling http requests: another advanced concept before we get to details of how basic functionality works. Same thing with routing. Only as a subsection of "handling http requests" are controllers, views and helpers introduced. These should be higher level and earlier. And since there's no search, hiding them beneath a name like "Handling HTTP Requests" is ugly.
  • Working with data is a reasonable name. I think I'd put "Using Data Sources" in more of an installation section, but that's a debatable point. The rest is good. maybe move "creating data sources" to an advanced section, but that's also debatable.
  • Globalization: I've never heard the term, and thought it might have something to do with global variables. recommend changing to the more standard "Internationalization"

gwoo pointed me to this sample code: https://github.com/pointlessjon/sphere

It's actually the most useful doc I've seen so far. Sorry to be blunt, but it was more useful than the whole existing manual. I recommend putting a link to this code prominently on the web site, including on the first page of the manual.

Hello.

I have installed the framework like instructed here: http://lithify.me/docs/manual/getting-started/installation.wiki

My server is running under a virtualbox machine with archlinux on it as guest. The httpd daemon is nginx + php-fpm 5.5.6-1.

I have configured the nginx server section as instructed here: http://lithify.me/docs/manual/configuration/servers/nginx.wiki, my webroot is set to /srv/http/li_framework/app/webroot/.

The lithium framework was installed using the git commands as instructed on wiki.

When I access my web server using localhost:8080, i get this errors:
http://pastium.com/view/4e308fe3e0a174b6224b2116eedb5acb

All the files from the li_framework dir are owned by the http user and group. I don't understand why I get that errors, how can I solve them?

I've removed this to quicken the restructure being moved back to master. I'm adding this issue so the good ideas here don't get lost.

50748b3

What happened:

• im taken eg. from @link http://lithify.me/docs/manual/02_lithium_basics/02_filters.wiki
  /.../
  if (isset($ctrl->publicActions) && in_array($params['action'], $ctrl->publicActions)) {
  return $ctrl;
  }
  return function() use ($request) {
  ^^^^^^^^^
  return new Response(compact('request') + array('location' => '/users/login'));
  };
  /.../
• put this to auth.php (full code) @link http://pastium.org/view/4a35aeb1bf856634d7185df9709628ad
• every request to app throw notice
  -( ! ) Notice: Undefined variable: request in /home/agborkowski/Sites/holicon/pwi2/app/config/bootstrap/auth.php on line 32
• Catchable fatal error: Closure object cannot have properties in /home/agborkowski/Sites/holicon/pwi2/app/config/bootstrap/action.php on line 61

i reset to HEAD action.php and modify filter:

https://gist.github.com/1064588

now its work better but
im not sure from come $request is.
$request is set by Auth::check('default', $this->request); in UsersController->login() ?
but why eg from manual don't wanna work without my isset workaround.. ?

I wanted to try out this framework. As the manual recommends, I did this:

$ composer create-project --prefer-dist unionofrad/framework project

Could not find package unionofrad/framework with stability stable.

It's fine if the project doesn't have a stable tag, but you should modify the manual to reflect the correct installation method.

For the moment, I use:

$ composer create-project --prefer-dist unionofrad/framework:dev-master project

These paths should be included in manual, extending lithium section though.

Sometimes especially adapter paths can become confusing.

In the manual, examples are given for how to link javascript code from a remote server here:

http://lithify.me/docs/manual/handling-http-requests/views.wiki

however; the API here has no examples at all for using the script html helper:

http://framework.local/docs/lithium/template/helper/Html::script()

My suggestion would be to add a couple of the examples in the manual to the API docs.

The link for installation in the sentence "If you haven't already installed one then check out the installation guide in this manual" is broken and leads to a 404 page. It's in the first paragraph under the heading "Setting Up".

Currently the link is: https://github.com/UnionOfRAD/manual/blob/master/en/quickstart/installation
It needs to be:
https://github.com/UnionOfRAD/manual/blob/master/en/installation

Typo in cache config examples where "Memcached" is written instead of "Memcache" on the website and here. "Memcached" does not seem to work.

For instance:

https://github.com/UnionOfRAD/manual/blob/062a85b2823fd06c1e28bb13381742c59b2e6574/09_common_tasks/05_caching.md#configuration

I was creating a plugin so that I can communicate with a legacy API so I was reading up on Creating Data Sources.
It talks about using item() but it seems like the use of item() is deprecated.

This was brought to my attention by Mehdi (mehlah?) in this post at StackOverflow: Overriding data\Source::read() and using item() gives me incorrect results

Also, I ran into an error using the code from doc. For dependency injection, it defines service, entity and set for $_classes. However, I believe we also need to add 'schema' => 'lithium\data\DocumentSchema' because without that, I get the following error:

Fatal error: Uncaught exception 'lithium\core\ClassNotFoundException' with message 'Class `schema` of type `` not found.' in /var/www/lithium/clean/libraries/lithium/core/Libraries.php on line 693

lithium\core\ClassNotFoundException: Class `schema` of type `` not found. in /var/www/lithium/clean/libraries/lithium/core/Libraries.php on line 693

Thanks guys, I love this framework so much that I voluntarily break rest just so that I can mess around with it :)

The path, manual > architecture > File Structure > Libraries, has the following line,

Any plugins you download from the Laboratory, or pull down via the Library li3 command should end up here.

The hyperlink 'Laboratory' is broken.

The page Creating a user in M, V, C describes how to add a filter to the user model so it saves the user's password using \lithium\security\Password::hash(). This is fine, but then Simple Authentication continues by using the \lithium\security\auth\adapter\Form, which uses String::hash() (i.e., sha1) to hash passwords.

Thus, if one was to follow the procedure in order, one would end up with a system that does not work because of the different hashing functions.

Either both should use String::hash(), or Simple Authentication should describe how to use \lithium\security\Password::hash() and \lithium\security\Password::check(). The later combination is more secure, that would be my preference. Of course that's just a personal preference, feel free to disagree :)

An example of a working Adapter (that just overrides the check method of the Form Adapter) would be:

<?php

namespace app\extensions\adapter\security\auth;

use \lithium\security\Password;

class PasswordHashedForm extends \lithium\security\auth\adapter\Form
{
    // We don't need to hash the password, so don't use filters
    public $_filters = array();

    /**
     * Check if the supplied credentials are okay
     */
    public function check($credentials, array $options = array()) {
        $model = $this->_model;
        $query = $this->_query;
        $conditions = $this->_scope + $this->_filters(array_map('strval', $credentials->data));

        // do not include the password in the query ...
        unset($conditions['password']);
        $user = $model::$query(compact('conditions'));

        // ... instead verify the password using the Password class
        if (Password::check($credentials->data['password'], $user->password))
            return $user->data();
        return false;
    }

}

?>

After fiddling with relationships (belongsTo) I found that in en/working-with-data/relationships.wiki this :

<?php
class Categories extends \lithium\data\Model {
    public $hasMany = array('Products' => array(
        'class'      => 'Products',
        'key'       => 'category_id',
        'conditions' => array(),
        'fields'     => array(),
        'order'      => null,
        'limit'      => null
    ));
}

should be replaced by this :

<?php
class Categories extends \lithium\data\Model {
    public $hasMany = array('Products' => array(
        'to'      => 'app\\models\\Products',
        'key'       => 'category_id',
        'conditions' => array(),
        'fields'     => array(),
        'order'      => null,
        'limit'      => null
    ));
}

I'm not sure if it's an issue in the code or in the documentation but since I got it working without modifying li3, I assume the doc is wrong.

It would be fantastic if there was a centralized location for all the different Litihium plugins. It could simply be a page on the lithium website with titles, description, a link to the plugin home page, and/or a link to a git repo for the plugin.

Or, possibly, you could create another Github organization, like "lithium_plugins" that hosts the master repo for each plugin. But that sounds as though it may be a little less practical, since (I think?) you would run into permissions issues for all the different authors for their plugins.

Configuration: Working with External Libraries

Zend Framework 1.x

First, we recommend installing ZF1 from the unofficial Git mirror, at git://github.com/Enrise/Zend.git. This distribution contains only the class library…

…and is outdated! No updates since 2013. A lot of security updates are missing!

• last ZF version in "Enrise/Zend" is 1.12.1
• current ZF version is 1.12.18

The chapter with the problem: https://github.com/UnionOfRAD/manual/blob/master/en/configuration/third-party-libraries.md#zend-framework-1x

The path, manual > models > querying, has the following sentence,

Some finder implementations might require a little processing in addition to a default set of conditions-somewhat like the . In that case, you can.......

Looks like the sentence is incomplete.

This is a constant request for me, there is a ton of automatic stuff going on here that is extremely difficult for new folks to figure out.

http://lithify.me/docs/manual/working-with-data/relationships.wiki has wrong data in it.

class Categories extends \lithium\data\Model {
    public $hasMany = array('Products' => array(
        'class'      => 'Products',
        'key'       => 'category_id',
        'conditions' => array(),
        'fields'     => array(),
        'order'      => null,
        'limit'      => null
    ));
}

• class should be to
• conditions should be constraint

(previously on UnionOfRAD/lithium#555 )