[0.9.2] Known Issues and resolutions

When I view source I see the following -

So good they included it twice !

interesting, I have experienced none of these issues, everything works after upgrading to 0.9.2 bravo

i’ve also found that most of my issues i had are almost always user error or just plain ignorance on my part he he. I keep studying modx so i don’t have to ask more stupid questions.

In other news...

While playing around with the document.parser.class.inc.php file in hopes of finding a fix for the 404 issues, I’ve found some unusual behavior in regards to error page redirection. It seems that if you don’t have an error page assigned then the parser simply gives out. So...we should probably either find a way to allow for having no error page assignment, default it to the starting page, or tell the manager to prompt the user for an error page document ID.

Also, in regards to error page redirection, I noticed that the default behavior for pages that don’t exist is to reassign the document ID to the error page. Granted, there’s a line for the outputDocument function (around line 429) that adds a 404 header but it doesn’t appear to work since Apache doesn’t log any 404’s upon hitting a page that doesn’t exist. I think the getDocumentObject function may be the problem since it appears to be changing the documentIdentifier variable to the error page around line 863. Whew! There’s alot going on with this! LOL! Anyways...the main thing we need to do is make sure that anytime a page doesn’t exist and the OnPageNotFound event is invoked to send a header("HTTP/1.0 404 Not Found") event before any redirection to the error page occurs. Even better, if we can tell MODx to not use any redirection and simply parse the error page then we should be able to send a 404 header as the first thing parsed before anything else. The main thing is to get the header out first. That way Apache will log it properly as a 404 and probably won’t log any 200, 301, or 302 messages either.

Jeff

Jeff ... take a look in the commit logs for Victor’s (vbrilon) commits regarding the headers ... he had a partial or maybe a complete solution in place for the 404 issue I believe.

I actually found the problem...errr...sort of. Part of the problem was this line around line 429 in document.parser.class.inc.php:



It’s part of the outputContent function and checks to see if the error page is being referenced as the page to be parsed. If it is then it adds the 404 header to the output. However, it also checks to see if a variable called $redirect_error evaluates to true. Problem with this is that there is only one place this variable exists and it’s in the sendErrorPage function towards the top (around line 120). For now, at least till we find a better solution, I changed it to where if either evaluates to true then it sticks in the header:



Granted, this isn’t ideal if the error page is being used for an unauthorized user error...but at least it ensures that a 404 header is used for any non-existant page errors which is pretty important. I’ll take a look at what Victor has done. I’m guessing that we’ll need to put in some work towards revamping how errors are dealt with. It’ll probably result in the removal of some redundant code...which is a good thing. We can probably streamline it pretty good.

I have found a small problem in 0.9.2. I am not sure if it existed in previous versions, as I have only tried it recently.

I have declared a TV, colours, as a drop down list -"red||blue||green||etc ...". This is used to pick up a css file to display stuff in the appropriate hue.

However I have discovered that, whatever I set the TV to in the page, when I save it reverts to the default value.

i.e Default is red, I change to blue. On save it is red again. If I do not specify a default value, then I get blank.

Thanks

[resolved] The name of the TV was "Colour Scheme". I changed it it to "ColourScheme" and now it works. I can’t explain it but I’m happy

Jeff,

I had a full 404 fix committed that addressed all those problems. But some of the changes made for the emergency security fix fundamentally changed the flow of how my code was being called, therefore making my fix useless

Anyway, I’ve been swamped with work, but getting a better 404 fix is definitely on the agenda for sometime in the next few weeks. If you have ideas (or better yet, code ) on how to fix it, please let me know.

Victor

hi Vic!

I have noticed, that parser is swears, that two header in one place.



Content-Type we can send from index.php... can’t we?

And "kick" to the future: real Last-Modified Date from db as lastediton -- doesn’t realy?

There are 2 fields in the database, "publishedon" and "publishedby". These fields are set correctly when a document is published using the right click/publish method, but they are incorrectly set when the document is saved with the ’publish’ box ticked. In this case they are reversed, i.e. "publishedon" get the user id and "publishedby" gets the time.

The culprit is the SQL INSERT in save_content_processor.php. 2 values are set up prior to this query

However, looking at the query -


1. "publishedon" and "publishedby" are the wrong way round, and
2. The values previously calculated for them are actually assigned to "editedby" and "editedon" and they get new copies, regardless of the status of the "published" flag.

Are we still using the bugtracker? If so I will post this there.

PS I have now tracked it here.

Quote from: zenmaster at May 28, 2006, 04:21 PM

Are we still using the bugtracker? If so I will post this there.

Nice catch, and please log it in the bugtracker, so we don’t forget about it...