Closed Bug 500060 Opened 15 years ago Closed 15 years ago

webroot/tiki-editpage.php acts as if AddType isn't defined on SUMO staging

Categories

(mozilla.org Graveyard :: Server Operations, task)

All
Other
task
Not set
blocker

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: ecooper, Assigned: reed)

References

()

Details

Sometime recently (today, it seems), the SUMO staging server acts as if it doesn't know how to execute PHP files when webroot/tiki-editpage.php is loaded. Instead of rendering the page, the browser attempts to download the file. Downloading the file results in an empty file.

See https://support-stage.mozilla.org/tiki-editpage.php?locale=en-US&page=%2AClearing+private+data

Staging is the only place we're seeing this. This can't reproduced locally using r28322, the latest revision.
Severity: critical → blocker
Assignee: server-ops → phong
gemini:~ reed$ curl -k -I "https://support:stage@support-stage.mozilla.org/tiki-editpage.php?locale=en-US&page=*Clearing+private+data"
HTTP/1.1 200 OK
Date: Tue, 23 Jun 2009 23:47:38 GMT
Server: Apache/2.2.3 (Red Hat)
X-Powered-By: PHP/5.2.6
Cache-Control: no-cache, pre-check=0, post-check=0, max-age=0
Expires: Tue, 23 Jun 2009 23:47:38 GMT
Content-Type: text/html; charset=utf-8

There's nothing in the error log...
Assignee: phong → reed
Interestingly, you can trigger a 'Page is currently being edited' warning with webroot/tiki-editpage.php. This means that whatever is causing this problem is happening after line 256 (this warning is thrown during lines 221-256).

webroot/tiki-editpage.php hasn't been updated in two weeks. The only thing I know touching tiki-editpage that has changed is tiki-setup_base.php, which happened today. While it won't fix the problem, reverting tiki-setup_base.php could confirm that the problem is with the changes introduced in bug 497109.
So, can you test with bug 497109 then, or do you want me to continue debugging?
Please continue debugging (thanks).  The changes in bug 497109 don't cause this problem on sumotools.
sumotools is currently using the prod branch, where the patch for bug 497109 isn't present yet because I feared something like this would happen. 

Apparently, I screwed up and forgot to post that in the bug, though. :(
I switched sumotools back to trunk and cannot reproduce the bug there.
Backing out changes for bug 497109 resolves this issue on staging. See https://bugzilla.mozilla.org/show_bug.cgi?id=497109#c10
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Working now...
Krupa found a critical regression, which she filed as bug 500239.
Depends on: 500239
No longer depends on: 500239
Verified FIXED; can log in and view the page -- before, I was consistently getting a blank page.
Status: RESOLVED → VERIFIED
No longer depends on: 500239
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.