Cheepnis

So sorry. :(

Is there any reason why my problem is being ignored?

Solved it and added it as an optional addition to the mod in the contributions database. Works great!

You need a carriage return in this line: source = tep_db_fetch_array($source_query);$entry_referral = tep_get_sources_name($source['customers_info_source_id'], $cust_result['customers_id']); Between query); and $entry

Similar request as vixen800: I would like this to show up on the orders list and was able to insert all the fields properly in orders.php by inserting the appropriate lines from customers.php. It shows up just fine in the admin orders listing. However, none of the data is reported, that is to say, all the results show " --none-- " in the "Referred By" column. I'm sure it has to do with the search string variables $customers['customers_id'] that are requested here not being created as they are in customers.php, but I don't know how to modify this to collect the data: //rmh referral start $source_query = tep_db_query("select customers_info_source_id from " . TABLE_CUSTOMERS_INFO . " where customers_info_id = '" . $customers['customers_id'] . "'"); $source = tep_db_fetch_array($source_query); $entry_referral = tep_get_sources_name($source['customers_info_source_id'], $customers['customers_id']); //rmh referral end

What is the file usu_cache.db-journal and why does it show up in my \cache_system\sqlite folder? It has zero-length and zero permissions(!) but when it shows up, my store breaks with this error: Fatal error: Call to a member function fetch() on a non-object in /users/MYDOMAIN.com/htdocs/store/catalog/includes/modules/ultimate_seo_urls5/main/usu5.php on line 308 I wrote about this problem before and in the meantime discovered that this file is what breaks the store (I delete it and everything works again) but I still haven't heard from anybody here about what is the source of this problem. I really cannot allow it to keep happening as it breaks my store. Any help?

What is the file usu_cache.db-journal and why does it show up in my \cache_system\sqlite folder? It has zero-length and zero permissions(!) but when it shows up, my store breaks with this error: Fatal error: Call to a member function fetch() on a non-object in /users/MYDOMAIN.com/htdocs/store/catalog/includes/modules/ultimate_seo_urls5/main/usu5.php on line 308 I wrote about this problem before and in the meantime discovered that this file is what breaks the store (I delete it and everything works again) but I still haven't heard from anybody here about what is the source of this problem. I really cannot allow it to keep happening as it breaks my store. Any help?

There was a zero-length file in the sqlite directory with 000 permissions and "JOURNAL" in the name. When I deleted it, everything began working correctly! What is this file, how did it get there, and how can I prevent it from showing up again? VERY strange! Hoping it doesn't show up again....

I just received this error. I cannot access the USU5 Pro configuration page within admin (500 sever error), but I can access all other admin pages without a problem. The store side is broken and generates the error: Fatal error: Call to a member function fetch() on a non-object in /users/MYDOMAIN.com/htdocs/store/catalog/includes/modules/ultimate_seo_urls5/main/usu5.php on line 308 UPDATE: After doing a complete restore of the store and the database, I was able to access the USU5 Pro configuration screen again. I turned off the caching, then disabled USU5 Pro. The store worked again! I then enabled USU5 (leaving cache off) and the store worked - FOR A FEW MINUTES and then went back to the error I posted above. I went back to configuration and disabled USU5 and the store came back, but now the USU5 configuration page is not operable again. I just uploaded the USU5 distribution files again, in case one of them was corrupted, but that hasn't made a difference. I'm really at a quandary because this is a great mod and had been working flawlessly for several months (and was heavily indexed by Google, BTW) and now I have a LOT of external and internal links that are currently dead without the mod being active. It seems to have gone belly-up and I don't know how to fix it at this point. Please help! :o

After doing a complete restore of the store and the database (and waiting until the max connected users cleared, I was able to access the USU5 configuration screen again. I turned off the caching, then disabled USU5. The store worked again! I then enabled USU5 (leaving cache off) and the store worked - FOR A FEW MINUTES and then went back to the error I posted previously. I went back to configuration and disabled USU5 and the store came back, but now the USU5 configuration page is not operable again. I just uploaded the USU5 distribution files again, in case one of them was corrupted, but that hasn't made a difference. I'm really at a quandary because this is a great mod and had been working flawlessly for several months (and was heavily indexed by Google, BTW), but it seems to have gone belly-up and I don't know how to fix it at this point. Please help!

I just received this error. I cannot access the USU5 configuration page within admin (500 sever error), but I can access all other admin pages without a problem. The store side is broken and generates the error: Fatal error: Call to a member function fetch() on a non-object in /users/MYDOMAIN.com/htdocs/store/catalog/includes/modules/ultimate_seo_urls5/main/usu5.php on line 308 How do I get my store working again? If I have a "too many user connections error" with the database, would this create the error? My store is currently dead. Help!

Robert, any chance you would port this over to ZenCart? Somebody already ported Chemo's Ultimate SEO URLs, but I cannot bring myself to go near that beast. I really like your mods - they are all simple installs and bullet-proof. I manage another store in ZenCart but don't know how well this would work with it. It seems like it would be pretty straight forward - they have a page of port notes here: http://www.zen-cart.com/wiki/index.php/Developers_-_Porting_modules_from_osC Thanks for all your great work!

Should a completely ancillary function from a third-party website really be allowed to break the entire application when their server has a hiccup, however rare? The next version of this really should have a test for the presence of a working lookup site and should also allow the user to disable that function as part of it's settings (especially considering the speed improvements). I'm not a good enough programmer to make those changes, but I think it would be a welcome addition if anybody wants to do it.

BTW, not having the IP Lookup enabled REALLY speeds up Who's Online - a lot! I may never put it back (especially since the links should still work once the database is running again).

Make sure you add another end tag: } to the section, just before: //Add IP address geolocation to whos_online table

Ok, worked out the fix. To disable the IP Lookup feature (but not disable the link to the lookup) Comment out the following lines in admin/whos_online.php: Around line 106 add "//" to this line (as shown): // require('includes/classes/ipinfodb.class.php'); Around line 161, add: /* BEFORE this line: //Function to get IP address geolocation data from IPInfoDB and update whos_online table and around line 214, add: */ BEFORE this line: // Determines status and cart of visitor and displays appropriate icon. Around 372, add "//" to this line (as shown): // add_geolocation(); That's it! Hopefully it doesn't break anything else, but at least it gets Who's Online working again until ipinfodb.com is running again.

How can I easily disable the IP lookup feature and make Who's Online work again? I rarely use it anyway.

Tell me again where the configure file is? I also noticed that the featured link box in column right wants to show a link image, even if I have turned off link images in the configuration. It fails to show the image in any case and right-clicking on the image link shows that it wants to find it in the catalog directory! I don't know why all the directory paths for images would be so jumbled. I didn't change anything in this mod, all other aspects of the store work, and all other aspects of this mod work...

Ok, I figured it out. My stupid %$#^%# winzip doesn't unzip empty folders, so I never created the catalog/images/links_manager_uploads directory. Now that I created it, link images load correctly. Whee! However, working on the categories, it seems that uploading an image for a category will put it into the catalog/images folder, while when trying to display the category image, it looks for it in the catalog/images/links_manager_uploads/images (which doesn't exist by default, nor would it). It seems there may be a typo in the categories image calling line that looks in the wrong directory and the upload routine puts it in the wrong place anyway?

I followed the instructions - I guess I didn't mean "suppress". I used a VCC contribution in the store a long time ago for the stock submission pages. I don't know how to implement it on this mod. Wouldn't Google's recaptcha interfere? I'll have to look into it. Yes, forcing a link exchange prospect to join would be prohibitive. I didn't think of that. As for graphics, when I select a file for either link or category, it uploads fine, but when I look at it in the live store, all I see is a box where the image should be. When I edit either the category or the link, it says image does not exist.

Just installed this program in my 2.2 MS2 store and everything works great (well, I DID have to suppress the "Fatal error: Call to undefined function: tep_hide_session_id()..." message). Everything works great, except for images which I cannot seem to get to work at all, either for category or for link. Of course, I CAN disable that feature, but it's one of the nicest parts of this mod and one of the main reasons why I wanted to install it. I'm offering a free link exchange with whomever can provide the fix! :lol: Thanks in advance! Another thought: Would somebody like to offer a quick and dirty VVC update for the submit form? :thumbsup: Or an option to require a link submitter to have a store account? And why are the links in red text? ...and what about scarecrow's brain!?!

I figured it out - the only file that had changed was the .htaccess in the catalog directory. It was a zero length file for some reason. Just wiped clean! I'm not sure what could have caused that, but I'm not amused. I restored a backup file and the SEO Urls are back in their glorious working order! *WHEW*

Robert, I had something of a fright and I'm a bit concerned about how to resolve it. All of my products, reviews, and specials would return a 404 throughout the entire store (but were still visible on the admin side). When I disabled this mod, everything returned back to normal (with the stock URLs, of course), and now I cannot use this wonderful contribution and your URLS which Google already heavily indexed, by the way. Do you have any idea what might have suddenly caused this? I really don't think I did anything that should have affected this in such a manner! :o

No chance of it deleting new entries either then, eh? I hope this was just a one-time fluke. Any thoughts about what might have caused this to happen (besides my first thought of customer error)?

I recently had a customer concerned that his new shipping/billing addresses that he updated to a while ago have reverted back to the old addresses for some reason. He corrected them, placed his new order, then when the package didn't arrive in the mail, he looked and saw the addresses had again reverted back to the old. The only thing I can think of that might cause this behaviour (and I have performed no database restores) is this mod, as I have been running it somewhat regularly. Is it possible that there's a bug somewhere here with the customer data cleaning? Another reason why it might be good to have a more detailed description of what exactly this mod does. :)