-
-
Notifications
You must be signed in to change notification settings - Fork 436
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updated PHPStan to 1.9.13 and ZF1Future to 1.22 #2960
Conversation
fballiano
commented
Jan 17, 2023
•
edited by sreichel
Loading
edited by sreichel
- Closes ZF1F update (v 1.22.0) #2956
These patches are not applied correctly anymore:
|
See #2956 |
oops, missed that :-D |
Patches can be removed. |
done! ❤️ |
ZF-299 has been merged too. Please check. |
it gets applied, i'll check the source code after a call I've to do in 5 min :-) |
@sreichel it seems ZF-299 wasn't merged in 1.22, if you check https://github.com/Shardj/zf1-future/blob/release-1.22.0/library/Zend/Date.php it doesn't have any of the code included in the patch. |
mmmm I see what you mean, but is it ok if Zend/Date.php stays without the patch that now has been added upstream to DateObject.php? |
Mhhh, my PR targets Zend/Date/DateObject.php ....maybe something went wrong here. I'll check it later. |
Just from memory ... Did magento added this to Zend/Date.php with calling parent method (in Zend_Date_DateObject)? Quick check lgtm. |
right, it extends Zend_Date_DateObject, removing that patch in 1 minute |
class Zend_Date extends Zend_Date_DateObject Y. |
uff, sorry for the many commits, kinda busy in this very moment |
No, im not in contact with @Shardj. There should be three MAG-patches left (ignoring MAG-1.1). I'll add them in time. OM-patches may need to be reviewed before create PR at ZF1F. |
Ignore phpstan error ... (possibly repeating error is fixed with removal of code/core/Zend) Ill update tomorrow, |
Some new phpstan errors popped up, possible related to the patch files removed? |
@fballiano i think this patch was applied to core/code/Zend. |
merged and cherrypicked to v20 |
There's an issue with deleting the patches in the source tree, because composer.json requires it from:
But now, that file is 404. So if you have a commit earlier than this one, composer install will fail to apply these patches. To reproduce:
output:
So far it's not a big problem because we don't have any tag where we use My first attempt to fix was to define patches like this: "patches": {
"shardj/zf1-future": {
"MAG-1.1.1": "./patches/MAG-1.1.1.patch",
"MAG-1.9.3.0": "./patches/MAG-1.9.3.0.patch",
"MAG-1.9.3.7 - SUPEE-10415": "./patches/MAG-1.9.3.7.patch",
"MAG-1.9.3.9": "./patches/MAG-1.9.3.9.patch",
"OM-918 - Add runtime cache to Zend_Locale_Data": "./patches/OM-918.patch",
"OM-1081 - Not detecting HTTPS behind a proxy": "./patches/OM-1081.patch",
"OM-2047 - Pass delimiter char to preg_quote": "./patches/OM-2047.patch",
"OM-2050 - Prevent checking known date codes": "./patches/OM-2050.patch"
}
} Which does work on if you clone this repo and composer install, but fails if you install via So, then we should either reference the patches with the commit hash in the URL:
Or, make a new repo for it, |
We should keep it in mind, but actually it should be no problem (unless your branch isnt up2date). We have no release including ZF1F that requires these files, but its a good idea to move them outside. |
It's not a problem now, but will be if we were to tag a release today. Because then the patch files could never be deleted from this repository without breaking that release. |
@fballiano can you please add at "patch-repo"? |
Like zf1patches? Or composerpatches? |
I'd prefer "vendor-patches" (or "composer-patches") |
For the issue with the deleted files, that could've been solved simply by using the permalink which uses the latest commit id, instead of the one with the branch name: Still works: https://raw.githubusercontent.com/OpenMage/magento-lts/6b0408fce476a738b7008bd3a4b99921fef2ee80/patches/ZF-299.patch |
@elidrissidev great idea |
Note that I did mention that in my comment, But, a separate repo is still better IMO, because it could be too easy to modify a patch and forget to update the hash in the same PR. Or you do update the hash, but then the hash changes when you squash. Also, finally, older tagged versions still use the older patch [may be a good or bad thing]. |
the fact that the old tagged version would use the older patch I think it would be a "must have" |
I'm not against using commit hashes. I guess modifying or introducing a patch need to be done in one PR, and referencing the patch in composer.json needs to be done in a second PR? I think at least... It would be nice if this was merged instead: cweagans/composer-patches#417 |
That would be the best way to do it, but the activity on that repo is very slow, so I have to agree with the current way for now. |