Undefined index: spider_flag

[masterrusty]

1.5.7b
Php 7.4
Fantasycostume.com

[12-Mar-2022 00:21:59 UTC] PHP Notice: Undefined index: spider_flag in /home/fant8380/public_html/includes/classes/observers/class.products_viewed_counter.php on line 37

That is all that is in the log...
error every 15 seconds or so with no one on site..

Any ideas?

[mc12345678]

1.5.7b
Php 7.4
Fantasycostume.com

[12-Mar-2022 00:21:59 UTC] PHP Notice: Undefined index: spider_flag in /home/fant8380/public_html/includes/classes/observers/class.products_viewed_counter.php on line 37

That is all that is in the log...
error every 15 seconds or so with no one on site..

Any ideas?

Really, really, really should upgrade to 1.5.7d. That issue was addressed by the following pull request in Github: https://github.com/zencart/zencart/pull/3796/files

The red color represents removed content, the green is added information.

[Fantasyland]

Really, really, really should upgrade to 1.5.7d. That issue was addressed by the following pull request in Github: https://github.com/zencart/zencart/pull/3796/files

The red color represents removed content, the green is added information.

Hi. My developer was randomly thrown out of this forum for no reason with no explanation, but I still have this problem.

I managed to get the site upgraded to 1.5.7b, but it was still getting spider_flag errors. At this point, I have a 100% raw version of 1.5.7b running at test.fantasycostume.com and it throws a spider_flag error with every click.

I checked the 1.5.7d code and it has the update defined in your link, but it is not solving the problem.

[Fantasyland]

This new raw version of Zen 1.5.7d was using my old database (been in use and upgrading since 1.3.9). Thinking there my be some dross in that database, I changed over to a new blank database generated by zc_install.

Now I am getting this error every click.

PHP Warning: Trying to access array offset on value of type null in /home/fant8380/store/wax_candles/includes/classes/VersionServer.php on line 89.

It is starting to look like this new version of Zen is flawed. Is that why I can't get any answers here?

[mc12345678]

Hi. My developer was randomly thrown out of this forum for no reason with no explanation, but I still have this problem.

I managed to get the site upgraded to 1.5.7b, but it was still getting spider_flag errors. At this point, I have a 100% raw version of 1.5.7b running at test.fantasycostume.com and it throws a spider_flag error with every click.

I checked the 1.5.7d code and it has the update defined in your link, but it is not solving the problem.

I have no knowledge, input, or other information on your previous developer. That would be to be addressed through the forum moderators or others in the know.

As to the continued issue(s) in the above quoted post, I don't see how the exact same error message can occur associated with $spider_flag if the changes of the above link are applied to the current store configuration. So, either logs were continuing to be created but with different information or the changes were not applied, or there is some other modification made to the base store software not related to the core code.

As to the logging related to the remote server, those logs are being caused by 1) the version server having some form of communication issue, 2) a software development issue that wasn't previously strictly tested because the server was so reliably available and 3) made known only in particular operating environments. *A* resolution to that issue was made by the following code change: https://github.com/zencart/zencart/pull/4692/files though even the originally proposed solution which at the time was working has been put under question. Of course I personally hope that the version server wasn't put into its current state just to perform testing and I'm a little surprised that the previous fix has been completely undone as the follow on proposal doesn't offer the same level of evaluation that was originally provided.

[Fantasyland]

Thank you so much for the reply mc12345678!

I am checking on the code change you referred to. In the mean time, I have found that the error I got after setting up the RAW store was an anomaly. Hours later the site was operating without errors.

However, when I installed my database the errors started up again. Are you aware of some way some dross could have been created in the database that could cause this?

As I mentioned, this database has been in use, and getting upgraded, since 1.3.9. I found something on this site that says the current db version is 1.5.7c. As far as I know, zc_install did not upgrade my db when I upgraded from 1.5.5 to 1.5.7b, and it definitely did not do a db upgrade going from 1.5.7b to 1.5.7d.

[Fantasyland]

Code change defined at https://github.com/zencart/zencart/pull/4692/files had no effect.

[carlwhat]

@fantasyland, i will comment on the 3 things you seem to have brought up:

• while i can not comment on the specifics of your developer's situation, there have been times when the software that runs this board has blocked me for no apparent reason. if your developer was thrown out and would like to be reinstated, and assuming he did not commit a heinous act (which could be different for many people), contact @swguy to get them reinstated.
• with regards to your spider_flag issue that you resolved by a new database install, i am pretty sure that if you went admin -> configuration -> sessions -> force cookie usage, that was set to true. that seems to be a bug in the code. if set to false, that would eliminate that error. you can obviously try that yourself.
• with regards to your server version problem, you can go to: admin -> configuration -> my store -> Show if version update available and set that to false. that should resolve your other problem.

hope that helps.

[swguy]

We have a lot of spam problems and the forum software is really strict. In particular, if an email bounces (perhaps because you have changed your email address), you get kicked off.

[mc12345678]

Thank you so much for the reply mc12345678!

I am checking on the code change you referred to. In the mean time, I have found that the error I got after setting up the RAW store was an anomaly. Hours later the site was operating without errors.

However, when I installed my database the errors started up again. Are you aware of some way some dross could have been created in the database that could cause this?

As I mentioned, this database has been in use, and getting upgraded, since 1.3.9. I found something on this site that says the current db version is 1.5.7c. As far as I know, zc_install did not upgrade my db when I upgraded from 1.5.5 to 1.5.7b, and it definitely did not do a db upgrade going from 1.5.7b to 1.5.7d.

Welcome to the "new" Zen Cart. Sub-version 1.5.7d appears to have been pushed somewhat in haste. I do not know the reason, I just know that none of the usual/basic updates were made in reference to that sub-version (ie. the zc_install files such as the full sql install, the sub-version update and at least one other significant location were *not* updated to show 1.5.7d.) Then... please consider this overall software. What is important, what is a great idea and what prevents a sale... This sub-version issue has ZERO affect on the ability of the store to operate. One or more someones omitted a review and correction, darn...

Now, these logs or issues... The term "error" keeps getting used... Error is a specific problem. There is also warning and notice. Of course sure a fatal error, but it's still an error just one that is more extreme. If the site is still functional from "start" to "finish", it's very unlikely that the occurrence is an error, probably at worst a warning. So, to figure out what is going on, the content of the logs.. The *debug* logs or specifically myDebug logs needs to be reviewed to identify what happened and why.

Look at the file(s) and if the issue of the latest file has been corrected and more logs are being generated, then correct the latest entry of the most recent file. Review again...

To assume that the software will have zero defects in its release for all possible environments some of which may never have been tested is unrealistic. There is no product that doesn't require some sort of correction of some sort at some time after its release. Think of the fact that there are over 600 configuration table entries. If each entry had only 2 settings (e.g. off or on), then that would equate to more than 4 x 10^180 potential configurations... While all of the above is just estimates and rough determinations, good luck trying to set and check each and every one of those configurations though proper testing would also attempt to use data outside of the constraints so that potential/possible issues might be identified/corrected.

Again, could there be something in the database that might cause a log file to be generated? SURE... But, what is being logged? It may be nothing, it may need correction, perhaps something about the server needs to be made better but the software is fine.