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

Ok well then why don't you take your complaint to Daniel or do a pull request
tilly wrote:
Sun Feb 04, 2018 1:21 am
Thanks, I'll give it a shot on Monday and let you know what happens.

Dedication and passion goes to those who are able to push and merge a project.

Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

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

Post by tilly » Mon Feb 05, 2018 8:30 pm

This is a fresh install of OC, I have other stores that use 1.5.x and decided to change servers and refresh. The reason I posted here is based on seeing the semi-colon and tick in the exception, I thought there was something in the code base that was perhaps a typo, and since it was happening in more than 1 extension, that it was in the code base. The .htaccess was created automatically with php_value default_charset "UTF-8;" in it but removing the semi colon didn't change anything. As you can see above the collation is correct.

Also, should the UTF-8 be in quotes in the .htaccess? in the php.ini, it is not.

Billy, you have code that has UTF-8 (in capitals) in the extension, are you saying that that should be lowercase? BTW, none of these (utf-8 lowercase updates) changes have fixed cc_offline, still need to test PayPal.

Newbie

Posts

Joined
Thu Feb 01, 2018 1:36 am

Post by billynoah » Tue Feb 06, 2018 2:48 am

tilly wrote:
Mon Feb 05, 2018 8:30 pm
The .htaccess was created automatically with php_value default_charset "UTF-8;"
Nowhere in the Opencart base has that declaration ever existed. I'm not sure how it made it's way in to your installation but you can verify what I'm saying by browsing the releases on github. In theory, the case shouldn't matter but the semi-colon might and there could very well be something else overriding your settings. Also, different web servers may interpret this directive differently and depends on PHP module. I've emailed you and we can talk tomorrow to get this straightened out. Cheers.

Image


Active Member

Posts

Joined
Tue Jan 15, 2013 12:46 pm

Post by rmullaney77 » Tue Apr 10, 2018 7:50 am

straightlight provided the proper solution...
straightlight wrote:
Sun Feb 04, 2018 1:04 am
In catalog/controller/extension/payment/pp_standard.php file,

find:

Code: Select all

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

Code: Select all

'name'     => html_entity_decode($product['name'], ENT_QUOTES, 'UTF-8'),
'model'    => html_entity_decode($product['model'], ENT_QUOTES, 'UTF-8'),
Issue still present in latest 3.x github repo.

Note: I don't report issues on github anymore. Seen too many "you're an idiot" comments toward others and "this is not a bug" comments by "you-know-who" before closing legitimate bug reports. I just fix them in my own core-fix ocmod(s) for internal/client use :P

--------------------------------------------------
My BlogMy ExtensionsOpenCart Templates


User avatar
Active Member

Posts

Joined
Fri Nov 19, 2010 2:08 am
Location - Tampa, Florida

Post by straightlight » Tue Apr 10, 2018 7:53 am

Issue still present in latest 3.x github repo.
While you indicate the issue is still present on Github, and the user above on this topic did indicated the issue was resolved after the provided solution, did you tried the provided solution above? If so, what were the results?

Dedication and passion goes to those who are able to push and merge a project.

Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

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

Post by billynoah » Tue Apr 10, 2018 8:27 am

As was discussed above, this specific issue was related to an .htaccess syntax error.

Image


Active Member

Posts

Joined
Tue Jan 15, 2013 12:46 pm

Post by straightlight » Tue Apr 10, 2018 8:30 am

The referred github link has already been reported before as I did addressed the issue above on the topic clarifying the fact, and confirmed by other users for these results, that this solution is working accurately. If you remain confused at this point after the results were already provided by others, then there would be nothing simpler at this point than to integrate the solution I already provided on the above to rectify the issue.

Dedication and passion goes to those who are able to push and merge a project.

Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

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

Post by rmullaney77 » Tue Apr 10, 2018 8:38 am

straightlight wrote:
Tue Apr 10, 2018 7:53 am
While you indicate the issue is still present on Github, and the user above on this topic did indicated the issue was resolved after the provided solution, did you tried the provided solution above? If so, what were the results?
Upon finding a solution on page one, did not continue to page 2 (topic seemed to derail thereafter). I checked my htaccess, and while it does not contain the directive, unexpectedly cPanel-generated INI files did. The "default_charset" problem (see below) can be reintroduced by a server manager (WHM) or domain admin (cPanel) using the "MultiPHP INI Editor" in "Basic Mode" without a site owner's knowledge. Explicit flags and encoding in the core should help avoid that.

Code: Select all

; cPanel-generated php ini directives, do not edit
; Manual editing of this file may result in unexpected behavior.
; To make changes to this file, use the cPanel MultiPHP INI Editor (Home >> Software >> MultiPHP INI Editor)
; For more information, read our documentation (https://go.cpanel.net/EA4ModifyINI)

[PHP]
default_charset = "UTF-8;"
memory_limit = 128M
max_execution_time = 30
post_max_size = 8M
upload_max_filesize = 2M
mysql.connect_timeout = 20
session.auto_start = Off
session.use_only_cookies = On
session.use_cookies = On
session.use_trans_sid = Off
session.cookie_httponly = "On;"
session.gc_maxlifetime = 1440
;display_errors = 1;
;error_reporting = E_ALL;
display_errors = Off
max_input_time = 60
max_input_vars = 1000
session.save_path = "/var/cpanel/php/sessions/ea-php70"
zlib.output_compression = Off

--------------------------------------------------
My BlogMy ExtensionsOpenCart Templates


User avatar
Active Member

Posts

Joined
Fri Nov 19, 2010 2:08 am
Location - Tampa, Florida

Post by rmullaney77 » Tue Apr 10, 2018 8:41 am

It is a non-issue for me. Was attempting to show others that was a reasonable solution in my opinion.

Maybe if the setting was validated at 'install/step_3' it would avoid others reporting the same problem ;)

--------------------------------------------------
My BlogMy ExtensionsOpenCart Templates


User avatar
Active Member

Posts

Joined
Fri Nov 19, 2010 2:08 am
Location - Tampa, Florida

Post by straightlight » Tue Apr 10, 2018 8:44 am

These configurations are still server specifics. It can't be reliable as a standard-specific solution since each server configurations are obviously different. Otherwise, it would be of no point from the PHP Industry to create an alternate function with switch cases that would require to convert a string set.

Dedication and passion goes to those who are able to push and merge a project.

Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

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

Post by ADD Creative » Wed Sep 05, 2018 4:19 am

straightlight wrote:
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.
Just did a search for the same error and found this thread. The above is actually wrong. The correct code should be.

Code: Select all

'name'     => $product['name'],
'model'    => $product['model'],
There was a merged pull request https://github.com/opencart/opencart/pull/1348 which incorrectly added the htmlspecialchars. Replacing them with html_entity_decode is also wong as the the strings are use in a form in the template. If they did have a special char in them, it could mess up the form.

The actual root cause of the problem is with this line in the php.ini. https://github.com/opencart/opencart/bl ... php.ini#L3 It should not have the semicolon on the end. It will not affect most setups, but can be a problem in some. One example is with the cPanel and it's MultiPHP INI Editor. It will interpret that value including the semicolon, outputting to the the following to .htaccess.

Code: Select all

php_value default_charset "UTF-8;"
Whereas the correct value should be.

Code: Select all

php_value default_charset "UTF-8"

www.add-creative.co.uk


Expert Member

Posts

Joined
Sat Jan 14, 2012 1:02 am
Location - United Kingdom

Post by straightlight » Wed Sep 05, 2018 4:35 am

These changes are no longer critical since the TWIG engine can already parse those values directly since the implementation into Opencart. Since this is an old topic you are re-addressing, this wasn't considered at that particular time. While the changes on GitHub has been merged, it is still not required to make those changes from PHP when using htmlspecialchars. As for the UTF-8 changes, the research being made has not been provided on where exactly for all servers this change would actually take effect since on the addressed topic, it does use the ; at the end of the UTF-8 line.

Dedication and passion goes to those who are able to push and merge a project.

Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

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

Post by ADD Creative » Thu Sep 06, 2018 12:36 am

The Twig template engine does not change anything as the automatic output escaping is not enabled.

Regarding the UTF-8. That was the whole problem, line 3 of in https://github.com/opencart/opencart/bl ... php.ini#L3 should NOT have the semicolon on the end.

www.add-creative.co.uk


Expert Member

Posts

Joined
Sat Jan 14, 2012 1:02 am
Location - United Kingdom

Post by straightlight » Thu Sep 06, 2018 12:41 am

Regarding the UTF-8. That was the whole problem, line 3 of in https://github.com/opencart/opencart/bl ... php.ini#L3 should NOT have the semicolon on the end.
Thanks for elaborating the root cause for those who do encounter this issue as compared to others.

Dedication and passion goes to those who are able to push and merge a project.

Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

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

Users browsing this forum: Shiftcom, SohBH and 394 guests