096 RC3 support and issues

Ive got a new error, but i think it is a configuration error.
I was testing ModX on Wamp on windows.

When i was going to login using weblogin, it wanted me to download index.php
This was only on one computer, running Firefox. I couldn not reproduce the error on my own computer.

Have anyone else had this problem?

It kinds of worries me that the browser wanted to download index.php
with the sourcecode all open.

Quote from: beryl at May 20, 2007, 06:00 AM

Ive got a new error, but i think it is a configuration error.
I was testing ModX on Wamp on windows.

When i was going to login using weblogin, it wanted me to download index.php
This was only on one computer, running Firefox. I couldn not reproduce the error on my own computer.

Have anyone else had this problem?

It kinds of worries me that the browser wanted to download index.php
with the sourcecode all open.

That sounds like a misconfiguration issue... do other pages work ok? That would happen if PHP isn’t being parsed properly by the server (and I’ve also seen it happen if Apache segfaults while trying to parse a script). The file would most likely be empty if you downloaded it, though.

Definitely a server configuration issue (and yes it would be a very serious issue if it were a live public server).

Websignup snippet (websignup.inc.php) refers to input elements in the default template chunk with different names.

In the default template chunk (but not the default tpl in file) sometimes elements are named with a prefix "wsu_username" and "wsu_email" but in the file they are named just "username" and "email".

$username = $modx->db->escape($modx->stripTags($_POST[’username’])); from file will not find wsu_username from template chunk so it breakes.

Sorry if this is alredy adressed somewhere else.

I was checking thru my server settings and cannot find anything wierd. I also tried "ultra secure" php.ini and httpd.conf files. Same error on the same computer, i can´t download any other php file than index.php though. Ive also tried downloading a CVS version of ModX, and it seems to not have the problem..

Bug

I am not sure if this is a bug or not, but I am pretty sure modx is not suppose to behave like this. If you click in the document tree and delete a document, then click on the document, the preview will not display the document. The page just constantly tries to load, like it is some kind of continuous loop.

Quote from: capin at May 22, 2007, 10:42 AM

I am not sure if this is a bug or not, but I am pretty sure modx is not suppose to behave like this. If you click in the document tree and delete a document, then click on the document, the preview will not display the document. The page just constantly tries to load, like it is some kind of continuous loop.

Is your error page set, and is it published and public (not in a restricted document group)? The preview window should forward to the error page, so that needs to be set up and working properly.

Well you know your sh*t because that seemed to fix the problem/bug.

Is this the version with the OO framework at the core and PDO emulation? I looked at the code and it doesn’t seem to be, but I’m confused when that’s coming? I’ve got a project I’d like to use it on!

@pbowyer: The core is being overhauled to use xPDO in MODx 097. (the next major release after 096) As for a release date, I think the current estimates are to have - at a minimum - a beta available sometime this summer.