-
Notifications
You must be signed in to change notification settings - Fork 49
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
Remap old config variables #1509
Conversation
- Remove no longer needed code fragments that ensure that old configuration variable formats are supported after a minor update
Update Development branch
$tPath = ini_get('upload_tmp_dir'); | ||
} | ||
if(!$tPath && isset($GLOBALS["TEMP_DIR_ROOT"])){ | ||
$tPath = ini_get('upload_tmp_dir'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Confirming this is an intended change in logic. The proposed code will default to using the upload_temp_directory returned by ini_get('upload_tmp_dir') unless that function returns false. The previous logic appears to default to the value in $GLOBALS["tempDirRoot"] . Perhaps the intent is to default to the new $GLOBALS["TEMP_DIR_ROOT"] and fallback to ini_get('upload_tmp_dir') if that global is empty ? (line 446 will short-circuit on !$Path )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, defaulting to upload_tmp_dir is the attended action. The old code defaulted to using the old variable format (tempDirRoot), and then upload_tmp_dir, and then the new format (TEMP_DIR_ROOT), which is a little screwy. Simply defaulting to upload_tmp_dir, and then TEMP_DIR_ROOT, is perfect. Thanks for checking.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See previous comments
Pull Request Checklist:
Pre-Approval
master
branch and squash and merged back into themaster
branch.Development
branch, NOTmaster
Post-Approval
Development
branch, remember to use the squash & merge optionDevelopment
branch into the master branch, remember to use the merge optionmaster
branch, a subsequent PR frommaster
intoDevelopment
should be made merge option (i.e., no squash).Development
branch before a tagged release (i.e., before an imminent merge into the master branch), make sure to notify the team and lock theDevelopment
branch to prevent accidental merges while QA takes place. Follow the release protocol here.Thanks for contributing and keeping it clean!