keat

One of my recently updated carts has a number of UTF8 tables in the database. What are these, and are they safe to remove ?

Looking at the order history in the cart, I'm guessing that he's gone back and changed his order after pressing the continue button. Despite my cart stating in huge bold letters "YOUR ORDER HAS NOW BEEN CONFIRMED, PRESSING THE BACK BUTTON AND CHANGING YOUR ORDER WILL ....BLAH BLAH BLAH" Processing Yesterday, 11:32 Pending Yesterday, 11:31 Pending Yesterday, 11:30 Pending Yesterday, 11:20 Pending Yesterday, 11:11 Pending Yesterday, 11:11 I found his IP from the cart, then searching the raw access logs from the past few days, I only find 1 entry. [13/Feb/2017:11:01:11 +0000] "GET / HTTP/1.1" 301 26 "-" "Mozilla/5.0 (iPhone; CPU iPhone OS 10_2_1 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) GSA/22.1.146053689 Mobile/14D27 Safari/600.1.4" That's it, nothing more.

The odd thing is, global.inc.php shows me the name of the admin folder, which is correct. The name of admin.php however, is incorrect. Its easy enough to change, but has me wondering what purpose the entry in global.ini.inc plays if I can login using the original admin.php file.

Due to the amount of traffic the web site sees I fear that the logs will have probably already expired.

I'm trying to log in to the admin side of one of my carts, but it's just dropping me at the home page. I know I have the correct URL, as I confirmed this in global.inc.php. Amy ideas ? Edit: Interesting. I performed an update to 6.1.5 today, and although global.inc.php would indicate that the url has changed, I can still login using my original url, but not the new one.

I want to move the line between catalogue items just a little. Could anyone advise where I might find the setting to move this line down a few pixels. I found it in common.css

I now recall reading that somewhere, but never paid attention. Thanks

I've just run the upgrade from 6.1.4 to 6.1.5, modifying ini.inc.php to bypass the PHP 5.4 limitation, and get the following error. Fatal error: Using $this when not in object context in /home/xxxxxxx/public_html/classes/config.class.php on line 266

This issue reared it's ugly head again today. I never applied BSmithers fix (above) as he talks about the issue being caused by stock levels. We don't use stock levels, every item is marked as infinitum, so I can rule out anything to do with reducing stock levels.

Mine also says 'Loading'

Sorted

interesting. I'm running 5.3.29, but there's no mention of enable php_zip in PHP info. And no option in PHP config editor on the server. I'll dig a little deeper in the server configs. edit: Currently recompliling PHP

Typical. I tried again now I'm at home and it works. Maybe my work PC was caching something

I think we can close it.

I tried to install a plugin using the thunderbolt on my 6.0.10 site and this installed OK. I tried the same thunderbolt on the 6.1.4 site and it hung. Both sites are on the same server. Any thoughts.

[10-Feb-2017 15:38:59 UTC] PHP Fatal error: Class 'ZipArchive' not found in /home/xxxxx/public_html/admin/sources/plugins.index.inc.php on line 79 I performed an update to Cpanel on the server during the week. I'm guessing PHP isn't compiled correctly or something. or is this a requirement of 6.1.4 that wasn't required in 6.0.x

I did the code edit, but couldn't get it to default to "Please Select" Comparing the code beweeen 6.0.10 and 6.1.4, the section is a little different, so I assume it would be handling something differently.

error log is empty. does it require anything enabling ?

I could cheat this. Using PHP MyAdmin export product_options_group as a csv file Arrange the option_name column in alphabetical order, then over write the priority column with numbers ascending from 1. Make a backup copy of the product_options_group table. Truncate the table, and import your modified CSV file back in. You could do the same with options_value It's amateur and long winded, but if like me you don't know PHP, it works.

BSmither wrote a little tweak to force shipping to default to "Please Select". It seems that this no longer works in 6.1.4, and shipping defaults to the cheapest option again. Can anyone suggest a work around, or hook ?

I assume that you're using PayPal Express Checkout, and this is the reason you want to remove the Secure Checkout button. ? We had a situation where a customer ordered something for work, and used his work address as his delivery address, then paid using his personal paypal account. This over wrote what was in the cart (the guys work address) and replaced it with his home one. Subsequently, we sent the parcel to his home. We switched back to standard after that.

It seems so. Just seems to hang when I try using the hex code.

I've updated a 6.012 test site to 6.1.4 but i'm unable to install any plugins. If I try from the market place using the hex code, then the install plug page just hangs at http://www.testdomain.co.uk/admin.php?_g=plugins. Clicking refresh give me a Cross Site Forgery Message Might I add that i've used the work around for PHP 5.3

It's OK, I found it. I was working with BSmither on a snippet addition at the weekend, where we encountered similar issues. I had removed them from the cart side, but there were still PHP files in the folder: includes/extra I removed these and the 404 errors have stopped.

I updated a 6.0.12 test site this morning to 6.1.4, using the technique suggested by Al, however, I'm now getting 404 errors (category does not exist) when trying to browse categories. Debug shows these errors and the end of the debug [1] 1: Not unique table/alias: 'Array' [ERROR - CACHE WRITE] [2] 1: Not unique table/alias: 'Array' [ERROR - CACHE WRITE] [3] 1: Not unique table/alias: 'Array' [ERROR - CACHE READ] Any ideas ?