Steve80

Thanks, Jack. Finally got it done. Really appreciate your work with regards to things a lot of us don't know too much about 👍👏. Steve

OK.. I hate to be DUMB.. but I AM that :-(.. So.... Using the DELETE option from the install file appears to have done NOTHING. Running the install again also does nothing (new) as far as I can tell. I WAS able to finally figure out that the original add-on installed GOOGLE XML SEO as _group = 289 in the configuration_group table and has the original options in the configuration table. The NEW version that I installed chose a different group_ID of 6502 - but that doesn't show in the configuration_group table. I'm assuming THAT is the source of the problem. Now.. just to be certain .. are you telling me to use phpMyAdmin to go into the Configuration table and DELETE all references to the options for the original version as well as all options for the new version.. then also go into the configuration_group table and also delete the entry for Google XML SEO .. and THEN run the install script file again and THAT should fix it all ?? Sorry.. just trying to make as certain as possible that I don't do something to HOSE my entire shop. I'm assuming that after I delete all those items, I could go into my site Admin and see that the Google XML SEO option is GONE.. and then after REinstallation, it should come back .. and work correctly this time .. I hope. Of course, while I'm having this issue, both FF And Chrome have decided that I don't have secure access to my phpMyAdmin so won't let me work on it. Fortunately, MSIE still seems to work OK. Something to do with TLS versions .. I guess GoDaddy is falling behind .. and so must MSIE. Don't know how much longer MSIE is going to work.; Steve

Thanks for the reply, Jack. I have gotten it to work MANUALLY .. but only by COMMENTING OUT all that code about the secure_IP (in the index file). I executed the 'install' for the update and it would APPEAR that the proper stuff got written to the db, but the additional options aren't showing up in Admin and I get instant errors with the 'secure_ip' code in there. I still see the old options in Admin - just not the new ones (all about the IP options). Did I miss something in the install process? I got the followup page that gave me the DELETE or RESET options, but I didn't have enough info at the time to know which was appropriate, so I just went back to HOME. I see the code in the install file that updated the db, but nothing that I recognize as 'enabling' them in the Configuration by Admin. I did check from phpMyAdmin that the new ( I think there are 4) items ARE there in the db .. immediately following the original options (I think there are 5). Thoughts? At least I can get the files created again by running it manually now. :-). Steve

Jack, I have downloaded the latest version as in indicated in the LAST POST of the old thread ( ) but have run into another problem. In the latest version, you added code for SECURE_IP to keep "just anyone" from being able to run the script manually. if (! empty(GOOGLE_XML_SITEMAP_SECURE_IP)) { $safe_ips = explode(',', GOOGLE_XML_SITEMAP_SECURE_IP); if (! in_array($_SERVER['REMOTE_ADDR'], $safe_ips)) { header("location:http:127.0.0.1"); } } That new code throws a php error (that hebrew double colon error) since my site is on Godaddy and currently running php 5.4. I have commented out that section of code and can now get it to run manually while I continue to work at getting my site moved to the latest OSC version on a new server running php 7.2. However, it would be nice to have that 'protection' from anyone else executing the script until I get that completed. Is there any OTHER way to provide that secure_ip check using the old 5.4 php? Steve

I know this is a VERY old thread, but it worked on my site for many years .. and now it won't ? It actually worked perfectly for many years from cron.. then a couple years ago the cron started failing (due to register_variables issue), but it would run just fine from the browser window.. so I just kept doing it manually. Now, it also fails from the browser with a 127.0.0.1 call . which I think means it can't find the actual IP address where it used to be .. which is most likely because of the latest series of security changes made by all ISPs and everyone else too. I haven't found anything in this thread and I don't see any mentions in the original addon series.. but, of course. all of that is years old now .. Is anyone still 'listening here'? Is there a way around the problem? Is there a replacement feeder that works that I need to change to? The store is still running under MS2.2 .. yes.. a terribly OLD version of OSC, but I just haven't taken the time to upgrade and the store still works .. for the time being. Sorry for asking here, but I don't 'stay on top' of this store as well as I should since there is a relatively small number of products in a small store. But I would like to get the google feeder working again. TIA, Steve

Have already done that .. there are no changes and the size is identical. Just that the timestamp is changing. I've just deleted and recreated the ref file and noted the specific timestamp on the htaccess file according to FileZilla has not changed. I received 2 emails from Sitemonitor. The first one was when I clicked the FIRST ADMIN box to delete/recreate the ref file. It reported the usual NEW FILES/DELETED FILES referenced in my post on May 26 .. 4 or 5 above this one (as well as a change in the log file as expected) and found NO SIZE MISMATCH and NO PERMISSIONS MISMATCH, but it DID report a TIME MISMATCH on the htaccess file .. it reported "Last Changed on Tuesday, 12 Jun 2018 19:27:05 GMT". Interestingly that timestamp happens to be exactly x hours off of the currently showing timestamp via FileZilla of 3:27:05 PM both before and after I clicked the 1st Sitemonitor box. 3 minutes later I clicked the 2nd admin box and received another email - this time showing the usual NEW/DELETED files and ZERO MISMATCH reports. This SEEMS like a comparison problem of some sort .. but it is also true that the timestamp on htaccess HAS changed in the last few days.. with NO change in what's in it. I can't even write to it (although I can read it) or modify it in any way. It was created by my 1and1.com control panel and shows '0 0' as the owner with 644 permissions and I can't change them. I don't have any direct access. Perhaps this is an issue I need to bring up with 1and1? Could they possibly be 'pinging it' occasionally thusly changing the timestamp? I haven't been keeping my daily reports - I guess I need to retain a few of them to see exactly (if it is 'exact') how often the timestamp is changing.... Maybe I should take a few aspirin and maybe a tall cocktail and forget this is happening :-). Oh.. I just looked back in my emails and I have another report from yesterdays' chron run with a TIME MISMATCH on htaccess showing "Last Changed on Tuesday, 12 Jun 2018 00:14:45 GMT" .. I guess it was a few minutes into 'today' (the 12th) by GMT when it was still 'yesterday' here in GA. Steve

OK.. Sitemonitor seems to be working mostly, however I keep getting a 'date mismatch' on .htaccess in my admin directory. I can see no changes in the file, but the date/time *IS* changing. Maybe about every time Sitemonitor is supposed to delete and reconstruct the reference file. I have made NO CHANGES at all to the .htaccess file, yet the timestamp keeps changing. ? Steve

Along about p54 of this thread, there was a discussion about "some" characters that could be used in FILENAMES .. that would 'confuse' sitemonitor and therefore report invalid 'new' and 'deleted' responses from sitemonitor executions. I note that COMMA and AMPERSAND are at least 2 of them. 'Dot' and 'parenthesis' seems to be OK from my tests, but I wonder about other chars that cause issues. Jack.. do you have a list that should NOT be used in filenames .. but are 'legal' by other standards . either windows or unix? Reason.. although I am webmaster, I do NOT manage the day to day updates to the products and images that are uploaded. I have tried my best to promote 'good practice' to the people that DO that job, but they are somewhat 'computer illiterate' and things don't get updated every day .. so stuff gets 'in there' when transcribed from a sheet of paper into the store ... mostly for image names since they rarely (if ever) actually upload other types of files. It is somewhat weird to me, based on Jack's posts back then... sitemonitor reads the filenames CORRECTLY when it creates the reference file (i.e. includes the commas and ampersands) - the files are LISTED correctly, but is apparently TRUNCATING the filenames (in different ways) when doing the comparisons... a COMMA in a filename gets a 'New file' flag generated and and AMPERSAND in a filename says it was DELETED. Both show correctly in the reference file. Somehow the 2 sections of code - 1 looking for new files . and the other looking for DELETED files, seem to be going through different comparison routines. Could be related to file SIZES I suppose, but those are not listed in the reports and the reports show NO SIZE or TIME differences found. I also seem to have a problem of some sort in the sitemonitor_configure_setup.php vs sitemonitor_configure_0.txt file. The .txt file shows the $admin_username = '' (nothing), but whenever I bring up 'Configure' via admin panel, that item is filled in with my admin directory name .. and if I UPDATE without clearing that value, it THEN gets written into the .txt file. That should NOT happen.. should it? Why is configure pulling that directory 'out of the sky' and placing it on the config page when it's not needed unless curl is in use from what I've read? I can live with both of these issues, but thought I'd throw them out there. On the other side .. I do seem to have sitemonitor working on my (practice) site except for the 5 or 6 bogus reports that result from 'bad characters' used in filenames. It's WONDERFUL to have that peace of mind email every day! Thanks, Jack for this add-on. And, BTW, I'm using PHP7, so it does work with that too. Steve

Yes, that's extremely interesting. I downloaded that link yesterday just before my post above and UpdateDocs was NOT in the package. I also see that Jack updated it yesterday.. apparently some time after the above posts since I immediately downloaded it again after Jack said to read UpdateDocs.. NOW it's there. So, I get to read it. Hopefully, it will answer any other questions I might come up with. There must have been some 'grey time' between when Jack uploaded the change and when the server made it available at the public link. Steve

You know.. I'm really trying NOT to be a PAIN, but there is NO UPDATEDOCS directory that I can find .. not in the OSCV234BS directories, nor in the zip file associated with sitemonitor V3.3 or 3.4. WHERE is this directory supposed to be?? I AM *OLD* so maybe I'm just too THICK for this stuff? Steve

Sorry... I have NO IDEA what that is supposed to mean. There is NO FILE named 'update' in the latest version addon zip - nor is the word 'update' mentioned anywhere in any file in the zip that I could find. Additionally there is NO NEW INFORMATION in the readme.txt file other than the addition of the filenames.php file. The ONLY text that I see is THIS - Changed code in admin/sitemonitor_config_setup.php to remove a strict standards error. - Changed code in admin/sitemonitor_config_setup.php to close table properly. - Replaced defined filenames to work with the latest oscommerce version. As far as I can tell .. all is working now (but I haven't test chron yet) ....EXCEPT for the fact that I have not received ANY emails after running sitemonitor. I DO get a report and it's acceptable (I think). The hacker test also seems to be OK since I'm pretty sure I haven't been hacked on this new server ... yet. Steve

Thank you so much Arjan. That has at least gotten me to the next step. We'll see how long it lasts... :-) . Steve

I am setting up a new installation of OscV2.3.4BS on a new server (at 1and1 host) running php7.1 and would like to get sitemonitor working on it. I have downloaded and installed the latest version (V3.3) but cannot get it working after several days of trying. It SEEMS that something is missing from the download or the readme.txt instructions. I can see sitemonitor on my admin page and it has Configure and Admin within it .. however neither page will run. 'Configure' errors out trying to load template_top.php (on line 380) - the error says ' require(DIR_WS_INCLUDEStemplate_top.php): failed to open stream: No such file or directory. This is a fairly obvious error .. DIR_WS_INCLUDES is NOT defined. Well.. that constant is not defined in either of the configure.php files and it is not mentioned in the readme file for sitemonitor... so HOW can everyone else get this installed and working when I cannot? The store is working and the admin functions other than sitemonitor seem to work just fine, so I have to assume that DIR_WS_INCLUDES is not a part of the basic OSC V2.3.4BS package (I have double checked the zip file that it came from and even downloaded it again to be sure). I'm not sure whether sitemonitor is trying to open the 'main' template_top.php or the one that's in the admin directory. I tried adding a define for DIR_WS_INCLUDES in the admin configure.php file - and tried 'pointing' to one of the template files, then the other, but that just generates new errors, so I guess I must be missing something somewhere. DIR_WS_INCLUDES is definitely in the sitemonitor_configure_setup.php file and it's definitely NOT mentioned in the readme file, so it must be expecting it to be in the 'store' configure.php files. My original store is running a VERY OLD version of OSc - 2.2ms (which DOES use DIR_WS_INCLUDES) and I have been trying to migrate to the updated version. I could never get sitemonitor to work on the original store either so this was one of the main features I wanted to gain with the new version. Anyone have a guess .. anyone else using the newest 'responsive' version of Osc and have sitemonitor working on it? I'm not sure WHEN the BS version of Osc was generated, but it seems likely that it's been since 2016 - the date of the post just before this one. I've seen Jack's answer repeated over and over .. sitemonitor works with ALL versions of Osc... maybe not any more? I'm hoping someone still looks here occasionally :-). Steve