Just started getting this error today. I added a few new products this morning without any problems. It only appears when in Admin->Catalog->Products and viewing a products fields.
Notice: Undefined offset: 0 in ./core/fn.catalog.php on line 1313
Hello Racingsolution,
[quote name='racingsolution' timestamp='1308507964' post='115292']
Just started getting this error today. I added a few new products this morning without any problems. It only appears when in Admin->Catalog->Products and viewing a products fields.
Notice: Undefined offset: 0 in ./core/fn.catalog.php on line 1313
[/quote]
We are sorry to hear that you experience such a problem.
It seems that the debug error module is enabled in your store. In order to disable it, remove this part of the code:
error_reporting(E_ALL);
ini_set('display_errors', 'On');
in the “config.local.php” file located in the root directory of your CS-Cart installation.
—
Anastasiya Kozlova
CS-Cart Support team
Wouldn't it be best to provide a solution to the problem rather than recommend that the error reporting of the problem be turned off?
Hello Tbirnseth,
[quote name='tbirnseth' timestamp='1308596988' post='115372']
Wouldn't it be best to provide a solution to the problem rather than recommend that the error reporting of the problem be turned off?
[/quote]
Thank you for the reply.
There is nothing dangerous in displaying PHP notices in a standard CS-Cart installation. Notices only remind developers about undefined or unused variables.
It seems that this problem occurred because of incorrect creation of option combinations. In order that we can provide an exact solution to the problem, we need to investigate the issue on this server. As a quick solution we provided the mentioned code.
Thank you for understanding.
—
Anastasiya Kozlova
CS-Cart Support team
Or references to indexes that don't exist (most common) and that usually indicates a deeper problem in my experience especially when the error occurs in a return statement.
The product would be best served to have error_reporting(E_ALL) in place and during QA, to have 'display_errors' be true for both customer and admin views and then in production have 'display_errors' be false for the customer side, but enabled for Admin so that deeper problems can be identified and resolved.
In regard to a poorly configured option combination… The software should detect the problem, not try to access data that doesn't exist. You have good defensive code in place for most things and in this case you are using a ternary operator to try and return a correct value but $product_ids is zero and there is no $options[$product_ids] which is the return value in that case for fn_get_product_options().
Dear Tbirnseth,
[quote name='tbirnseth' timestamp='1308680840' post='115451']
Or references to indexes that don't exist (most common) and that usually indicates a deeper problem in my experience especially when the error occurs in a return statement.
The product would be best served to have error_reporting(E_ALL) in place and during QA, to have 'display_errors' be true for both customer and admin views and then in production have 'display_errors' be false for the customer side, but enabled for Admin so that deeper problems can be identified and resolved.
In regard to a poorly configured option combination… The software should detect the problem, not try to access data that doesn't exist. You have good defensive code in place for most things and in this case you are using a ternary operator to try and return a correct value but $product_ids is zero and there is no $options[$product_ids] which is the return value in that case for fn_get_product_options().
[/quote]
Thank you for the reply.
Yes, we almost agree with you. The occurred problem requires careful investigation on the server and it should be resolved by making necessary code changes to standard CS-Cart files. Also the problem should not be resolved by commenting out the debug module code.
Also we did not notice this problem in a standard CS-Cart installation, so that is why we could not provide the exact solution to prevent this issue. If Racingsolution contacts us via Customer Help Desk and sends us a detailed instruction on how to reproduce the problem, we will investigate the problem more thoroughly.
—
Anastasiya Kozlova
CS-Cart Support team
I've seen this come up before in the 2.0 series which is why I am a bit familiar with it.
There's the original problem to address in the option configuration as well as adding some defensive code so that if a problem is detected, the function will return array() versus FALSE or UNDEFINED.
Dear Tbirnseth,
[quote name='tbirnseth' timestamp='1308772857' post='115531']
I've seen this come up before in the 2.0 series which is why I am a bit familiar with it.
There's the original problem to address in the option configuration as well as adding some defensive code so that if a problem is detected, the function will return array() versus FALSE or UNDEFINED.
[/quote]
Thank you for the reply.
Yes, we remember that you experienced this problem in one of old CS-Cart versions. But it seems that we failed to reproduce this problem in order to understand what code should be fixed.
Sorry for any possible inconveniences.
—
Anastasiya Kozlova
CS-Cart Support team
Well, maybe it can be recreateable now…
Please share solution when you find it (original option issue as well as the defensive code changes).
Dear Tbirnseth,
[quote name='tbirnseth' timestamp='1308874727' post='115632']
Well, maybe it can be recreateable now…
Please share solution when you find it (original option issue as well as the defensive code changes).
[/quote]
Thank you for the reply.
If we find a solution, we will post it here.
—
Anastasiya Kozlova
CS-Cart Support team