This is a follow up question to the post "https://forums.modx.com/thread/84303/why-my-customusergetlistprocessor-retrieves-modusers-too".
Description of Problem:
As mentioned in the above post, we have created the class
customUser which is an extension to the
modUser class.
As it turns out, the solution to the above post solves half of the problem. That is, the
customUserGetListProcessor now correctly returns the "total". However, the "results" property of the response is empty.
In other words, the
customUserGetListProcessor counts the right amount of objects to be retrieved, but no object is actually retrieved.
After some tests we have performed we have come to the conclusion that the problem lies in line 54 of the
modUserGetListProcessor class. The code that causes our problem is highlighted below.
public function prepareQueryAfterCount(xPDOQuery $c) {
$c->select($this->modx->getSelectColumns('modUser','modUser'));
...
return $c;
}
It is because a selection is made for the columns of the
modUser class' table, that the
customUsers are not returned.
But this code is inside the
modUserGetListProcessor class and, thus, it cannot (should not) be changed.
So, our question is twofold:
- Is it indeed the above line to be blamed for the problem?
- If yes, is there a way to override its behavior, so as to avoid changing core code?
Steps to Reproduce [1]:
- Add two new entries in the "users" table of the database.
- Set their "class_key" property to "customUser".
- Create a new instance of the customUserGetListProcessor class.
- Run the above processor (i.e., call its "run" method).
- Store the returned value to a variable (e.g., $response).
Expected Outcome:
Inside a PHPUnit test case, the assertions below should pass.
$responseArray = $modx->fromJSON($response->response);
$this->assertEquals(2, $response['total']);
$this->assertNotEmpty($response['results']);
However, only the first assertion passes [2], while the second one fails.
- MODX Version: 2.2.7pl (Advanced)
- PHP Version: 5.4.3
- Database (MySQL, SQL Server, etc) Version: 5.5.24
- Additional Server Info: Apache 2.2.22
- Installed MODX Add-ons: None
[1]: Of course the steps cannot be reproduced because you would need the
customUser class. But the example of the section serves to make things clear as to what the problem is.
[2]: This is the problem discussed in the post mentioned in the beginning of this post.
[ed. note: leffyrant last edited this post 13 years, 5 months ago.]
