Opencart 1.5.6.4 with PHP 7.1

Hello,
My update to php 7.1 went fine with only one contrib that I see that kicks an error BUT still seems to function.
It is for multi-store and prevents people from logging in using accounts from different stores to log into other stores....

In controller/account/login.php I added under protected function validate() {
Added this section:
$customer_info = $this->model_account_customer->getCustomerByEmail($this->request->post['email']);
$customerGroupId = isset($customer_info['customer_group_id']) ? $customer_info['customer_group_id'] : -1;
$allowedCustomerGroups = $this->config->get('config_customer_group_display');
if(!is_array($allowedCustomerGroups) || !in_array($customerGroupId, $allowedCustomerGroups))
{
$this->error['warning'] = $this->language->get('error_login');
return false

It still works but AT TIMES and no time I can pin-point, the log has this in it:
undefined index email in controller/account/login.php on line 202

The first line I added is line 202. So The question is why this error gets logged now under php 7.1 when it didn't kick an error before?

Thank you,
Mike

It still works but AT TIMES and no time I can pin-point, the log has this in it:
undefined index email in controller/account/login.php on line 202

The first line I added is line 202. So The question is why this error gets logged now under php 7.1 when it didn't kick an error before?

You still need to validate the $this->request->post['email'] prior to pass its super global parameter from the browser into the model. Otherwise, the validate() method may loose its focus since the login page may rely on a last entry point of location on the store-front where the email parameter may not be defined at that specific time period.

straightlight wrote: ↑

Sun Jun 02, 2019 7:18 am

You still need to validate the $this->request->post['email'] prior to pass its super global parameter from the browser into the model. Otherwise, the validate() method may loose its focus since the login page may rely on a last entry point of location on the store-front where the email parameter may not be defined at that specific time period.

By validate, do you mean validate it is set? i.e. isset ?

Also why was it working prior to the update to php 7.1?
Thank you,
Mike

[quote[
By validate, do you mean validate it is set? i.e. isset ?
[/quote]

Correct.

Also why was it working prior to the update to php 7.1?

Industrial change. Which is why, troubleshooting is important so not to stick on same OC version for several years.

straightlight wrote: ↑

Sun Jun 02, 2019 9:16 am

By validate, do you mean validate it is set? i.e. isset ?

Correct.

Also why was it working prior to the update to php 7.1?

Industrial change. Which is why, troubleshooting is important so not to stick on same OC version for several years.

Thank you for the replies...

And there brings up the issue....
1.5.6.4 was (is?) the most stable version I've ran but beyond that the contibs I have are almost critical to making my store run well and easy.
i.e.
At least 4 times a year major number of product price changes and usually with a few days notice that changes are needed.
Daily quantity updates (via background ran admin cronjob)
SEO auto modules that work but are no longer supported
My template
etc.

I also don't know the differences between 1.5.6.4 and 3.0.x and especially I do not know twig so it might be a steep learning curve. Also I'd like to keep my order and customer data.

Thank you,
Mike

Cue4cheap wrote: ↑

Sun Jun 02, 2019 10:12 am

straightlight wrote: ↑

Sun Jun 02, 2019 9:16 am

By validate, do you mean validate it is set? i.e. isset ?

Correct.

Also why was it working prior to the update to php 7.1?

Industrial change. Which is why, troubleshooting is important so not to stick on same OC version for several years.

Thank you for the replies...

And there brings up the issue....
1.5.6.4 was (is?) the most stable version I've ran but beyond that the contibs I have are almost critical to making my store run well and easy.
i.e.
At least 4 times a year major number of product price changes and usually with a few days notice that changes are needed.
Daily quantity updates (via background ran admin cronjob)
SEO auto modules that work but are no longer supported
My template
etc.

I also don't know the differences between 1.5.6.4 and 3.0.x and especially I do not know twig so it might be a steep learning curve. Also I'd like to keep my order and customer data.

Thank you,
Mike

That is the point of the industrial change. Granted, bug reports have been found and reported and most of them been resolved on GitHub. However, this is what users in general needs to understand; that OC ain't always the source of origin where bugs gets developed but rather the other way around most of the time. It could be simply due to a PHP version change by the industry and programmers as much as for users simply needs to opt and adapt the change based on incident requests being created on the forum and on GitHub.

Well, PHP v.7.1 was not a well-done Version, and should better be
replaced by PHP v.7.2, since it's already near it's end of life cycle.
And the (still most stable ) OC v.1.5.6.5_rc works well with PHP 7.2x,
after replacing the system/library/encryption.php file, similar
to later OC Versions, requiring the same change, to further function.
Ernie
---