Jump to content
thirty bees forum

Recommended Posts

Posted
8 hours ago, elund said:

@datakick I am trying to test your module, but is getting this error:

image.png.fcb39edfde2d56d1aa4b04956d5c83ab.png

What should I look for to fix this error?

Thanks in advance,
Elund

That's weird error, I've never seen it before. Is this clean installation? Did you create some custom fields in module back office? 

Posted
9 hours ago, datakick said:

That's weird error, I've never seen it before. Is this clean installation? Did you create some custom fields in module back office? 

No, it's a backup of my production site. And I have not created any custom fields or even changed something regarding the fields.

  • 1 month later...
Posted (edited)

I have a few thoughts for whatever it's worth.  I am trying version 0.9.2 of Chex, and find the following, others have mentioned some of these things, so I'll be repeating some things.  Please ignore the non-stock theme and products....

1)  With the cart, as in this pic, it would be nice to have +/- on the quantity someplace.  I know you can hit edit and do it, but that's a little cumbersome for some people.

2)  A 'Cart' icon might be nice before the word Cart.

3)  It would be nice if one could click on the product and be taken to it's page. 

4) When a person has a coupon, and its set to be viewable, it would be nice if it showed up, maybe just after the last line, and before the enter coupon code/add coupon controls, or, maybe afterwards.....

1185108348_Screenshot2023-04-05192416.png.a327861e68bb444c58de5d6376c2a727.png

 

As my site only ships to the US, it would be nice if the country selectors, both at the top, and inline on the customers address, were not there at all.  Seems like more steps than one needs.  I'm not even sure whey the top country/state selectors are there to begin with, just to give a guest customer a shipping guesstimate?  Why bother as you cant really check out as a customer, guest or otherwise, without a full address.

Also, if the admin has it setup, it would be nice to see a message saying 'Spend another $x to get free shipping for your order!' someplace.

Being able to move the different 'blocks' around, like 'cart', or 'shipping and billing address', or 'confirmation', ect.  Being able to put them into 1 to maybe 3 columns, and then move the 'blocks' around....

 

Great job on the module, it looks like its got some real potential!!

 

Edited by SLiCK_303
  • Like 1
Posted

If you look back in the thread you'll find solutions for 'edit' button visible all the time and the country selection removal.


Another thing I was thinking was the options of products are not visible in the cart during checkout. It would be nice to have some truncated features/options there.

  • Like 1
  • 3 weeks later...
Posted
9 hours ago, the.rampage.rado said:

Despite of having them translated I don't receive the text in Bulgarian?

Indeed, that's a bug. Javascript method that translates string is in this case called before the translations are provided. I have to delay this, and translate string only when error happens.

  • 3 weeks later...
Posted

@datakick

In terms of this mainly minded on digital content

  1. Do the checkout support just "needed info" or will it request all full customer information (can we limit it to just get name + mail and/or phone) 
  2. Will we be able to hide the "shipping" part, as that is not needed
  3. In terms of free orders - is their a option to ensure that no orders are allowed if they are 0 or below? (So block free orders) 
  4. In terms of Payments, can we controle if we like to show images or just text on the payments or will that be 100% rolled by the payment methods ? 
Posted
2 minutes ago, Cassim said:

 

Do the checkout support just "needed info" or will it request all full customer information (can we limit it to just get name + mail and/or phone)

All information required for invoicing is collected, including address

2 minutes ago, Cassim said:

Will we be able to hide the "shipping" part, as that is not needed

If you cart contains only virtual products, shipping is not displayed

2 minutes ago, Cassim said:

In terms of free orders - is their a option to ensure that no orders are allowed if they are 0 or below? (So block free orders) 

No, such option does not exists. It behave in the same way as default checkout -- allow free orders.

2 minutes ago, Cassim said:

In terms of Payments, can we control if we like to show images or just text on the payments or will that be 100% rolled by the payment methods ? 

I don't understand

Posted
3 minutes ago, datakick said:

All information required for invoicing is collected, including address

Can this be added default.? So that you can set a default value using the module and then hide this fields.? We have hardcoded that into our current module, as we only are allowed to capture the information needed to deliver the order, and in terms of digital items, we don't need a adresse, to deliver the order.

 

4 minutes ago, datakick said:

No, such option does not exists. It behave in the same way as default checkout -- allow free orders.

Is that something you can add as a option in the backend.? To allow or disallow free orders.? 

Posted
1 minute ago, Cassim said:

Can this be added default.? So that you can set a default value using the module and then hide this fields.? We have hardcoded that into our current module, as we only are allowed to capture the information needed to deliver the order, and in terms of digital items, we don't need a adresse, to deliver the order.

No, I won't implement this. Frankly, that's too much work, and I believe it can only cause trouble. For example, in my country invoice must contain customer's full address, so I need to collect it even for virtual products. That only leaves company information fields. And this one is important for business users.

1 minute ago, Cassim said:

Is that something you can add as a option in the backend.? To allow or disallow free orders.? 

I guess I could implement such check.

Is is something that is useful, though?

I mean, if my customer has voucher for $100, and they want to use it on a product that costs $80, why should I block them to do that?

  • 6 months later...
Posted

Testing version 0.9.3 gives a different error than when I tested version 0.9.2 (see post from february 24 in this thread):

CleanShot2023-12-09at10_07.05@2x.thumb.png.ed4e05eeb06fc652876aa4e7138eeee3.png

Has anyone seen a similar error before? Or any ideas how to troubleshoot this?

I am still testing in a backup of my production site - so more or less the same environment as when testing version 0.9.2.

BR Elund

Posted (edited)

regardless the validation in the module that can be fixed to support null value, i suggest you update the carrier required field of delay (i think its called transit time) make sure you have it for all languages

Edited by yaniv14
  • Thanks 1
Posted
9 hours ago, yaniv14 said:

regardless the validation in the module that can be fixed to support null value, i suggest you update the carrier required field of delay (i think its called transit time) make sure you have it for all languages

Thanks a lot 🙂 

Could not find anything in the backend of ThirtyBees, so went into phpMyAdmin and deleted all records related to "La Poste - So Colissimo - Commerce de proximité". No clue why they exist, but probably from the old PrestaShop days.

BR Elund

Posted

Next problem - no payment methods available:

CleanShot2023-12-09at22_42.14@2x.thumb.png.576a8720cc253e51d111b610ba9253ed.png

Payment options works fine with standard or other checkout modules...

BR Elund

  • 2 weeks later...
Posted
8 hours ago, elund said:

After some researching I think I found an answer on my problem here:
https://www.prestashop.com/forums/topic/1000776-chex-one-page-checkout-module-for-ps16/

So looks like the payment modules (Quickpay and Reepay) - that I use - do not implement the displayPaymentEU hook 😞

BR Elund

Yes, that will be most likely the problem.

Most payment modules implement both approaches -- displayPayment and displayPaymentEU.

The first one is the older approach, and simply emits HTML code with all payment functionality into a page. And the expectation is that the page to be standard checkout page. This is very easy and convenient for developers, but it's very "hardcoded". It works on standard (or slightly modified) checkout page only. 

The displayPaymentEU approach is a declarative approach. Instead of emitting HTML, the module describe what is needed to do in order to process payment. And it's responsibility of checkout page to display the HTML and call the payment functions when needed. This makes it very easy to switch between checkout pages.

Seems like your modules implemented the old approach only

  • Like 1

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...