New features, improvements or something else?

[the.rampage.rado]

Hi there!

The summer is time to relax and unwind (at least here in Europe 😛 ). But it could also be a time fore new ideas. We know that you use TB as part of your business and this gives us hope that you like it.

We would like to know what you think of the project so far and ask you for ideas on how and what to implement so we (as a community) could make it better!

I tried to gather the most recent topics that floated in the forum, but if you have some nice, new and powerful idea please reach out and I'll edit the pool.

Don't forget about our marketplace where you can support developers involved in the project!

The core developer team also has set up a backer support platform where you can vow some small (or not so small) amount per month if you like to support the development of the platform! Developing and troubleshooting takes time and resources!

Best regards,
Rado

[30knees]

Before I vote, what would the warehousing module all do beyond what tb already does?

Regarding payment providers, I'd be happy for an official Mollie module (and will vote for it).

[the.rampage.rado]

31 minutes ago, 30knees said:

Before I vote, what would the warehousing module all do beyond what tb already does?

Regarding payment providers, I'd be happy for an official Mollie module (and will vote for it).

I believe that @Smile and @datakick could describe the module best and what could be achieved.

[datakick]

Regarding native mollie module - this is approved project. We also need this module. We investigated and decided to backport latest version of ps17 module to ps16 platform. Most of the functionality was written back in the days when ps16 was supported, so backporting those parts will be trivial. Some new functionality (like subscription/recurring payments) were unfortunately written for ps17 only. It will be possible to backport this as well, but with significantly more effort. So subscriptions may not be part of the first native version, we will see. Ultimately, we want to backport this functionality as well, as we have plans to use it for 'tb backers' ourselves.

Regarding warehousing module. In short, it is a set of tools to handle after-sale processes.

At its heart, there is a warehouse stock management system that is using double-entry accounting principles.

Everything is modelled as a stock movements between locations (location is something like account).

Locations can be physical or virtual. We have input locations (suppliers), output locations (customer sales, lost, wasted, etc), warehouse/regular locations, transient locations (picking and packing stations, etc).

Every location has set of capabilities -- for example, if one can use this location for picking, if the products on location are sellable, etc.

We don't track quantities of individual products on every location, we only track stock movements. Every movement belongs to some sort of 'warehouse operation document', for example picking, packing, stock intake, stock reservation, etc. Within this document, sum of quantities must equal to zero. For example, when picking products, we can take 3 items from Shelve1 and 2 items from Shelve2, and put 5 items into PickingBin1. sum(-3, -2, 5) == 0. This ensures that we can track where every product came from, and that nothing is lost.

At location level, we do not track quantities. Instead, current quantities of products at location is SUM of stock movements for this location.

This all allows us to answer a lot of interesting questions about our inventory:

• how many products we have for sale (sum of all sellable locations)
• how many products we actually have (sum of all locations - this can include returns, products in pick'n'pack process)

On top of this core, there are implemented few processes - product intake, order fulfilment. In the future product returns, etc.

For example, order fulfilment process:

1. available quantity for sale is automatically calculated from warehouse info -- store shows actual quantity available for sale.
2. order is placed by customer, and goes through the standard order validation process.
3. employee mark order as validated, and switch it to 'Ready for warehouse' status
4. module will try to automatically reserve stock on locations available for pickers.
   1. This can fail, for example if stock is at location that does not support picking (external warehouse, high location, etc) In that case, employee will create internal 'Stock movement order' to transfer  stock to location available for picking. Once all stock is ready at picking locations, it will be reserved. 
5. When all products are reserved, system can (automatically or manually) print 'picking order'. 
6. Pickers will take this employee, and will use our picking app inside barcode reader or phone
   1. they will scan order
   2. it will tell them location where to go, and what to take from there
   3. they will scan barcode at location, and barcode of product, enter quantity
7. one everything is picked, they will move the picked items to packing station
8. packer will take the list, and will use our other application to ensure everything is packed. It will print the shipping labels etc.
9. packages are handled over to carriers

Internally, there will be multiple documents. Reservation document will mark product at location as reserved. Picking document will move product from location to temporary picking bin. Packing document(s) will move products from picking bin to package location. Carrier document will move products inside packages to customer location. 

It's all very complex and complicated, but also quite powerful.

It's designed for bigger shops that have multiple employees and that want to streamline their warehouse processes.

• Pickers/Packers will not have to think, really, they will just do what they are told by the system.
• in office, you will have overview of what is where, what needs to be ordered/moved/etc

Hope this makes it more clear. I know it probably raised more questions than it answered,... it's really hard to explain. 

[led24ee]

I use combinations. Is there any way that You can show for customer HOW MANY OF EVERY item You have ? At the moment TB shows for all combinations that this is available, but in reality there is only one of of six available.

Also there may be delivery time notice for combinations.

Is there any way that Layered Navigation Block is able to use "slider option" for other things than hard coded price ?

[the.rampage.rado]

@led24ee very nice suggestions! I like them! Also I would find very useful a table display of all combinations in the product page - those that are not available to be greyed out and those that are available to be selectable.

Of course those changes would require theme adjustment.

[wakabayashi]

2 hours ago, led24ee said:

I use combinations. Is there any way that You can show for customer HOW MANY OF EVERY item You have ? At the moment TB shows for all combinations that this is available, but in reality there is only one of of six available.

Theoretically no problem. It's a question of the theme displaying the stuff...

[led24ee]

Good to know, but what will I do with this knowledge ? Until this theme or feature is not included in TB then there will be principle shit storm with every update.

There may be possibility to "bundle" products so that they will look like combinations. But this should be different from the possibility "bundle" that exist at the moment.

[the.rampage.rado]

Most themest use same code structure in this area, so code could be migrated between themes and with little css hackery things should be fine.

[elund]

Nice suggestions - especially speed and security 🙂 

What I would loose my mind over would be:

• a better (customizable) theme like the Panda theme
• a better (customizable) one page checkout.

[musicmaster]

My preferences are in keeping compatibility with Prestashop 1.6. Unfortunately Thirty Bees is disappointing me in that respect.

[led24ee]

Why only 1.6 ? Why not 1.4 ?

[the.rampage.rado]

15 hours ago, musicmaster said:

My preferences are in keeping compatibility with Prestashop 1.6. Unfortunately Thirty Bees is disappointing me in that respect.

Few things had to be change in order to allow php8 compatibility and move the project forward. Other than that each and every PS1.6 module I tried this year (I'm using always the edge TB version) has no problems.

Of course some 'edge' cases like powerful modules that manipulate stock or other aspects will be affected but I believe if those are so important you might pay additional funds to fix them for TB.

 

TB becomes better and better each day!

[musicmaster]

7 hours ago, the.rampage.rado said:

Few things had to be change in order to allow php8 compatibility and move the project forward. Other than that each and every PS1.6 module I tried this year (I'm using always the edge TB version) has no problems.

Of course some 'edge' cases like powerful modules that manipulate stock or other aspects will be affected but I believe if those are so important you might pay additional funds to fix them for TB.

 

TB becomes better and better each day!

Examples:

 - new modules that store their configuration data under the /img directory and completely erase their /module directory with each update

 - the "recommendation" to delete the extra columns that have been added by modules to system tables

 - upgrades impose their indexation on the database - and crash when some module had changed that indexation so that the old key was no longer unique

- as far as I know the bug that doesn't allow uppercase in module names still hasn't been solved

[datakick]

22 minutes ago, musicmaster said:

Examples:

 - new modules that store their configuration data under the /img directory and completely erase their /module directory with each update

I don't understand why this should bother you just now, as this was the case from the very start of thirty bees. This was the way tbupdater module extracted the modules  it downloaded from api server. Module directory was indeed deleted, and replaced with new dir. 

If you uploaded the module manually, this didn't happen -- content was merged.

In thirty bees 1.5, this is not an issue anymore, since we don't use tbupdater for updating modules from api server anymore. 

22 minutes ago, musicmaster said:

 - the "recommendation" to delete the extra columns that have been added by modules to system tables

How is that a compatibility issue? We simply display information about extra column. We don't delete the column from db. We also display that removing this column is 'Dangerous'. I would expect that nobody would click on it, unless they know what they are doing.

22 minutes ago, musicmaster said:

 - upgrades impose their indexation on the database - and crash when some module had changed that indexation so that the old key was no longer unique

This is similar to previous point. Some module decided to change database schema for core table, and didn't bother to inform core code about this change.

You are saying that core is breaking the module by enforcing database indexes it depends upon. I say that module is breaking core by changing database indexes.

The core code depends on unique indexes a lot. PHP code expects database to enforce these indexes. If some module changes the index structure, all these assumptions in core code stops working. Exceptions and 500 error pages follows.

22 minutes ago, musicmaster said:

- as far as I know the bug that doesn't allow uppercase in module names still hasn't been solved

Ahh, finally some compatibility issue.

Thankfully 99.5% of modules uses lowercase-only in their names, so this one is not critical. I agree it should be fixed, though. We do accept Pull Requests -- feel free to fix this bug if it causes trouble for you. Should be fairy easy. 

[wakabayashi]

5 hours ago, datakick said:

I agree it should be fixed, though.

Not worth the time 😅 Sorry, but if you are a module dev you have no reason to use uppercase. It's just not clever. Exactly as naming your module generic "paypal" is also not clever...

Luckily I read at the beginning of my coding "life" the book from Fabien Serny about prestashop (modules). He explained this very well... That's why all my modules have prefix "genzo_". 

@musicmaster Are these really the main issues you have with tb and ecommerce in general? I mean then you are the luckiest dev/merchant around here.

[musicmaster]

On 7/19/2023 at 9:24 PM, wakabayashi said:

Not worth the time 😅 Sorry, but if you are a module dev you have no reason to use uppercase. It's just not clever. Exactly as naming your module generic "paypal" is also not clever...

Luckily I read at the beginning of my coding "life" the book from Fabien Serny about prestashop (modules). He explained this very well... That's why all my modules have prefix "genzo_". 

@musicmaster Are these really the main issues you have with tb and ecommerce in general? I mean then you are the luckiest dev/merchant around here.

No, I am not a module dev. And your attitude is exactly the kind of attitude that makes me giving up on Thirty Bees.

You look at it from the point of view of a module developer. And from that point of view uppercase module names are irrelevant.

My point of view is that of someone who helps people migrate from older Prestashop versions towards TB. And it is exactly things like these that cause most of the trouble. It is not just uppercase module names. There are dozens of such minor incompatibilities. And often they take many hours to solve because I have no idea where to look. It is a death by a thousand cuts.

There are still many shops around using PS 1.6 or older. Thirty Bees could be an attractive option to them. But not as long as TB takes the position that everything that deviates from its strict interpretation of the PS 1.6 model can be ignored. People don't like to see their shop crash when they make the migration. They don't like it even less to be ridiculed by TB maintainers afterwards because their shop didn't adhere to some strict but arbitrary rules.

[wakabayashi]

30 minutes ago, musicmaster said:

No, I am not a module dev. And your attitude is exactly the kind of attitude that makes me giving up on Thirty Bees.

You look at it from the point of view of a module developer. And from that point of view uppercase module names are irrelevant.

My point of view is that of someone who helps people migrate from older Prestashop versions towards TB. And it is exactly things like these that cause most of the trouble. It is not just uppercase module names. There are dozens of such minor incompatibilities. And often they take many hours to solve because I have no idea where to look. It is a death by a thousand cuts.

There are still many shops around using PS 1.6 or older. Thirty Bees could be an attractive option to them. But not as long as TB takes the position that everything that deviates from its strict interpretation of the PS 1.6 model can be ignored. People don't like to see their shop crash when they make the migration. They don't like it even less to be ridiculed by TB maintainers afterwards because their shop didn't adhere to some strict but arbitrary rules.

If this was possible at PS 1.6, then there is some point in your request. I am not totally sure, if it was and if it was intended...

https://devdocs.prestashop-project.org/8/modules/concepts/module-class/#name

Quote

This attributes serves as an internal identifier (technical name). The value MUST be the same as the module’s folder and main class file. Only lower case letters and numbers are accepted.

But ok lets get productive. What is the problem in renaming them? I understand that this is no option for a merchant, but I am asking YOU as a DEV. Which modules are you actually talking about, cause in my years I have never seen one with capital letters...

[datakick]

39 minutes ago, musicmaster said:

No, I am not a module dev. And your attitude is exactly the kind of attitude that makes me giving up on Thirty Bees.

You look at it from the point of view of a module developer. And from that point of view uppercase module names are irrelevant.

My point of view is that of someone who helps people migrate from older Prestashop versions towards TB. And it is exactly things like these that cause most of the trouble. It is not just uppercase module names. There are dozens of such minor incompatibilities. And often they take many hours to solve because I have no idea where to look. It is a death by a thousand cuts.

There are still many shops around using PS 1.6 or older. Thirty Bees could be an attractive option to them. But not as long as TB takes the position that everything that deviates from its strict interpretation of the PS 1.6 model can be ignored. People don't like to see their shop crash when they make the migration. They don't like it even less to be ridiculed by TB maintainers afterwards because their shop didn't adhere to some strict but arbitrary rules.

I understand your frustration. However, it's simply not possible to maintain 100% backwards compatibility, and yet move this project forward. 

Some of the compatibility changes were forced upon us. For example

•  PHP8 reserved new Attribute class forced us to change core class name, without any way to provide BC polyfill
• A lot of libraries thirty bees core depended on, like minification, http requests lib, template, made their own changes and API modifications. Old versions of these libraries are not PHP8 compatible, so we had to adopt the new one. Again, this cause BC compatibility problems if some module uses them.

To maintain compatibility in these areas, we would have to abandon PHP8 completely. And we don't want that. Even for a price that some older modules stop working.

Then there are those minor incompatibilities you talk about.

• some of these are caused by new feature developments (new column in tables, new indexes, additional parameters to some methods). We try to implement these changes to be as BC as possible. For example, most of the new columns are nullable. Sometimes, it's not possible, though.
• changes in code structure - basically refactoring. We very rarely change signatures of public or protected methods, mainly to maintain BC with overrides. Sometimes we do this, but not very often.
• changes in semantics - again, we do this very rarely. For example, change return value of some method from 'array or null or false or zero' to return only array. These changes are sometimes forced to fix php8 issues caused by older modules. For example, some module can have code 

foreach (SomeClass::someMethod() as $row) {...}

if someMethod returns false/null,  this would throw an exception in php8. We might decide to fix this problem by making sure this method never returns null/false, and it always return array (maybe empty). But that can cause BC as well, if some module have strict comparison checks like this

if (SomeClass::someMethod() === false) {...}

So we now have to make a decision to prevent exception (500 error page), or potentially cause some minor compatibility issue. It's not an easy decision. And whatever we decide, somebody will blame us for doing it wrong.

• bug fixes -- yes, some modules depends on bugs in core. Some bugs were there for years, so module developers embraced and worked around them. When we finally fixed those bugs, modules stop working properly. Should we keep bugs in the core? I don't think so

So yes, there are some (maybe lots of) backwards compatibility issues. Still, it's orders of magnitude less than what ps17 forced upon their user base.

The only way to not have backwards compatibility issues is to stop development.

[musicmaster]

On 7/25/2023 at 11:35 AM, datakick said:

So yes, there are some (maybe lots of) backwards compatibility issues. Still, it's orders of magnitude less than what ps17 forced upon their user base.

The only way to not have backwards compatibility issues is to stop development.

The reason for forking Thirty Bees was discontent with the way Prestashop was going with 1.7. And its promise was a continuation of the 1.6.1 line.

Prestashop could get away with 1.7 because its huge market share guaranteed that module developers would provide all the necessary modules for the new version. Thirty Bees doesn't have that luxury. 

What I see now is that compatibility issues are treated as low priority. And in much of the new development maintaining compatibility seems low priority too. 

It gives me the impression that Thirty Bees is becoming a hobby project of a few people who are developing custom modules for their own or their customer's shops.

On 7/25/2023 at 11:32 AM, wakabayashi said:

If this was possible at PS 1.6, then there is some point in your request. I am not totally sure, if it was and if it was intended...

On 7/25/2023 at 11:32 AM, wakabayashi said:

But ok lets get productive. What is the problem in renaming them? I understand that this is no option for a merchant, but I am asking YOU as a DEV. Which modules are you actually talking about, cause in my years I have never seen one with capital letters...

Yes, it was possible in 1.6 and I encountered a module that did have a capital in its name. In TB you could install it but then it was invisible in the backoffice.

Whether it was intended is rather irrelevant. It is the PS 1.6.1 ecosystem as it exists that TB needs to maintain compatibility with.

Yes, you can work around many bugs once you know them. But often you will have wasted hours or even days to pinpoint them. And maybe the worst part is that it detracts your attention from the rest of the upgrade - what can lead to problems elsewhere.

In this case I ended up creating an override that disables the TB code that causes this problem. As this is not a module that I created I consider it rather tricky to rename it. Not to mention the complications that could arise when the shop owner might at some day upgrade the module.

[nickz]

10 hours ago, musicmaster said:

Prestashop could get away with 1.7 because its huge market share guaranteed that module developers would provide all the necessary modules for the new version. Thirty Bees doesn't have that luxury. 

And why is that?

IMHO it was the lack of standing out as an alternative to the all new prestashop 1.7 series which naturally caused, judging by the issues seen in the Prestashop support forum, IMO by a too hasty switch. 

I still believe that TB should push for more marketing. Even grassroot marketing should do the trick. Collect and write to all clients, Supporters, Forum members and push for their social media involvement. No money is needed, just give them, us,  an hour of support should they (we) need that.

As I see it Prestashop is using users as the test medium. Thirtybees should not fall into a similar pattern.
Contrary to the car sales ideology: not buying the newest model, in software (apps, Shops) people are fixed to the idea that the newest software is,  it to be the most secure.  Nothing is more secure than monitoring. Having a clone shop on a different server should serve as a backup, that at a cost of 100 US a year.

[vapedroidzs]

Prestashop could get away with 1.7 because its huge market share guaranteed that module developers would provide all the necessary modules for the new version. Thirty Bees doesn't have that luxury. 

[led24ee]

I tried PS 1.7 And yes this is very good platform ... for these who just want to pay for every "so called" module which in some miracle reason are already present in TB. But this was long long time ago, maybe now there are some changes. The most annoying part was with translation. I couldn't find possibility to export all existing translations and then after some modification import these to a new version. So for me this was extremely useless thing.

[Beeta]

I think that layered filter in search results could be very usefull for many shops.

Edited September 11, 2023 by Beeta

[terrytomyzs]

Is there any way that Layered Navigation Block is able to use "slider option" for other things than hard coded price ?