Feature Request Time!

[led24ee]

There is need to add captcha also to newsletter subscription.

[Wartin]

I have this little issue when you change the name of a product. If you just save and leave, the 'SEO search engines optimization' remains unchanged, leaving some broken links. It would be nice to have it regenerated automatically :)

 

[ariom]

11 hours ago, Wartin said:

I have this little issue when you change the name of a product. If you just save and leave, the 'SEO search engines optimization' remains unchanged, leaving some broken links. It would be nice to have it regenerated automatically 🙂

 

maybe i misunderstood your question, but in products preferences page there is already an option to achieve that

Edited February 12, 2021 by ariom

[Wartin]

7 hours ago, ariom said:

maybe i misunderstood your question, but in products preferences page there is already an option to achieve that

oh, didn't see that, thanks!

[ariom]

Just a little hint:
I would like to see an option, for products with different atttributes, each one with his own price increment, to better show the price difference instead of one price only ... in this way...:
Fron € 14,50 to € 17,90

 

[datakick]

8 hours ago, ariom said:

Just a little hint:
I would like to see an option, for products with different atttributes, each one with his own price increment, to better show the price difference instead of one price only ... in this way...:
Fron € 14,50 to € 17,90

 

This is not really a core feature, it's a theme functionality. It's up to theme designers to implement these kind of requests.

Of course, we could implement this in community theme.

[lesley]

I want to throw my 2 cents in the ring on this. 

 

What I would like to see as a new feature is likely something most merchants would not care about, but I think it would be instrumental in pushing thirty bees forward in the future and expanding the base with more developers and larger tier users. 

 

1. Push a change to how modules store data. I think this will get a lot of push back, but I think its needed for the end result. I think modules need to start adding columns to the default tables, with maybe more default tables needing the be added. Say you have a module that displays a custom section of text that is editable on a per product level. Like a module that hooks under the productextraleft that says "Free Shipping" on the front. I think that module needs to quit relying on its own table and store in the tb_product_languages table by adding a column. 

I think every possible module needs to start extending the default tables and storing data there when ever possible, 

2. I think the current webservice needs to be left as is, completely compatible with prestashop, but a new version 2 needs to be built out with a different end point. But instead of building it like the limited webservice that prestashop has, build a really extensible, resilient api. There are a ton of limitations with the current webservice, its only good for getting (some) data and storing data. 

What I am talking about is bringing everything online with the api. It needs the ability to build carts, query the api for shipping prices on those carts, get payment gateways, pass payments (which I do understand the modules have to be written to support this). 

Where the adding columns comes in, is in the resiliency of api. Where someone working with the api can just get product id -> language - > moduletext. The idea is when a module is added since its adding a column to the table, that new column becomes available in the api. 

Bringing an api like this online and making 100% of the core available through the api will expand the thirty bees universe more than anything. Look at PrestaShop, they are working towards a better more modern smarty integration, taking logic from their templates, ect. But in the end they are ending up with the same thing, just organized differently. Bringing the whole api online will make it possible for thirty bees to be headless, which will open doors of new technologies as the come out. Want to run a node front end? Sure, you can. Or React? Ok. Static html? Yeah, that would actually be possible. 

That (those) are the features I think need to be added.  

[Rhapsody]

@lesley - a very good post on potential architecture update.  I've been using WordPress extensively too and offer another suggestion.  WordPress has tables that may be used to store extra fields.  As an example for users (e.g. customers) there is a table wp_usermeta structured with the fields user_id, meta_key  - varchar (255), and meta_value - longtext.  When adding custom user fields, the data is stored in this table along with many core defined user fields.  When adding custom user fields there is no need to add columns to a table. WordPress has built in functions to retrieve and store data so it is properly escaped and safe .  There are similar tables for posts & pages (analogous to products).

An approach like this might have less impact on the existing core.  Functions could be added to extend the existing architecture.

[lesley]

@Rhapsody The main reason I am suggesting adding more tables is because the data is not going to be accessed internally. In wordpress you have their plugins grabbing the data and sorting through the json looking for what they need. What I am suggesting is for to make it all accessible through an updated web service. That way people do not have to run a theme at all, it can be a completely separate application accessing the data in the shop. This would standardize things. 

[datakick]

@lesley / @Rhapsody I very much agree with the idea of core being aware of all the data. How / where exactly are the data stored is not really important. It could be implemented in different ways -- extending core tables, dynamically create new tables to join, or as wordpress does it. 

The hard part will be force module developers to adopt this new mindset. However, if done correctly, it could very much simplify and reduce module development time. Core would take care of installing and dropping db tables and columns (both during initial installation and during module updates). All data would be readilly available to all other  components in the system, ie. in the theme or in the api.

This is definitely a good thing to have. And I'm happy to let you know that it's on our long-term vision. 

[AndyC]

While placing a order, I've just had another thought that I wish could be changed..

Can we do away with State drop down list and have the customer add their own State. I know we still need country but would be much nicer.. Or even having the auto fill address but I understand that would be rather difficult as this is a subscription module

[lesley]

@AndyC The reason that was never done and isn't done in any third party modules is because the data needs to be sanitized. Take paypal for instance, if you pass a payment with a state name, the payment will fail and the user will get an error. It has to be passed with an iso code of the state. That is how most gateways are. So having a typed state really does not work. 

[AndyC]

10 minutes ago, lesley said:

@AndyC The reason that was never done and isn't done in any third party modules is because the data needs to be sanitized. Take paypal for instance, if you pass a payment with a state name, the payment will fail and the user will get an error. It has to be passed with an iso code of the state. That is how most gateways are. So having a typed state really does not work. 

But when I use my processors website (not prestashop or TB) they don't have a drop down list and I use PayPal and other processors with no issue

[lesley]

@AndyC Not all processors require a state to be passed. With paypal, that is honestly the main reason that PrestaShop and ergo thirty bees ever included states. If you look at the list of the countries with states that comes with the default installation, those are the countries that paypal requires states from. This is the current list of countries that require a state to be passed, and the state / province code that they need. https://developer.paypal.com/docs/api/reference/state-codes/

[AndyC]

ok 🙂

[haylau]

5 minutes ago, lesley said:

@AndyC Not all processors require a state to be passed. With paypal, that is honestly the main reason that PrestaShop and ergo thirty bees ever included states. If you look at the list of the countries with states that comes with the default installation, those are the countries that paypal requires states from. This is the current list of countries that require a state to be passed, and the state / province code that they need. https://developer.paypal.com/docs/api/reference/state-codes/

We have disabled states and PayPal works just fine for us. So perhaps it is “if states are enabled then they have to be the correct coding@

[AndyC]

1 minute ago, haylau said:

We have disabled states and PayPal works just fine for us. So perhaps it is “if states are enabled then they have to be the correct coding@

I thought you had mentioned you had disabled them a while back, but wasn't sure 

[lesley]

I assume its because both of you are in the UK and the UK and EU do not have any countries with required states (except italy). 

I am not a fan of the big address format either to be honest, but paypal kind of ties your hands. For the autofills those are great, but generally not free. Algolia used to offer a free one, but they have twilighted it.  And I know a lot of people in the EU would be upset if the google one was offered as a standard component, they do not like sharing their information with google and clicking no in the gdpr box would break the checkout since they would not allow google to look up the address. 

 

[AndyC]

20 minutes ago, lesley said:

I assume its because both of you are in the UK and the UK and EU do not have any countries with required states (except italy).

Yes we both are

[led24ee]

There is need for custom or extra field for transport. I have offered possibility for transport "I'll specify later" but I can't enter price, because there isn't price. If I put "free" then I can't explain to customer that this free isn't actually free. Or maybe there is possibility that I haven't find yet ?

[SLiCK_303]

I'd love to see a couple modules added, or the functions of them built in..

Log in as Customer

and

Scroll to the Top

and

Spend x to get free shipping

Edited March 5, 2021 by SLiCK_303

[haylau]

1 hour ago, SLiCK_303 said:

I'd love to see a couple modules added, or the functions of them built in..

Log in as Customer

and

Scroll to the Top

and

Spend x to get free shipping

There are free modules available for log in as customer, even one from datakick himself

https://store.getdatakick.com/en/modules/login-as-customer

Scroll to top is often part of the theme (it is on Panda), but there is a free scroll to top here, from a great coder: 

https://mypresta.eu/modules/front-office-features/scroll-to-top.html

 

[SLiCK_303]

Thanks @haylau.  I've got, and use, those exact modules already though.  Just thought they were nice features that should be part of the core thats all.

[rubben1985]

I think including it as core features with a "contribution" mention in the module interface could be a good option if the developers agree.

[oliiix]

one thing that could be added: A way to ensure given emails in account creation are correct, or let's say an option in the backend that allows activating this feature 😉 At the moment I'm displaying two email fields with authentication(-create).tpl and validate.js that enable/disable the submit button when emails are matching/not matching.

An option of course would be my way to include two email fields. At least for the second no copy/paste/etc functionality should be active.

In case you consider sending out activation-link emails I hope you'd make that another option that could be set in back office as this could have a negative impact for us because users then bother us again just because they didn't get the account activation email.

I think both of upper options should be implemented and given to admins as an option to deactivate/activate. Would be great if it's possible to activate/deactivate both options independently.

I think you already solved the "bug" that passwords are sent via email, can't check right now but if passwords are still being sent via email, this should of course be fixed as well,, but I think you've done that already. I seem to remember a post about this on TB somewhere.

Edited March 15, 2021 by oliiix