My custom page is redirected to cookie_usage when called using 'wget'

I'm developing a custom page to perform some nightly maintenance on the database.
When I browse to it using Chromium or Firefox, it does exactly what I expect it to. However, if I call it using 'wget' (V1.15) it is redirected (302) to the cookie_usage page.

Since this is my first attempt at building a custom page I have based the structure and boilerplate of my page on an existing module, sitemapxml. The functionality, however, is nothing at all to do with sitemapxml. My page is on the catalogue side, in /includes/modules/pages/my_update with a template in /includes/templates/template_default/my_update and a class to implement the functionality in /includes/classes.

Calling sitemapxml using wget works correctly. In fact, this is how it is usually called via a cron job. I want to do the same with my code but cannot get it to execute using wget. I have not disabled cookies in wget and the fact that it works with sitemapxml suggests that I have it configured correctly. I use:

wget 'http://www.xxxx.com/index.php?main_page=my_update&action=update&imagedir=genuine_images&all_images=1&max_records=10' -O my_update_test.html -o my_update_test.log

I have also tried setting wget's user-agent string to the same as Chromium uses but this seems to make no difference. I have removed all the business logic from my page and still get the redirect.

I understand that ZenCart must be trying to determine that the caller supports cookies and deciding that it doesn't. What could the difference be between two custom pages such that one is redirected to cookie_usage and the other is not, given that both pages are retrieved in the same way?

I've searched the forum and I've searched the ZenCart code to find the only places where the redirect is made are in code that requires a session (e.g. login or checkout). My code doesn't require a session and doesn't try to log in.

I'm developing a custom page to perform some nightly maintenance on the database.
Why not use ZenCarts builtin maintanance function settable in the admin

Then edit a copy of this file "nddbc.html" with your "custom" content leave the name the same and test it

kobra:

Why not use ZenCarts builtin maintanance function settable in the admin

Then edit a copy of this file "nddbc.html" with your "custom" content leave the name the same and test it
Thanks for the quick response, kobra. However, I'm not sure how that helps. Wouldn't it make the entire shop inaccessible to customers while the maintenance is going on? Wouldn't the task stop running when a user cancels loading of nddbc.html? And how could it be scheduled automatically to enter maintenance mode at a certain time? On most servers, would any PHP code be executed at all in a file with extension ".html"?

The maintenance task is to update a list of about 55,000 products from a supplier's system. The supplier's system is pretty slow to respond so the task needs to run overnight, every night, in order to update the entire list once a week. Say about 12 hours per night. The slow response of the supplier's system means bandwidth requirement is low, however, and running overnight avoids the busiest time for their system and ours. All the logic to achieve this - fetching product details, updating the database, terminating after x hours, etc. - is handled within the custom page 'my_update'.

This task needs to run in the background so that the site will be accessible during this time. I think the scheme of fetching the page via wget in a cron job is a reasonable one as it is used by other modules. I just need to know what could be causing my page to be redirected to cookie_usage when other modules can be executed successfully in the same way.

To clarify, what I have is a custom page at: http://www.xxxx.com/index.php?main_page=my_update

BillJ:

To clarify, what I have is a custom page at: http://www.xxxx.com/index.php?main_page=my_update

The index.php?main_page= route is for customers/visitors, not for maintenance.

For maintenance, create a handler script in the root of your site such as daily_update_script.php and have it include('includes/application_top.php') and then do whatever maintenance you require.
If for some reason you need to bypass part of the init_system you can clone the config.core.php auto_loaders file as my_daily_update.core.php and remove from it whatever you wish to skip, and then tell your daily_update_script.php to utilize that by setting $loaderPrefix ='my_daily_update'; before calling application_top.

Thanks very much, DrByte. I'll do it that way, then. It should be simple enough to change it round. I'll put it in /cgi-bin, in fact.

Since I've seen that other modules do it the way I was attempting, I am still keen to understand what might make those modules callable from wget while mine would redirect to cookie_usage (despite cookies being enabled in wget).

What might trigger this behaviour?