thirty bees 1.1.1 - pre-release bug hunt

[Briljander]

4 hours ago, wakabayashi said:

Devs won't upgrade their 1.6 modules at some point (I believe some devs already left or focus only on 1.7).

Yeah, this is already reality. As an example Warehouse theme is only focusing on 1.7 and I have more modules focusing on 1.7. The problem is that they don't even consider TB either cause it's too small project. Makes it very expensive to maintain them by own developers.

Edited March 4, 2020 by Briljander

[Acer]

16 hours ago, toplakd said:

You still have to understand, that thirty bees is open source free of charge software, no matter if based on prestashop or any other platform.

Fixes and improvements behind it are mostly not paid  if one could calculate all the hours spent.

Heck, even on paid solution shops (monthly or yearly subscription) many things sometimes are not working as they should, or there are bugs which are not fixed for extended amount of time.

So bitching over something that is free of charge is not a good thing.

If you look at PS. They said end of support for 1.6, please move to 1.7 and pay for some basic modules that were free in 1.6.

Even prestashop evolved during the years. I started with 1.3.8 and they moved on with versions as things had to be fixed until they said its time for something totally new and brought out 1.7.

Once you will sell for couple of millions per year  than you can have your own software team which will work on your own custom shop platform.

 

1.6 is now obsolete, and if new futures and bugfixes in TB will break some of the obsolete compatibility, then so be it.

You have to understand, that not many developers are willing to change/fix their 1.6 themes (which also include some bugs) to the latest fixes, as its easier to milk the money as long as it goes, as they are already selling new 1.7 version of their theme.

 

If one can not afford to spend 200-300 $/€ yearly for maintaining the shop, than its time to quit internet business and going to some daily job.

Thanks @toplakd for the great feedback and insight. 
My concern was that we've invested time and money into our TB stores, and required some reassurance that our critical modules (like the payment gateway, Panda and many other PS 1.6 modules) would not break in a year to 2 from now with future TB updates (like maybe TB drops majority of PS 1.6 support for example).

Essentially, I'm trying to gauge the health of the platform with it's current direction and updates - especially in relation to PS 1.6 compatibility.
We certainly do not want to re-platform to another platform any time soon.
And I definitely do not want to go to my CEO after all the time spent learning TB, developing, buying modules, building the site, and before launch telling him that maybe it was for nothing and TB wasn't the right choice...
It won't go down well.

Also if we had to re-platform... 
Unfortunately with the modules that we're using at the moment, the most natural platform would be PS 1.7 (!) - and that is something I'd like to avoid at all costs if possible.
PS 1.7 is just a crazy complete mess and would create major problems for us down the line anyway. From what I can see. And that's why we chose TB for our projects (we wanted 1.6 initially).

So no... If TB can maintain PS 1.6 compatibility as much as possible going forward, then it's still our first and best choice.
 

Edited March 5, 2020 by Theo

[Acer]

14 hours ago, Briljander said:

Yeah, this is already reality. As an example Warehouse theme is only focusing on 1.7 and I have more modules focusing on 1.7. The problem is that they don't even consider TB either cause it's too small project. Makes it very expensive to maintain them by own developers.

Hi. Yeah, but you don't need Warehouse 😀
Thankfully, one of the best and insanely feature rich and customisable PS themes, Panda, has been updated for TB and is actively maintained by the Theme developer @Jonny
Which is great and it gives you the "AAA" quality theme that you need for TB that is actively maintained and updated. 

Edited March 5, 2020 by Theo

[Briljander]

Yeah I know and I think thats great that Johnny are maintaining compatibility with TB. 

I do already have customizations of Warehouse which I do like and already spent a lot of time to get it the way I like. If I get forced to change theme I will but right now I have decided to stay with the version I have right now and hire developers to do fixes. Cost me a lot more but I don't have the time right now to change.

But this is not only Warehouse theme, I have more modules that only focuses on new releases for 1.7 and I do think they will increase in the future. That's my biggest concern.

[Acer]

20 minutes ago, Briljander said:

But this is not only Warehouse theme, I have more modules that only focuses on new releases for 1.7 and I do think they will increase in the future. That's my biggest concern.

Indeed, fair point. Same concern here. As long as TB has 1.6 support, and our 1.6 modules continue to work and we're happy with them as they are (no new features) - then we should be ok, imo.
For a while at least...

Lol, maybe TB should have a container or sandbox for PS 1.7 module support? (joke joke).
Or maybe better still, maybe TB should fork 1.7 and call it TB 1.7 (LOL)

= Either way, this way we can continue to have access to a large marketplace of modules 😂😀

 

Edited March 5, 2020 by Theo

[toplakd]

I'm not concerned.

I have no problems always running latest bleeding edge, as only thing that could break is my modified theme which is always fixable within short period of time.

People need to understand that once compatibility will start going separate ways, one can always stay on the latest working version that was 1.6 compatible.

[Briljander]

5 hours ago, toplakd said:

I'm not concerned.

I have no problems always running latest bleeding edge, as only thing that could break is my modified theme which is always fixable within short period of time.

People need to understand that once compatibility will start going separate ways, one can always stay on the latest working version that was 1.6 compatible.

There will always be a need of updating code cause of laws, new regulations, security holes bugs and so on. Once the module owners don't support TB or 1.6 you are on your own. It's still possible to update with own developers or if you have the knowledge, by yourself but this will be an expensive and time-consuming way of going forward. 

I still hope TB grow their fanbase to make module developers more willing to support it.

[toplakd]

I started 10 years ago with PS 1.3.8 something. During years versions have upgraded and new functions came in, old ones stopped working.

Modules and themes were sometimes not compatible anymore. And yet shops have survived, moved forward, upgraded to new versions.

People bought new modules, bought new themes. Some have migrated - myself included.

So at the end, world will still spin if at some point TB decides and goes further away from deprecated 1.6 PS.

[Acer]

13 hours ago, toplakd said:

I started 10 years ago with PS 1.3.8 something. During years versions have upgraded and new functions came in, old ones stopped working.

Modules and themes were sometimes not compatible anymore. And yet shops have survived, moved forward, upgraded to new versions.

People bought new modules, bought new themes. Some have migrated - myself included.

So at the end, world will still spin if at some point TB decides and goes further away from deprecated 1.6 PS.

Thanks @toplakd it's reassuring to hear this from someone who has played this game for a while with Presta and have gone through the evolutions a few times.
What's also nice to know is that you seem to be sticking with Presta-tech (for lack of a better term) and its continuation with Thirtybees.
I assume this is because it's the best option, if it's not, then can you please recommend others that you find as capable and feature rich? Like which tech would you switch to if TB was no longer an option?

Also... 

Although @toplakd 's comments have been reassuring, respected and appreciated, it's from a fellow merchant and dev. However...
What I would like to see is actual feedback from the TB team / senior dev or team lead - about PS 1.6 compatibility plans and plans in general for TB.
It's been oddly quiet from the guys -- there was a time until recently that they were involved with the community and communicated here and participated in discussions.
Has this changed?

Can you guys (the TB team and dev lead) please join the conversation and provide some feedback as well?

@Traumflug @lesley @Nemo @datakick

Edited March 6, 2020 by Theo

[toplakd]

I've tried Shopware, Gambio, XT-Commerce and few others, each for few days. Mainly from european developers.

Sure some of them they have some more or some less futures, but at the end of the day, for simple lightweight shop like mine, thirty bees beats them all in speed and simplicity.

Next thing in the row are the themes and how easy one can adjust them to own needs, simplicity of making or adjusting translations and list goes on and on.

Even if there is no Extra GDPR module for it, you can make it EU GDPR compliant with very few simple steps and use of "Block Customer Privacy" module.

 

And if at some point in future TB decides not to work anymore on the project, I will start searching and learning on for new lightweight platform.

My point of view is, if someone wants always be compatible with some outdated unsupported third party modules and themes which are bind to last 1.6 version, than one should stop upgrading it's shop to the latest stand.

Most Developers which support TB will provide their working modules/themes for the latest stable version, if you bought their update plan. If not, than one should use the version for which module/theme was made for.

One can not expect free lifetime support and upgrades for every shop version change.

And with fixing bugs and updating thirty bees, it will become less and less 1.6 compatible, especially with modules/themes that were not updated/fixed after PS discontinued their 1.6.

 

Dev team is fixing bugs and updating thirty bees, so joining this unneeded conversation if TB will still be compatible with 1.6 in 2029 would only take their time which they could use for maintaining tb, enjoying life or making 2 more kids.

[Acer]

7 minutes ago, toplakd said:

enjoying life or making 2 more kids.

2 more kids = no time for anything else 😁

Thanks for the feedback @toplakd

[Acer]

33 minutes ago, toplakd said:

I've tried Shopware, Gambio, XT-Commerce and few others, each for few days. Mainly from european developers.

Thinking of European developers, have you heard of Oxid CE?
At one stage back in the day when I was evaluating different e-commerce platforms, I seriously considered Oxid Community Edition.
It was simple, feature rich and blazing fast. At least back then and with my initial tests. Not sure how it stacks up today - but I see it's still around and alive and well.
Unfortunately there was no compatible payment gateway plugin for my country and we landed up going with Magento instead (lol and what fun! sad joke...)

Oxid CE
https://www.oxid-esales.com/en/why-oxid/
https://oxidforge.org/en/#top
https://demoshop.oxid-esales.com/community-edition/index.php?lang=1&
https://demoshop.oxid-esales.com/community-edition/admin/index.php?cl=login&redirected=1

Live site example: https://www.schiesser.com/

Years later I heard about PS and after lots of research decided on going with PS 1.6 - only to find when we were ready to pull the trigger that PS 1.7 was happening.
After reading some reviews and after some frustration, and out of desperation I decided to look for a PS 1.6 fork and voila: Thirtybees 😀

Edited March 6, 2020 by Theo

[datakick]

5 hours ago, Theo said:

Can you guys (the TB team and dev lead) please join the conversation and provide some feedback as well?

@Traumflug @lesley @Nemo @datakick

The idea behind tb project is still the same - to maintain compatibility, and have stable and bug free product. Feature development was never a big part of the mix. But that's ok, as tb core is already feature rich.

Of course, sometimes breaking compatibility changes have to happen. Smarty upgrade is an excellent example -- we had to upgrade smarty library to newer version, because old version was not compatible with php 7.2. 

 

[Acer]

20 minutes ago, datakick said:

The idea behind tb project is still the same - to maintain compatibility, and have stable and bug free product. Feature development was never a big part of the mix. But that's ok, as tb core is already feature rich.

Of course, sometimes breaking compatibility changes have to happen. Smarty upgrade is an excellent example -- we had to upgrade smarty library to newer version, because old version was not compatible with php 7.2. 

Thanks for the feedback @datakick It's reassuring, thank you.

Speaking of features: I may as well chance it here: any ideas or plans for "Multiple values for a feature" feature?
I see even PS 1.7 has that now...

Edited March 6, 2020 by Theo

[haylau]

1 hour ago, Theo said:

Speaking of features: I may as well chance it here: any ideas or plans for "Multiple values for a feature" feature?
I see even PS 1.7 has that now...

We use the Presta-addons module for that. Not free, but affordable.

https://www.presta-module.com/en/3-prestashop-addons/6-merchandising/8-multiple-features.html

[datakick]

1 hour ago, Theo said:

Thanks for the feedback @datakick It's reassuring, thank you.

Speaking of features: I may as well chance it here: any ideas or plans for "Multiple values for a feature" feature?
I see even PS 1.7 has that now...

This is exactly the kind of breaking change that we are trying to avoid 🙂

There are many modules (both native and third party) that would be broken with this change. Take elastic search module as an example. This module *expects* that only one feature value exists for every feature. How would this module behave if we allowed multiple feature values? Who knows. There are couple of possible outcomes.

• It could work out of sheer luck -- maybe the module is retrieving the data from the database, and process them, in a way that it would survive such change
• it could throw an error during product indexation
• or it could continue to index only one feature value (the worst scenario, if you ask me --- the module pretends it works correctly, yet search returns incorrect data)

Somebody would have to look into the code of this module and verify it works. We could do that for native modules (however it would take ages to go over all of them), but it's not realistic to expect third party module developers will do the same.

1 minute ago, haylau said:

We use the Presta-addons module for that. Not free, but affordable.

https://www.presta-module.com/en/3-prestashop-addons/6-merchandising/8-multiple-features.html

There is actually a free module out there that works OK on thirtybees -- link can be found somewhere on this forum. But that doesn't change anything. It's very dangerous to use such modules, if you ask me

[Acer]

On 3/6/2020 at 5:27 PM, datakick said:

This is exactly the kind of breaking change that we are trying to avoid 🙂

There are many modules (both native and third party) that would be broken with this change. Take elastic search module as an example. This module *expects* that only one feature value exists for every feature. How would this module behave if we allowed multiple feature values? Who knows. There are couple of possible outcomes.

• It could work out of sheer luck -- maybe the module is retrieving the data from the database, and process them, in a way that it would survive such change
• it could throw an error during product indexation
• or it could continue to index only one feature value (the worst scenario, if you ask me --- the module pretends it works correctly, yet search returns incorrect data)

Somebody would have to look into the code of this module and verify it works. We could do that for native modules (however it would take ages to go over all of them), but it's not realistic to expect third party module developers will do the same.

There is actually a free module out there that works OK on thirtybees -- link can be found somewhere on this forum. But that doesn't change anything. It's very dangerous to use such modules, if you ask me

Hi @datakick 
As you mentioned, there is a free module that works with Thirtybees - "Advanced Featured Values". I reached out to the developer last year and he is willing to donate this module to the TB Core.
However it's up to the TB team to allocate time / prioritise when and if they will be incorporating this module. 

Regarding your concerns + our findings using the Free Advanced Featured Values Module + popular Advanced Search 4 module or with Native Layered Navigation:

I understand your concerns that such a module could be "dangerous" especially in relation to Core and ThirdParty modules.
However, we required this feature and had to look for a module that gave us this functionality + we needed it to work with Advanced Search 4.
What's interesting is that our findings so far shows that it works 100% with TB Core and Advanced Search 4 + the native Layered Navigation. 
And that the "multiple values for a feature" values are being picked up and "seen" by the 3rd party module (AS4) and layered nav.

So for example, you can have a feature called "paper colour" with the values "red, green, blue, orange" and assign a test product to use "green and blue".
You can then create a filter in Advanced Search 4 or Layered Nav for the "paper colour" feature, it would then see all the values as separate individual values (like red, green, blue, orange).
And show these as a dropdown, input boxes or whatever.
Then, in the front-end, if you select either green or blue separately in the filter search, then our test product would come up as expected (it would not show for the other colours).

So this works for us and our business requirements. I know it's almost impossible to test against every thirdparty and core component, and I haven't tested this with Elastic search yet either.
As the code for this module is open source, perhaps you can check it out and see how it works?
Perhaps it could be "safe" enough to be incorporated into TB Core or it could provide valuable insights on how to possibly solve this problem with TB in a safe way - if you guys had to code a solution from scratch.
My point is that "multiple values for a feature" is a feature that imo should be part of TB natively.
Or at least you guys can use this module as an add on and update it if needs be for like PHP 7.4++ compatibility in the future.
 

For those that are interested in using the free "Advanced Features" module (multiple values for a feature), you can see this thread (contains installation steps plus minor fixes):
https://forum.thirtybees.com/topic/3456-multiplefeatures/?do=findComment&comment=30387

 

Edited March 9, 2020 by Theo

[Raymond]

Hello Everyone

I was curious to know at which point is the development of the new version, any news about?

Thank you

Best regards

[toplakd]

Bleeding edge 1.1.x is the newest version and it includes most recent bugfixes.

[Acer]

@datakick

New Bug with TB 1.1.x and Panda:
Got a strange new bug after I updated my 1.1.0 site with Panda to latest TB Bleeding edge:
On Product list / Category page: For some reason the Left Column disappears when a Sub Category is selected. Main Categories are fine.
I noticed that the var left_column_size is set to 0 instead of 3. Weird, as this worked before the update.

Because I know the Left Column should always show on the Category page, I've created the following to 'fix' it, albeit temporarily.
And obviously this isn't a real fix, as it doesn't address the cause. Just helps for now.

<!-- /// No Left Column on Subcategory Fix /// -->
{if $page_name == "category" && $left_column_size == 0}
	{assign var='left_column_size' value = 3}
{/if}
<!-- /// *** *** /// --->

Insert the code before: 

{if isset($left_column_size) && !empty($left_column_size)}

Thought I'd point this out. I have notified @Jonny as well. 

Edited June 4, 2020 by Theo

[wakabayashi]

On 12/1/2019 at 10:28 PM, led24ee said:

I noticed that with ASM there is another weird thing. This on is probably mistake. If You put products on supply order then the first row is reference. This should be product reference, but at the moment this is supply order reference.

Are you still using this? I have fixed this issue: https://github.com/thirtybees/thirtybees/pull/1406/files

If it works out for you as well, we could implement into the core! 😎

[led24ee]

Not currently used. I haven't even been able to upgrade to version 1.3

[wakabayashi]

On 4/3/2022 at 5:54 AM, led24ee said:

Not currently used. I haven't even been able to upgrade to version 1.3

Oh ok. As it turned out, the bug was anyway already fixed by the tb team ☺️ Hopefully you can upgrade soon. Im my case it worked nicely.