PHP 8 - Error line 1267
degive opened this issue · comments
Under PHP 8, I get the following error:
PHP Deprecated: preg_match(): Passing null to parameter #2 ($subject) of type string is deprecated in mobile_detect.php on line 1267
@degive I don't have a PHP8 release yet, only a PHP7 release scheduled https://github.com/serbanghita/Mobile-Detect/tree/7.x <-- can you test this branch if it has the same error please?
I can test PHP8 this week, but it will be under a different version scheme.
hum this new one does not work whatsoever... here is my test code
require_once ('MobileDetect.php');
$mobile_detect = new MobileDetect;
$is_mobile=( $mobile_detect->isMobile()) ? "yes" : "no";
echo "Mobile: $is_mobile";
and here is the error:, looks it can't even find the class yet it is there but I do noticed you changed the Class name from previous release
PHP Fatal error: Uncaught Error: Class "MobileDetect" not found in /ismob.php
@degive If updating the class name at your code is tedious due to being called from many places, you could use class_alias just after where Mobile Detect is loaded in to save the trouble.
E.g.,
class_alias('Mobile_Detect', 'MobileDetect');@serbanghita I sent a pull request for this just now. It should fix the problem. :-)
I don't get this error, isn't a typo of the op?
$mobile_detect = new Mobile_Detect;
should fix the problem no?
@DrLightman It's not just one problem which was mentioned. There are two separate problems mentioned.
- The deprecation notice for Mobile Detect's preg_match calls.
- OP's code not finding the class, due to the class name being changed.
Problem 2 is something which can be resolved by the OP at their end, and doesn't require any changes to be committed here at the upstream. But, resolving problem 1 requires a change to be committed here at the upstream (which is why I sent a pull request). :-)
ok I had missed the new 3.x version which has the class renamed.
So has the deprecation notice fixed?
Where can I download the fix from?
Thank you.
@degive I sent a pull request to fix the deprecation notice, but it hasn't been merged yet. We need to wait for @serbanghita to see it, so that he can review it and decide whether to merge it (I think he's very busy at the moment and hasn't had enough time yet, so we'll need to be a little patient). If, after reviewing it, he approves the pull request, it should then be possible to update via Composer, or, failing that, to update by downloading the latest version of the package from here directly.
@Maikuolan, thanks for the fix, I changed that line of code and no more warnings
@Maikuolan I've merged it, can you do the same PR against 7.x branch as well? 🙏
Done. :-)
@Maikuolan thank you!
I'm going to create an 8.x branch as well. @Maikuolan would you be available for a review?
Btw, if 7.x is well maintained, do we actually need a 8.x branch since it's just a PHP class and we can make backward compatible changes to the code in 7.x?
I'm going to create an
8.xbranch as well. @Maikuolan would you be available for a review?
I can help with reviews; No problem. :-)
Btw, if
7.xis well maintained, do we actually need a8.xbranch since it's just a PHP class and we can make backward compatible changes to the code in7.x?
When code compatibility is restricted to within specific version ranges, having separate branches can be a useful way to accommodate that, so that different users of different major PHP versions will have options available which are appropriate to their needs. But, in the case that there aren't any compatibility problems (e.g., code works perfectly fine and equally well regardless of whether the major PHP version used is 7 or 8), I don't see much point in separating branches like 7.x and 8.x, because presumably, the code in either branch would be mostly the same anyway, there wouldn't be much consequence for a user choosing to use one branch instead of the other, and ultimately, more branches means more work to maintain everything (and if we have a way to be more efficient, achieving more with less work, I would generally be in favour of that). So, in short, if we can ensure that the 7.x will also be compatible with PHP8, then I don't think having a separate 8.x branch will be necessary.
But, in the case that there aren't any compatibility problems (e.g., code works perfectly fine and equally well regardless of whether the major PHP version used is 7 or 8), I don't see much point in separating branches like 7.x and 8.x, because presumably, the code in either branch would be mostly the same anyway, there wouldn't be much consequence for a user choosing to use one branch instead of the other, and ultimately, more branches means more work to maintain everything
@Maikuolan This is exactly what I was thinking, thank you for the review on this matter!
I'm currently trying to figure out how to move forward with two branches (5.x, 7.x) and two release tags 2.8.xx and 3.74.xx where 74 signifies the PHP version. Maybe this is not entirely correct. I plan on skipping from 3.0.0 to 3.74.0 because 3.0 was originally intended to have a broader scope, but I realised I cannot do it alone at this point.
What's your take on the above?
What's your take on the above?
Doing it that way should probably be okay, I think. Just as long as we ensure that version numbers remain compatible with semver into the future (skipping versions is okay, and managing multiple different major versions is okay too, as long as dependency managers like Composer et al don't become confused, e.g., mistaking newer versions for older versions, older versions for newer versions, etc). So, if the intended PHP version is to be cited within the version cited for Mobile-Detect, if you were to release a version targeted towards PHP 8.0 as an update to 3.74.0, it would best to use 3.80.0, and not something like 3.8.0 (to ensure Composer sees it as a newer version, not an older version).
The "major" part of the version (2.x, 3.x) should also (per semver) still communicate to users whether a particular version remains backwards-compatible with previous versions (so, for example, after releasing 3.74.0, if a subsequent version stopped supporting a major PHP version previously supported by 3.74.0, we would, at the least, want to use something like 4.74.0 as the version for that subsequent version).
@Maikuolan yes, the goal is to keep semver compatible tags so we don't confuse the releases and composer releases as well.
2.x is the current LTS version which will support PHP 5.3 - to be determined how long.
3.x is a stripped version of 2.x, I removed all @deprecated methods and properties. Still using the same logic. Maybe add new logic (like smartwatches). In theory this is backward compatible with minor changes related to the namespace, but since it's a major version, we're not obligated to maintain backward compatible.
At the moment I'm focused on nailing down the releases for 2.x and 3.x so people understand that if they want support for PHP >=7.x, they need to go with 3.74.xx. I need to migrate all people who install Mobile Detect via composer.
Only this is achieved, we can focus on new features.
I hope this makes sense
Sounds like a good plan to me. 👍
@Maikuolan ok great, thank you for the reviews and fixes! I'm closing this
Having the dev version being name 7.x for the branch released as 3.74 looks weird to me (Composer names dev versions based on the branch name)
@stof agreed, can you give me an example out there in the wild from established PHP projects?
So basically your suggestion is having a 3.74.x branch that corresponds to all 3.74.xx releases right? And then update the docs that this release is for PHP>=7.4
Yes, this is what I suggest. Examples naming the branch like the next version are easy to find: Symfony and Doctrine are following that pattern for instance (IIRC, Laminas does it as well for all their packages).
and for the dev versions being wrong right now, the proof is on https://packagist.org/packages/mobiledetect/mobiledetectlib (look at the version list in the right column)
@stof ok this is eye opening to me and I want to thank you for all details
I checked both https://github.com/symfony/symfony/branches and https://github.com/doctrine/orm/branches and I was initially in shock to see they have no master or main branch. But now it makes sense to chose the default branch as the latest stable version - this is important for me because right now people are opening PRs against master and I have to do redundant merges to incorporate their changes.
I'm thinking of either deleting master (I hope that doesn't have major consequences on the history of the project) or just locking it as read-only (must check GH options).