Is there anyone that could provide any insight into what changed between 2.2.1-pl2 and 2.2.2 that would cause such an error.
<b>Catchable fatal error</b>: Argument 1 passed to xPDOObject::load() must be an instance of xPDO, instance of modX given in <b>/home/webs_temp/modxrev.pmmsystem.net/htdocs/core/xpdo/om/xpdoobject.class.php</b> on line <b>404</b>
I use modx as a CMF so its really hard to provide an example that would make any sense to anyone. So I need to try to solve this backwards.
Not calling it a bug but since I do use modx diff then the average bear I do find interesting things and it was not producing this error before upgrade last night.
[ed. note: aesmith last edited this post 14 years, 4 months ago.]
"One of these days I will get around to my own website... Its only been about 12 years... maybe tomorrow
"
Ok so at this time there is so little modx involvment in what is actually being called the only thing I can assume is that is is catching an exception that is not even based on any modx code itself.
maybe there was a change to the error handling and it is catching more then it was before.
For now I guess ignore this unless someone else has similar issue
"One of these days I will get around to my own website... Its only been about 12 years... maybe tomorrow
"
I have determined the reason for this error noted previously.
The error itself is kinda bogus. What is happening is that the session handlers are trying to clean house and the modx object class no longer exists or is in the processes of being broken down and is incomplete. This only seems to happens under unique situations when using modx as a CMF.
The trigger for this is when you call die or exit; and modx tries to wrap things up.
I am probably not explaining this very well since session handling outside of php defaults is new to me and I am learning and I stumble through these issues.
Apparent Solution:
call session_write_close(); before calling die or exit;
"One of these days I will get around to my own website... Its only been about 12 years... maybe tomorrow
"
-
MODX Staff
- 10,725 Posts
Work to avoid this problem was done some time ago. It seems that there is an exit point somewhere that does not have the session_write_close() implemented...
I suspect it is in the minify code.
That is a very good guess. In fact I am not able to run the minify code on this server because of that error. Strange thing is I do not get the error across all server env I use modx on.
I will keep my eye out in that area of the code.
Just a thought. What about adding a method to the modx class. And then making it suggested best practice to never exit() explicitly and asking everyone to all always call doExit().
function doExit(){
session_write_close();
exit();
}
"One of these days I will get around to my own website... Its only been about 12 years... maybe tomorrow
"
-
MODX Staff
- 10,725 Posts
Not a bad idea, maybe without the do prefix on the method. Mind entering a ticket for such for Revolution?
"One of these days I will get around to my own website... Its only been about 12 years... maybe tomorrow
"
I have found (at least as it relates to my issue) the solution to the minify code and erroneous error that would not allow me to use compression in manager.
Within file /manager/min/index.php at line 133, 134 after Minify::serve(.....)
@session_write_close();
exit;
I suspect this is not the only place. I am in fact still getting the this error under 400 Bad Request operations. Will follow up when I have more
"One of these days I will get around to my own website... Its only been about 12 years... maybe tomorrow
"
Ok here is the other.
/manager/min/lib/Minify.php
Add @session_write_close(); before exit(); within _errorExit() method.
I will put in a ticket for all this
"One of these days I will get around to my own website... Its only been about 12 years... maybe tomorrow
"
