Post by tilly » Fri Feb 02, 2018 4:39 am

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

Newbie

Posts

Joined
Thu Feb 01, 2018 1:36 am

Post by straightlight » Fri Feb 02, 2018 6:51 am

Which PHP version do you use?

Also ensure your database uses the collation of utf8_general_ci .

The most generated errors being found on Opencart forum originates from contributed programming. The increased post counters are caused by redundancies of the same solutions that were already provided prior.


Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by tilly » Fri Feb 02, 2018 10:11 pm

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

Newbie

Posts

Joined
Thu Feb 01, 2018 1:36 am

Post by tilly » Fri Feb 02, 2018 10:22 pm

getting the same error during checkout with Paypal - seems to affect payments - pp_standard.php line 50/51

Newbie

Posts

Joined
Thu Feb 01, 2018 1:36 am

Post by tilly » Sat Feb 03, 2018 12:42 am

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

Newbie

Posts

Joined
Thu Feb 01, 2018 1:36 am

Post by straightlight » Sat Feb 03, 2018 5:50 am

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?

The most generated errors being found on Opencart forum originates from contributed programming. The increased post counters are caused by redundancies of the same solutions that were already provided prior.


Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by tilly » Sat Feb 03, 2018 10:25 pm

sorry I didn't specify above but it is the correct one - utf8_general_ci

Newbie

Posts

Joined
Thu Feb 01, 2018 1:36 am

Post by straightlight » Sat Feb 03, 2018 10:54 pm

The PHP file name is not specified with your issue. From which location / exact and precise route does this issue occur from?

The most generated errors being found on Opencart forum originates from contributed programming. The increased post counters are caused by redundancies of the same solutions that were already provided prior.


Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by tilly » Sun Feb 04, 2018 12:28 am

2 places so far:
1 - PayPal checkout - see attachement
2 - Editing Offline Credit Card Payment extension - see attachment

Attachments

offline.png

offline.png (65.91 KiB) Viewed 10561 times

paypal.png

paypal.png (90.12 KiB) Viewed 10561 times


Newbie

Posts

Joined
Thu Feb 01, 2018 1:36 am

Post by straightlight » Sun Feb 04, 2018 12:49 am

"UTF-8;" but removed the semi-colon and no difference. V3.0.2.0
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.

The most generated errors being found on Opencart forum originates from contributed programming. The increased post counters are caused by redundancies of the same solutions that were already provided prior.


Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by tilly » Sun Feb 04, 2018 1:00 am

OpenCart © 2009-2018 All Rights Reserved.
Version 3.0.2.0

I will contact him again (he says its for this version), but what about the PayPal issue?

Attachments

offline.2.jpg

offline.2.jpg (251.49 KiB) Viewed 10547 times


Newbie

Posts

Joined
Thu Feb 01, 2018 1:36 am

Post by straightlight » Sun Feb 04, 2018 1:04 am

Quite unusual to use the htmlspecialchars for an API regarding PayPal for output purposes.

In catalog/controller/extension/payment/pp_standard.php file,

find:

Code: Select all

'name'     => htmlspecialchars($product['name']),
					'model'    => htmlspecialchars($product['model']),
					
replace with:

Code: Select all

'name'     => html_entity_decode($product['name'], ENT_QUOTES, 'UTF-8'),
					'model'    => html_entity_decode($product['model'], ENT_QUOTES, 'UTF-8'),
This should rectify the issue.

The most generated errors being found on Opencart forum originates from contributed programming. The increased post counters are caused by redundancies of the same solutions that were already provided prior.


Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by tilly » Sun Feb 04, 2018 1:21 am

Thanks, I'll give it a shot on Monday and let you know what happens.

Newbie

Posts

Joined
Thu Feb 01, 2018 1:36 am

Post by billynoah » Sun Feb 04, 2018 5:28 am

@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:

Code: Select all

$this->config->set('template_engine', 'template');
$this->response->setOutput($this->load->view('extension/payment/offline_cc', $data));
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.

Image


User avatar
Active Member

Posts

Joined
Tue Jan 15, 2013 12:46 pm

Post by straightlight » Mon Feb 05, 2018 12:22 am

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:

Code: Select all

html_entity_decode($var, ENT_QUOTES, 'UTF-8') 
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.

The most generated errors being found on Opencart forum originates from contributed programming. The increased post counters are caused by redundancies of the same solutions that were already provided prior.


Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by billynoah » Mon Feb 05, 2018 2:45 am

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.

Code: Select all

string html_entity_decode ( string $string [, int $flags = ENT_COMPAT | ENT_HTML401 [, string $encoding = ini_get("default_charset") ]] )
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.
Last edited by billynoah on Mon Feb 05, 2018 2:52 am, edited 2 times in total.

Image


User avatar
Active Member

Posts

Joined
Tue Jan 15, 2013 12:46 pm

Post by straightlight » Mon Feb 05, 2018 2:51 am

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.
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 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?

The most generated errors being found on Opencart forum originates from contributed programming. The increased post counters are caused by redundancies of the same solutions that were already provided prior.


Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by billynoah » Mon Feb 05, 2018 2:58 am

straightlight wrote:
Sun Feb 04, 2018 12:49 am
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.
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:
Mon Feb 05, 2018 2:51 am
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?
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.

Image


User avatar
Active Member

Posts

Joined
Tue Jan 15, 2013 12:46 pm

Post by straightlight » Mon Feb 05, 2018 3:01 am

I never said there's no need to use a function. I'm fine with that.
There's no reason to specify the character set for a function when it's already part of the configuration file.
The config file might be botched. Although, using the right functions to prevent this issue is also possible.

The most generated errors being found on Opencart forum originates from contributed programming. The increased post counters are caused by redundancies of the same solutions that were already provided prior.


Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by billynoah » Mon Feb 05, 2018 3:09 am

straightlight wrote:
Sun Feb 04, 2018 1:04 am
Quite unusual to use the htmlspecialchars for an API regarding PayPal for output purposes.
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.

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.

Image


User avatar
Active Member

Posts

Joined
Tue Jan 15, 2013 12:46 pm
Who is online

Users browsing this forum: rjcalifornia, todavy and 24 guests