Searching for "install.php" does not show any result

Oh wow. Well, this is an edge case because the URL ends in "install.php" and I am sure that is blocked by the server configuration.

Using the branch-specific "Files" search https://api.drupal.org/api/drupal/files/11.x, and typing "install.php" returns one link to https://api.drupal.org/api/drupal/core%21install.php/11.x.

We might need to do so if/else logic in the redirection to avoid this case.

Drupal core’s .htaccess will indeed have to be modified.

For the Drupal.org sites on Drupal 7, we had a restriction that only the root index.php could be routed to the PHP interpreter. It looks like the current For security reasons, deny access to other PHP files on public sites. section should do a good job of this. We should double check that it works, so that rogue PHP files are never run via an HTTP request.

Then we can look at adjusting the FilesMatch directive. Likely splitting it into a separate regex(es) that still deny \.php$ but allow something like api/[^/]*/search/.*\.php$

In the case described in the issue summary, would not making a redirect to https://api.drupal.org/api/drupal/core%21install.php/11.x or to a page showing all the files with a name containing install.php be possible?

That would avoid to change the Drupal core's .htaccess file.

The redirects would be best implemented in .htaccess, so we’re modifying that either way. That allows local testing in development.

We do have the option of redirecting at the CDN, which does have slightly nicer syntax. It would still be ideal to keep this logic along with the site’s deployment.

I apologize: I meant SearchForm::submitForm() can redirect to https://api.drupal.org/api/drupal/core%21install.php/[branch] in that specific case. Currently, it always redirect to Url::fromRoute('api.search.project.branch.term', ['branch' => $branch->getSlug(), 'project' => $branch->getProject()->getSlug(), 'term' => $search].

Redirecting to a single page would show the wrong page if there are more than an install.php file used by Drupal core, but it would still be possible to search for other files with that name via the Files page.

In this case, the logic involved is this:
- https://git.drupalcode.org/project/api/-/blob/2.x/src/Controller/SearchC...
- https://git.drupalcode.org/project/api/-/blob/2.x/api.routing.yml?ref_ty...

This was done to let the more specific search function deal with it, but as {term} happens to be core/install.php, it builds that type of URL.

We can change it and maybe urlcode/urldecode the parameter and that should fix things.