Fix the execution when served by DDEV

[morvans]

Fixes #61.

This PR renames the PHP files that are intended to be fetched (as plain text data) and run locally with the WASM PHP engine.

Without the renaming, when the JS code (install-worker.mjs) fetch() these files, they get passed to PHP on the server-side and the browser only gets the output.

As this resulting output gets passed to the local (WASM) PHP engine, it gets treated as plain HTML, without any <?php open tag, and the content is just returned back, as is, to the JS worker.

I think it is why it was so confusing, as it was leading to think that this execution error actually happened on the client side.

[morvans]

Just flagging that it could also be fixed by tweaking the DDEV config to prevent the execution of PHP files within the "assets" folder. But it makes the solution less portable to other server environments that would also execute PHP files.

[mglaman]

That makes a lot of sense. My one concern is using "-wasm" suffix. What if we used .code instead? Since it's just code and not Wasm

[morvans]

What about .phpcode then? Any extension will do really. The most annoying point is that code editors are going to stop recognizing these as PHP files for syntax highlighting, code completion, .... It might be better to have a specific .phpcode than a generic .code. Another suggestion could be to keep the .php and use the build pipeline that exists for JS code to just duplicate these files (and gitignore the duplicates) and use the duplicates instead of the original for the JS-side fetch(). What do you think?

[mglaman]

.phpcode works, maybe .editorconfig can be used later to associate the files correctly. They're not going to be edited often

[mglaman]

Looks like you can't with editorconfig. But IntelliJ always prompts for an association when it's a new file type. That's fine with me

[morvans]

.phpcode it is.

[mglaman]

Thank you for this!