Skip to content
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

Unknown error occurred returned for several error() calls in warnings.php #2881

Closed
JordanMussi opened this issue Oct 19, 2017 · 2 comments
Closed
Labels
b:1.8 Branch: 1.8.x s:resolved Status: Resolved. Solution implemented or scheduled t:bug Type: Bug. An issue causing error / flaw / malfunction
Milestone

Comments

@JordanMussi
Copy link
Contributor

Several error messages are using language strings from datahandler_warnings but that language file is not loaded in the warnings.php context, thus causing null to be passed to error() which falls back to An unknown error has occurred.

The fix is a simple $lang->load("datahandler_warnings"); underneath the current $lang->load("warnings");. However I thought it be best to discuss if the language strings should be copied to the warnings language file instead? It might be unexpected the datahandler language file being loaded outside the datahandler so should probably be avoided.

There may be more instances of this sort of use of datahandler language string use around other parts of the codebase.

@euantorano
Copy link
Member

Duplicating language strings is kind of annoying IMO, so I'd just load the data handler warnings instead of making life more difficult for translators.

@JordanMussi
Copy link
Contributor Author

There is one other place where datahandler language strings have been used:

mybb/usercp.php

Lines 261 to 265 in efce224

// Set allowed value otherwise select options disappear
if(in_array($lang->userdata_invalid_birthday_privacy, $errors))
{
$mybb->input['birthdayprivacy'] = 'none';
}

This section of code was introduced in 32c55f6 fixing Issue 2077.

This is a weird one because the expression would never evaluate to true as the language string isn't loaded. Having done some testing, what it was supposed to avoid doesn't actually happen without the block so it could be removed. For now I've modified the block so that it resets the option to the value stored in the DB.

euantorano pushed a commit that referenced this issue Jan 15, 2018
@Starpaul20 Starpaul20 added this to the 1.8.15 milestone Jan 15, 2018
@Starpaul20 Starpaul20 added t:bug Type: Bug. An issue causing error / flaw / malfunction b:1.8 Branch: 1.8.x s:resolved Status: Resolved. Solution implemented or scheduled labels Jan 15, 2018
Eldenroot pushed a commit to Eldenroot/mybb that referenced this issue May 8, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
b:1.8 Branch: 1.8.x s:resolved Status: Resolved. Solution implemented or scheduled t:bug Type: Bug. An issue causing error / flaw / malfunction
Projects
None yet
Development

No branches or pull requests

3 participants