The non-php fallback is causing too many issues. We need to draw a line.

We get a lot of benefits from being able to use PHP, not sure we want to give that up. The resolution to this may be just to document our dependencies.

Agreed we need to draw a line...at some point we gotta say that PHP is a requirement.

None of the ajax unit tests run correctly without PHP. We resort to a hack that says just don't run those tests if the protocol is file://. But if you're using a non-PHP server and the http:// protocol, wouldn't the ajax tests fail too?

There are a few options here:

1. say PHP is a build req and make unit tests fail when run from file:// or PHP is disabled.

2. say node.js is a build req, convert all PHP to node.js, and make unit tests fail when run from file.

3. attempt to keep the non-PHP callback, but have it load build/jquery.js so we can have the unit tests always run against a single file, but this causes the tester to build after every change.

I'm all for #1.

Or, we could load scripts from a single file without php or node...right?

@dmethvin I'm not talking about removing PHP, I'm talking about making it a known requirement/dependency of the test suite.

@mikesherov I'm going to say #1 for now, but #2 is an ideal long term goal. I've been working with Ben to iron out grunt details and moving to one server dependency seems to make the most sense across the board

@timmywil, I think your missing some context here - this arises because we want to be able to test build unbuilt and built source.

this theoretically should work though. It's weird. I'm going to take a look at it.

Regarding the multiple files from one file, that's what the non-PHP fallback does. We run into issues though when the include_js.php is loaded asynchronously or in other edge cases. At one point or another, doing a bunch of document.write's inside a JS file exposes itself as such.

There were issues with the path of those document.write scripts, when running the core suite, so i fixed that, but now there are issues with the files that are loaded via iframe. The whole thing is a damn mess... but only if you dont have a PHP enabled server.

Wait, so, the document.writes all need to have an absolute path. I attempted to do that by inspecting the url and looking for "/test/" as the way to find what the "base" url is... can you describe what the url was when the tests were run so I can debug?

Before we just condemn non-PHP execution (even though I'm all for it), I'd like a chance at debugging this.

so, I already have a ticket about warning the user if they run tests without PHP. I'll just fix what was mentioned here in that ticket.

Duplicate of #10901.