NaheemSays → created an issue.
Can an alternative installer be provided instead that simply (potentially bundles and) runs a composer command to download and install drupal?
Current patch doesnt work and I still need to figure out what is needed, so setting to needs work.
The problem with not backporting support newer versions of php to older releases is that you could find yourself in a situation where you cannot support the newer version of drupal on the same system as your existing version.
While IMO php minimum version support should not increase outside major drupal releases, there is value in increasing the latest version supported as new php versions are released.
Just a note that I have not tested this yet and expect it to require further work (especially as its failing in CI).
Can an alternative approach be to differentiate by mac address?
I dont think it is as common for different devices from the same IP address to be shared between multiple users as much as it was say 10 years ago, so if we still want to try and differentiate voters, it may be reasonable to look at distinguishing based on something other than IP address.
https://www.drupal.org/project/slick/issues/3360779#comment-15054024 ✨ Improve composer support Needs work says blazy does not require any libraries since the 2.6 release, so closing.
NaheemSays → created an issue.
NaheemSays → created an issue.
The only relevant from that is poll_vote.
However the code suggests it already has a primary key? Look at poll.install:
'primary key' => array('pid', 'uid', 'hostname'),
NaheemSays → created an issue.
Looking forward to it!
Is the devlopment code available to view somewhere?
NaheemSays → created an issue.
I have moved the code into a new merge request to avoid the previous messy commit history.
It is the same code as before plus a fix to a coding standards error (which is separate commit).
I would be grateful to get this done as I want to work on another feature for poll (multiple poll types), but I dont want to touch that until this is in place to ensure that nothing is broken by that work
It should be passing again.
The commits on the merge request are a bit of a mess but my attempt to rebase them was... less than adequate so when merging please make sure to squash into one. Thanks!
+1 to the proposal but with a less aggressive php support: Not the latest but the version before that. (8.0 for 10, 8.2 for 11)
I agree that a php version should be supported throughout the full release period, but jumping on a new php version within 6 months of its release is not always possible.
I often use Fedora, which is known to be aggressive with updating its packages, but iirc php 8 is still not supported in a stable release. It will be supported in Fedora 35 releasing end of October, almost a year after the release of php 9.0
For those using Ubuntu, it will also be defaulting to 8.0 in the october release.
Ubuntu also has its LTS releases in the even years (the same as proposed drupal major releases), so they could fall nicely for the original proposal, or if the current delay in adopting 8.0 is expected, 22.04 LTS might remain on 8.0, 24.04 on 8.2 etc.
Centos/RHEL are longer releases but they provide multiple versions of php.
Debian latest release is on 7.4 so it will still require a custom php package.