#Needs product manager review

It is used to alert the product manager core committer(s) that an issue represents a significant new feature, UI change, or change to the "user experience" of Drupal, and their signoff is needed. If an issue significantly affects the usability of Drupal, use Needs usability review instead (see the governance policy draft for more information).
โšก๏ธ Live updates comments, jobs, and issues, tagged with #Needs product manager review will update issues and activities on this page.

Issues

The last 100 updated issues.

Activities

The last 7 days of comments and CI jobs.

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom catch

    I've read it should be possible to use a Docker-based solution to run Linux with Apache or Nginx and PHP on a Windows host. In such a scenario, Drupal may not be relying directly on Windows, but it would still be running on a Windows server.

    This would still be supported more or less by default because we support running Drupal on linux in docker, and what exactly docker runs is not usually taken into account. As you say:

    In a Docker-based scenario, chances are, any security issue would be more related to the architecture within Docker rather than the host anyway.

    Agreed with this - I can't think of a situation where there'd be an issue, especially a security issue, specific to Drupal on docker on windows, as opposed to a generic Drupal issue or a generic Docker issue.

    However dropping support for directly running on Windows in production also means dropping support for apache on windows, not just IIS on windows - just to make that clear. We'd still accept bug reports from people using windows + apache (or even IIS) for local development, but any security issue would be made public as long as it's really windows-only, and we'd stop shipping the IIS file.

    I tried to update the issue summary to make this a bit clearer, although the wording probably needs improvement.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States paulmckibben Atlanta, GA

    I have, in the past, supported a D7 site on Windows/IIS, and I've had inquiries about the possibility of running a corporate-internal D10 site on Windows. This is to say, there are still a few organizations out there who run Windows server networks internally, but still have an interest in using Drupal and other open source software.

    I think it's fine to drop IIS support. However, I think we need to distinguish that from "Windows" support. For example (and I haven't tried this), I've read it should be possible to use a Docker-based solution to run Linux with Apache or Nginx and PHP on a Windows host. In such a scenario, Drupal may not be relying directly on Windows, but it would still be running on a Windows server.

    • What I'd like to see is a conclusive statement about what is or is not being supported by the security team. Is it IIS, or anything where Windows is involved? I'm seeing allusions to both of these in the previous comments.
    • If possible, if anyone has experience/expertise and can share, I'd like to see the documentation updated for "Best practices when running Drupal on Windows using Docker" or something along those lines. If my situation ever gets beyond inquiries and I have to figure it out, I'd be glad to contribute to such documentation, but I hope I'm not the first to even think about trying this.
    • Overall, I think I am more concerned about community support rather than security support, if that distinction makes sense. I know Windows is an edge case, and I'm unconcerned if the DST needs to exclude IIS and the Windows OS from security support. In a Docker-based scenario, chances are, any security issue would be more related to the architecture within Docker rather than the host anyway. What I would like to see is sharing of best practices by those who have had to support this use case. And to avoid a blanket "We don't support Windows" statement, but a more nuanced, "If you must use Windows, here is an approach that works."

    Thanks to the DST, core maintainers, and everyone else who has put so much thought into this. I'm writing this to share my limited experience with this scenario. If there is more I can do to help, let me know.

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom pstewart

    Hi all, I'm one of the maintainers of the the sqlsrv module https://www.drupal.org/project/sqlsrv โ†’ and from what I can see this change shouldn't change anything with respect to that module for sites using SQL Server either as the primary database or as an auxilliary database. I suspect most users of the module are hosting in a Linux env and just using SQL Server for database (which is my own situation), however I'm guessing we're more likely to have above average Windows + ISS users versus the rest of the community, so I've posted in the #sql-server Slack channel to publicise this RFC.

  • ๐Ÿ‡ง๐Ÿ‡ชBelgium BramDriesen Belgium ๐Ÿ‡ง๐Ÿ‡ช

    I have not encountered ISS yet in my professional carreer. However I did work on a few projects which used MS Azure and must say the process was not fun at all. Besides that performance was very poor and it took a lot of time and effort to get it to run somewhat well without slapping a huge amount of resources on the server. Azure itself also still has to my knowledge it's issues (DB level), but that's off topic here.

    In my opinion it perfectly makes sense to only allow linux environments. With the more modern approaches of Docker images and Kubernetes clusters I really don't see any problems with that. I think if this decision lands, this would even push "Windows only" clients into a more open source street, which is a positive side effect ๐Ÿ˜‰

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom scott_euser

    From database perspective I have had clients using Azure SQL as researchers are often working there. No issues using contrib https://www.drupal.org/project/sqlsrv โ†’ though and I asked platform.sh just a couple weeks back and they were happy to update driver support in php to 8.3 (was previously 8.1) so for those hitting this issue worried about connecting to such a database hopefully that helps.

    From a development environment perspective: as mentioned earlier WSL2 is a good option for Windows users. If you come across this issue and are worried if you can continue using Windows I would encourage you to try out https://ddev.readthedocs.io/en/latest/users/install/ddev-installation/#_... - I have had colleagues successfully use it fine across multiple big projects and Randy has a good test suite set up to make sure it continues to be supported there (https://ddev.com/blog/ddev-local-automated-testing/).

Production build https://api.contrib.social 0.61.6-2-g546bc20