Fatal error: Call to undefined method modRequest::initialize()

Quote from: OpenGeek at Sep 07, 2008, 02:13 AM

Try a clean install again, and when the install finishes, click Toggle Warning Messages and double-check to make sure there are not any SQL error messages reported there. If there were problems inserting data, they would be reported there.

There really are not any errors.

Quote from: OpenGeek at Sep 07, 2008, 02:13 AM

If you are sure no errors are being reported there, then perhaps your attempt to build the transport package is what failed instead (i.e. not producing all the object "vehicles" representing the table rows to be inserted from the transport package), and before I try to teach anyone how to debug the install process we need to explore the simple explanations first.

You might also provide more environment details like MySQL server and client library versions.

So MySQL 5.1 64-bit http://dev.mysql.com/downloads/mysql/5.1.html#winx64
PHP 5.2.6 32-bit and in this release are php_pdo.dll and php_pdo_mysql.dll in version 5.2.6.6 (Tell me Filealyzer)
Apache 2.2.9 32-bit

I have meant that I have set up error_reporting = E_ALL | E_STRICT but I have error_reporting = E_ALL & ~E_NOTICE. I’m dullard

So the output of transport.core.php is in attachment and output of modx/manager/ is here:

Strict Standards: Redefining already defined constructor for class modX in E:\htdocs\modx-097\core\model\modx\modx.class.php on line 284

Strict Standards: Assigning the return value of new by reference is deprecated in E:\htdocs\modx-097\core\model\modx\modx.class.php on line 457

Strict Standards: Redefining already defined constructor for class xPDO in E:\htdocs\modx-097\core\xpdo\xpdo.class.php on line 366

Strict Standards: Redefining already defined constructor for class xPDOCriteria in E:\htdocs\modx-097\core\xpdo\xpdo.class.php on line 1890

Strict Standards: Declaration of modX::getCacheManager() should be compatible with that of xPDO::getCacheManager() in E:\htdocs\modx-097\core\model\modx\modx.class.php on line 55

Strict Standards: Redefining already defined constructor for class xPDOObject_mysql in E:\htdocs\modx-097\core\xpdo\om\mysql\xpdoobject.class.php on line 69

Strict Standards: Redefining already defined constructor for class xPDOSimpleObject_mysql in E:\htdocs\modx-097\core\xpdo\om\mysql\xpdoobject.class.php on line 100

Strict Standards: Redefining already defined constructor for class xPDOObject in E:\htdocs\modx-097\core\xpdo\om\xpdoobject.class.php on line 552

Strict Standards: Redefining already defined constructor for class xPDOSimpleObject in E:\htdocs\modx-097\core\xpdo\om\xpdoobject.class.php on line 2017

Strict Standards: is_a(): Deprecated. Please use the instanceof operator in E:\htdocs\modx-097\manager\index.php on line 59

Fatal error: Call to undefined method modRequest::initialize() in E:\htdocs\modx-097\manager\index.php on line 77

That doesn’t help at all; ignore all E_STRICT warnings. Revolution is meant for PHP 4 and 5, not just PHP 5, and certainly not E_STRICT compliant.

I post it because if there isn’t something, what could cause this problem. But only strict messages and nothing other.

Problem is going to most likely be with using MySQL 5.1 (64-bit).  I fear new features, restrictions, deprecations, or bugs might be the culprit, either in MySQL or in the client libraries being used to communicate with it via PHP.

In fact, take a look at this bug report that seems to indicate problems with 64-bit MySQL on 32-bit operating systems (XP): http://bugs.php.net/bug.php?id=44645

I downgrade to MySQL 5.0.67 64-bit but same problem Strangely

So I have definitely discovered the problem and it’s STRICT mod in mysql.  >:( >:(
Why ? If 0.9.6.1p2 supports mysql strict mod.

My first impression is that Revolution is very very slow. My comp Core 2 duo 3.0GHz and not the public sever but my personal comp.

Quote from: snop at Sep 07, 2008, 11:41 PM

So I have definitely discovered the problem and it’s STRICT mod in mysql. >:( >:(
Why ? If 0.9.6.1p2 supports mysql strict mod.

Well, because I don’t run a MySQL server in STRICT mode when I’m developing (or in production for that matter), so it’s not a priority. Can you please report this in JIRA? If more people actually took the time to test and report their findings like you, then I guess we’d have more bugs squashed by now.

Quote from: snop at Sep 07, 2008, 11:41 PM

My first impression is that Revolution is very very slow. My comp Core 2 duo 3.0GHz and not the public sever but my personal comp.

Not for me; the framework is more flexible, front-end pages load just as fast (avg 3 to 10 pages per second in my local loopback tests), and the somewhat bulkier manager is much more usable, and has less frequent requirements to reload the whole frame-set. The manager is definitely a little slower to load the first time due to the ExtJS foundation, but once that JS is cached, you can get around the much richer, and much more customizable UI very quickly and smoothly. Actions such as saving a document/resource take milliseconds in the background with no page load required at all now.

Quote from: OpenGeek at Sep 08, 2008, 02:42 PM

Well, because I don’t run a MySQL server in STRICT mode when I’m developing (or in production for that matter), so it’s not a priority. Can you please report this in JIRA? If more people actually took the time to test and report their findings like you, then I guess we’d have more bugs squashed by now.

Why ? If you run MySQL in STRICT mod, then you can catch all this bugs. STRICT mod don’t hobble. But I mean that you have your own reasons.

Quote from: OpenGeek at Sep 08, 2008, 02:42 PM

The manager is definitely a little slower to load the first time due to the ExtJS foundation, but once that JS is cached, you can get around the much richer, and much more customizable UI very quickly and smoothly. Actions such as saving a document/resource take milliseconds in the background with no page load required at all now.

You are right and the saving of a documents will be very comfortable. I’m thinking that I will using ExtJS in my projects as well.

Quote from: snop at Sep 08, 2008, 03:19 PM

Why ? If you run MySQL in STRICT mod, then you can catch all this bugs. STRICT mod don’t hobble. But I mean that you have your own reasons.

I don’t run MySQL with any strict sql_modes because it adds overhead to every transaction on the MySQL server to do that kind of validation there. IMHO, the application should be responsible for the finer details of data validation. But regardless, we will be doing such advanced testing in the beta phase, and your input has helped us get a head start.