Getting this in an extension where the developer says its not his issue
Warning: htmlentities() charset `UTF-8;' not supported, assuming utf-8
what I find is odd is the semi-colon after UTF-8 and the ` (tick on the tilde key) before - thinking there is a typo somewhere, just don't know where. Any ideas? I did see in my .htaccess that I had php_value default_charset "UTF-8;" but removed the semi-colon and no difference. V3.0.2.0
Thanks
Which PHP version do you use?
Also ensure your database uses the collation of utf8_general_ci .
Also ensure your database uses the collation of utf8_general_ci .
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
ea-php56 , database is the correct collation
Server: Localhost via UNIX socket
• Server type: MySQL
• Server version: 5.6.38 - MySQL Community Server (GPL)
• Protocol version: 10
• User: blah@localhost
• Server charset: UTF-8 Unicode (utf8)
cpsrvd 11.68.0.28
• Database client version: libmysql - 5.1.73
• PHP extension: mysqliDocumentation curlDocumentation mbstringDocumentation
• PHP version: 5.6.30
Server: Localhost via UNIX socket
• Server type: MySQL
• Server version: 5.6.38 - MySQL Community Server (GPL)
• Protocol version: 10
• User: blah@localhost
• Server charset: UTF-8 Unicode (utf8)
cpsrvd 11.68.0.28
• Database client version: libmysql - 5.1.73
• PHP extension: mysqliDocumentation curlDocumentation mbstringDocumentation
• PHP version: 5.6.30
Here are the error logs
2018-02-02 13:54:09 - PHP Warning: htmlspecialchars(): charset `UTF-8;' not supported, assuming utf-8 in /home/jwagnergd/public_html/catalog/controller/extension/payment/pp_standard.php on line 50
2018-02-02 13:54:09 - PHP Warning: htmlspecialchars(): charset `UTF-8;' not supported, assuming utf-8 in /home/jwagnergd/public_html/catalog/controller/extension/payment/pp_standard.php on line 51
2018-02-02 14:02:16 - PHP Warning: htmlentities(): charset `UTF-8;' not supported, assuming utf-8 in /home/jwagnergd/public_html/admin/view/template/extension/payment/offline_cc.tpl on line 48
2018-02-02 14:02:16 - PHP Warning: htmlentities(): charset `UTF-8;' not supported, assuming utf-8 in /home/jwagnergd/public_html/admin/view/template/extension/payment/offline_cc.tpl on line 55
2018-02-02 13:54:09 - PHP Warning: htmlspecialchars(): charset `UTF-8;' not supported, assuming utf-8 in /home/jwagnergd/public_html/catalog/controller/extension/payment/pp_standard.php on line 50
2018-02-02 13:54:09 - PHP Warning: htmlspecialchars(): charset `UTF-8;' not supported, assuming utf-8 in /home/jwagnergd/public_html/catalog/controller/extension/payment/pp_standard.php on line 51
2018-02-02 14:02:16 - PHP Warning: htmlentities(): charset `UTF-8;' not supported, assuming utf-8 in /home/jwagnergd/public_html/admin/view/template/extension/payment/offline_cc.tpl on line 48
2018-02-02 14:02:16 - PHP Warning: htmlentities(): charset `UTF-8;' not supported, assuming utf-8 in /home/jwagnergd/public_html/admin/view/template/extension/payment/offline_cc.tpl on line 55
Based on the specifications you provided above, the most important question has not been answered - which database table collation structure do you currently use for the Opencart database?
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
The PHP file name is not specified with your issue. From which location / exact and precise route does this issue occur from?
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
Your screenshot mentions: .tpl file. You are NOT using v3.0.2.0 and / or you are using an incompatible extension with v3.0.2.0. offline_cc does not exist in the OC core. Contact the extension developer to resolve this issue."UTF-8;" but removed the semi-colon and no difference. V3.0.2.0
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
Quite unusual to use the htmlspecialchars for an API regarding PayPal for output purposes.
In catalog/controller/extension/payment/pp_standard.php file,
find:
replace with:
This should rectify the issue.
In catalog/controller/extension/payment/pp_standard.php file,
find:
Code: Select all
'name' => htmlspecialchars($product['name']),
'model' => htmlspecialchars($product['model']),
Code: Select all
'name' => html_entity_decode($product['name'], ENT_QUOTES, 'UTF-8'),
'model' => html_entity_decode($product['model'], ENT_QUOTES, 'UTF-8'),
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
@Straightlight, I am the extension developer and yes, you can certainly use tpl files in OC3. The tpl is for the admin UI only and it's quite easy specify the template engine in admin controller without affecting anything else. Front end is a bit more of an issue but adapting complex php driven OC2 admin views that are already written as tpl beats rewriting things as twig:
Regarding the charset issue, it's almost certainly a misconfiguration in the php settings. You can see in the errors he posted that somewhere in .htaccess, php.ini or elsewhere the charset is specified as UTF-8; whereas it should be utf-8 lowercase without an extra semi-colon. I advised @tilly about this days ago and but seems he ignored my advice and started a thread here instead. You can certainly override system settings by specifying it directly in the function calls but it will not fix the underlying issue which is guaranteed to affect other code in your installation which relies on the configured character set.
Code: Select all
$this->config->set('template_engine', 'template');
$this->response->setOutput($this->load->view('extension/payment/offline_cc', $data));
One downside by using an enforced setting to use the template is the interference toward other extensions that may use template switching from the Marketplace, for instance, since these extensions uses an override method in order to parse those template files. In addition, despite the settings of the .htaccess file, while it may require lower case for the UTF-8 translation, Opencart already uses the html_entity_decode function which, in this case, PayPal standard did not contained. By using this function, it will automatically be parsed appropriately on the web page. This is extremely and crucially useful when gathering data from countless APIs which is why this user encountered that error message. Countless examples can also be found in controller files requiring to initiate call requests via API endpoints which includes different ways of translations. Although, the right one must be used for each results being obtained in return.
Since this error message also appears in the admin-end from your extension, I would still suggest the use of the already implemented solution of the:
added in your extension in order to avoid UTF-8 error messages which will also prevent users on having to modify domain files. This user may not have necessarily ignored your statement, it may rather simply be because, based on his knowledge and experience, may not be on the same level as others and, also adding, this as not being exactly a technological issue. Which is why, this user may have rather decided to create a new topic so to find an alternate solution which is not an irrelevant approach in this case since, again, Opencart does use its own function to parse UTF-8 translations with unicodes.
Since this error message also appears in the admin-end from your extension, I would still suggest the use of the already implemented solution of the:
Code: Select all
html_entity_decode($var, ENT_QUOTES, 'UTF-8')
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
There's no reason to specify the character set for a function when it's already part of the configuration file. Especially if it introduces the risk of potentially overriding something the sys admin has specifically configured. In this case it looks more like someone left a syntax error in the config file and it's not the dev's responsibility to address that in the admin UI. The system administrator needs to fix the php config, plain and simple.
Notice it uses the system parameter "default charset". That should be perfectly acceptable and it is used throughout Opencart core. It's not just my extension but other parts of his installation which are being affected.Should we scour the github repo for any instance of html_entity_decode() and htmlspecialchars() and hard code a charset override out of concern that some sysadmin somewhere screwed up their php.ini file?
As for using tpl in OC3, there's no issue there. You said something that isn't true and I was just pointing it out to avoid any further misconception.
Code: Select all
string html_entity_decode ( string $string [, int $flags = ENT_COMPAT | ENT_HTML401 [, string $encoding = ini_get("default_charset") ]] )As for using tpl in OC3, there's no issue there. You said something that isn't true and I was just pointing it out to avoid any further misconception.
Last edited by billynoah on Mon Feb 05, 2018 2:52 am, edited 2 times in total.
Is that so? Then, perhaps you could explain on why exactly the admin/controller/event/theme.php uses conditional if statements rather than an enforced line when implying the use of TPL files rather than TWIG files? Granted, it may not be necessary to use TWIG files in OC 3 but nowhere else do I see an enforced solution to use TPL files as per the code described on the above either.As for using tpl in OC3, there's no issue there. You said something that isn't true and I was just pointing it out to avoid any further misconception.
As for the UTF-8 function, if there's no need to use a function, then perhaps you could also explain on why exactly it is already in use in the core which works pretty well already?
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
That is what you said. It isn't true. That's all I was addressing and I'm not interested in debating about this.straightlight wrote: ↑Sun Feb 04, 2018 12:49 amYour screenshot mentions: .tpl file. You are NOT using v3.0.2.0 and / or you are using an incompatible extension with v3.0.2.0.
I never said there's no need to use a function. I'm fine with that. I'm just saying that his errors are coming from files that are part of the OC core. The reason Opencart AND my extension are throwing errors here are because the config file is botched, not because of a code issue. In fact YOu are the one who suggested he should patch the OC core in this thread. You are contradicting yourself now.straightlight wrote: ↑Mon Feb 05, 2018 2:51 amAs for the UTF-8 function, if there's no need to use a function, then perhaps you could also explain on why exactly it is already in use in the core which works pretty well already?
I never said there's no need to use a function. I'm fine with that.
The config file might be botched. Although, using the right functions to prevent this issue is also possible.There's no reason to specify the character set for a function when it's already part of the configuration file.
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
Ok well then why don't you take your complaint to Daniel or do a pull request and leave me out of it. See lines 50,51 here: https://github.com/opencart/opencart/bl ... andard.php.straightlight wrote: ↑Sun Feb 04, 2018 1:04 amQuite unusual to use the htmlspecialchars for an API regarding PayPal for output purposes.
These are the so called files in question that according to you should be "using the right functions to prevent this issue". I'm honestly confused by your position on this. I'm just trying to point him in the right direction. As long as his config file is messed up it's not going to be easy to run Opencart or any other web application for that matter.
Who is online
Users browsing this forum: No registered users and 541 guests
