One-Page Checkout [Support Thread]

jpda:

Do you mean that defined_paths.php is ignored when reading local configure.php? Because in the local configure.php's DIR_FS_CATALOG has been defined correctly...

jpda
Nope, the defined_paths.php will supply the DIR_FS_LOGS definition by extending DIR_FS_CATALOG if that definition doesn't already exist ... which it did!

lat9:

Nope, the defined_paths.php will supply the DIR_FS_LOGS definition by extending DIR_FS_CATALOG if that definition doesn't already exist ... which it did!

Thanks again, I will check things again and report back because I think the DIR_FS_CATALOG existed and DIR_FS_LOGS was not explicitly defined in local configure.php. No log files were written at that point in time. They appeared again **after **I had explicitly defined DIR_FS_LOGS in the local configue.php :unsure:

Cheers,

jpda

jpda:

Thanks again, I will check things again and report back because I think the DIR_FS_CATALOG existed and DIR_FS_LOGS was not explicitly defined in local configure.php. No log files were written at that point in time. They appeared again **after **I had explicitly defined DIR_FS_LOGS in the local configue.php :unsure:

Have checked it again.
Removed both local directories and put both local configure.php files in their 'normal' directories (/includes/ and /admin/includes/, w/o explicit defines for logs. Thus forcing reading of these configure files.
Result: both debug logs were written.

Restored both local directories, put both **local **configure.php files in those local directories (/includes/local/ and /admin/includes/local/), w/o explicit defines for logs
And:
Restored both original configure.php files from the live site into their 'normal' directories (/includes/ and /admin/includes/).
Result: no log files!

Extra check: when I remove all configure.php files from /includes/ and /admin/includes/, leaving the local versions w/o explicit defines for logs, then debug logs will be written!

Conclusion? :unsure::unsure:

Cheers,

jpda

@jpda, since this issue doesn't have to do with One Page Checkout, I've created a new thread (https://www.zen-cart.com/showthread.php?223450-Logs-not-being-written-after-upgrade-to-1-5-5e-f&p=1340915#post1340915) in which to continue these discussions.

@lat9: Of course, you are right, should have done it myself, sorry.
Thank you so much for all your help with the issue!

Cheers,

jpda

Help with Uninstalling due to Ajax errors
Hi I ran the sql script to uninstall and set all the options in the module to false but get the following error in admin includes/templates/westminster_new/jscript/jscript_framework.php" is required for the plugin's proper operation.
If I put the script back the error goes but then the ajax errors come back.

Please could you advise how I remove it for now as when I tried deleting the files from the module I got a blank site and had to restore a backup.

Thanks in advance
Bob

merlin57:

Help with Uninstalling due to Ajax errors
Hi I ran the sql script to uninstall and set all the options in the module to false but get the following error in admin includes/templates/westminster_new/jscript/jscript_framework.php" is required for the plugin's proper operation.
If I put the script back the error goes but then the ajax errors come back.

Please could you advise how I remove it for now as when I tried deleting the files from the module I got a blank site and had to restore a backup.

Thanks in advance
Bob
You'll need to remove all the plugin's files, too. That error message comes from /YOUR_ADMIN/includes/init_includes/init_checkout_one.php.

lat9:

You'll need to remove all the plugin's files, too. That error message comes from /YOUR_ADMIN/includes/init_includes/init_checkout_one.php.

Thank you for your quick response.
Was hoping the uninstall sql would have done it.
Cheers

merlin57:

Thank you for your quick response.
Was hoping the uninstall sql would have done it.
Cheers
Nope, but an auto-uninstaller is on my list of enhancements to One Page Checkout!

Hello, I am using the one page checkout. It works correctly in language'dutch', but in language'french' it always returns with the message: 'Your order's details have changed. Please review the current values and re-submit.' . Can somebody help me with this?

@hbhorsesbe, I'll need for you to generate a One-Page Checkout log and send it to my personal email address (which I'll send you via PM).

Turn on the One-Page Checkout Debug via the admin configuration tools. Log in as a customer (and make sure that the language is changed to French). Place an item into the cart and navigate to the OPC's checkout_one page.

Choose a shipping and payment method and, if your store is set up to require one, 'tick' the conditions checkbox.

Using your FTP program, navigate to your store's /logs directory and delete the myDEBUG-checkout-one-xx.log file (where *xx *is the customers_id associated with the test checkout).

Now, click the "Submit Order" button ... once. The processing, in your case, returns back to the checkout_one page. At that point, copy that generated debug-log and email it to me.

Hello,

This is a great plugin and is exactly what I want.

I didn't start business yet and setting up my shop and want to install this plugin.
However I have not the layout I expected.
Followed the installation instruction and checked it twice but what the customer is seeing is not as in the example of the OPC plugin.
It is a one page checkout but all is placed in 1 collumn and need to scroll a lot to get at the end.

I'm using version 1.5.5f and have the Alto Premium Multipurpose Responsive Zencart Theme from Perfectus.
Maybe I did something wrong, forgot a setting or OPC is not compatible with my template.
Can someone help or advise?

Marcel

@Marcel, is this installation on a site where I could view it? If you're not ready to "go public" you could send me a Private Message (PM) with the site's link and a test-user email/password.

I've not heard of that template and from your picture, it looks like a CSS-related issue.

lat9:

@hbhorsesbe, I'll need for you to generate a One-Page Checkout log and send it to my personal email address (which I'll send you via PM).

Turn on the One-Page Checkout Debug via the admin configuration tools. Log in as a customer (and make sure that the language is changed to French). Place an item into the cart and navigate to the OPC's checkout_one page.

Choose a shipping and payment method and, if your store is set up to require one, 'tick' the conditions checkbox.

Using your FTP program, navigate to your store's /logs directory and delete the myDEBUG-checkout-one-xx.log file (where *xx *is the customers_id associated with the test checkout).

Now, click the "Submit Order" button ... once. The processing, in your case, returns back to the checkout_one page. At that point, copy that generated debug-log and email it to me.
Thanks for sending that! The issue is (and I'm certain that I've "solved" this before) that the initial entry to the confirmation page shows the order's total as €19.90, but after order-total processing that's changed to €19.90.

I should have that (re-)corrected later today.

@hbhorsesbe, I had another thought since you said that OPC's working fine in dutch, but not in french. Given the difference (identified above) that's causing the issue, what is the CHARSET value that is defined in your /includes/languages/dutch.php and in your /includes/languages/french.php?

@lat9, the charset is utf8_general_ci in both files and in my configuration file and also the same for my database.

@ Lat9, you have a PM

Marcel

hbhorsesbe:

@lat9, the charset is utf8_general_ci in both files and in my configuration file and also the same for my database.
I'm asking about the CHARSET definition in the language files. I'm guessing that the Dutch version is utf-8 while french is a type of iso-8559-??.

@hbhorsesbe's issue turned out to be the settings in the store's CHARSET (and DB_CHARSET) definitions. Once the CHARSET values (in all primary language files, both admin and storefront) were set to 'UTF-8' and each of the DB_CHARSET values (in both /admin/includes/configure.php and /includes/configure.php) were set to 'utf8', all's better.

lat9:

@hbhorsesbe's issue turned out to be the settings in the store's CHARSET (and DB_CHARSET) definitions. Once the CHARSET values (in all primary language files, both admin and storefront) were set to 'UTF-8' and each of the DB_CHARSET values (in both /admin/includes/configure.php and /includes/configure.php) were set to 'utf8', all's better.

Thanks for you great help.