Jump to content
thirty bees forum

Warning about updating to latest bleeding edge as of 2024-01-09


Recommended Posts

Posted

There is a vendor dependency psr/cache that some other modules may also rely on. Updating crashes the site if you have modules that also rely on it and that have their own versions. datakick is seeing whether he can remove the dependency from the core.

  • Like 3
Posted

This has been fixed. If anyone is interested what went on, here's s summary. 

Thirtybees contains vendor directory that have third party libraries that core depend on. We need smarty template engine to render templates, guzzle http client to send http requests to api server, tcpdf library to generate pdf, and others. These dependencies causes few problems

  1. some libraries have different implementaions for different PHP versions -- that's the reason why we have different PHP builds. We can do that as long as the library interface remains the same
  2. by having these libraries in the core vendor directory, they are autoloaded first. This can cause conflicts with modules

In this particular case, we updated library mobiledetect/mobiledetectlib to latest version 4.8.09. That versions depends on yet another library psr/cache version 3.0. Previous versions of this library did not have this dependency. After update, core vendor directory contained psr/cache version 3.

Unfortunately, a lot of modules (for example mollie) also uses this library, and have it in their respective vendor directory (modules/mollie/vendor). But because this library is already loaded by core, it will not be loaded from module vendor. If the module uses different version of library, than things can go bad very quickly. And that's what happened here - mollie requires psr/cache v1, but got psr/cache v3, and PHP raised exception.

The fix was for us to remove the original library  mobiledetect/mobiledetectlib from core -- it was replaced by library module tbdetectmobile. 

Now, this is not the complete fix, because there is still a compatibility problems between tbdetectmobile and mollie module -- both modules can't be installed at once. But at least it's not conflict between core and mollie module.

We have released the tbdetectmobile module in different versions, that you can choose from

  1.  very old version for PHP7.4  - https://github.com/thirtybees/tbdetectmobile/releases/tag/1.0.0
  2. version for php8 that does not have dependency on psr/cache https://github.com/thirtybees/tbdetectmobile/releases/tag/1.1.0
  3. version for php8 that have dependency on psr/cache - https://github.com/thirtybees/tbdetectmobile/releases/tag/1.2.0

If you have a module that depends on psr/cache v1, you can't use tbdetectmobile v1.2, but you can use tbdetectmobile v1.1

It's a mess, I know, but it's the best solution I could found.

In the future, we will release another version of tbdetectmobile that will change namespace of library dependencies, so it does not pollute global namespace. With that in place, the module will work correctly even if there is another module that have its own version of psr/cache library. Until that is done, you need to manually choose the correct version of the this module to use.

It would be great if all modules did that -- but we can't really force that on third party modules.

Side note:

the mobile detection is used by core for two things only:

  1. to display mobile theme variant. As far as I know, almost none of the themes support this -- there needs to be a /mobile/ directory inside your theme that contains overrides for themes. If this directory exists, then thirty bees will use templates from this directory when request comes from mobile device.
  2. to disable some modules on mobiles/tables:

image.png.df6749243d95e7dfad3bbbf9cef58726.png

Some third party modules might also depend on mobile detection. But, generally speaking, if you don't use these features, then you don't have a need for device detection, and you don't have to install the tbdetectmobile at all. Without this module, the response will be always identical for mobiles, tables, and desktop. With this module installed, the response can be different. 

  • Thanks 2
  • 3 weeks later...
Posted

THIS IS the very reason I have turned OFF and BLOCKED ALL automatic updates of any kind on ALL of my web assets - which include Prestashop, ThirtyBees, and Wordpress assets. Production sites cannot afford to have these kinds of chaotic and unexpected service disruptions happening, especially given the penalties from the search engines as they constantly have bots hitting your sites and will penalize your listings (covertly of course) the moment your site goes down and stays down beyond their unpublished golden limits.

That said, when you do turn off the automatic updates on ThirtyBees, it's a much more stable and better "engine" than what I know of out there.

I was not going to respond to this thread, but I feel like a conversation is desperately needed with software developers who are apparently impervious to the consequences of their considerable and constant "must upgrade" mentality. (Usually for "security" reasons although nothing in most of those new updates had anything to do with "security".) It's disruptive to business processes and operations, and if it truly is that unsecure that it constantly needs "security updates", it should NEVER have been released for anything other than testing purposes in the first place. Quality Control should have identified those bugs (security or otherwise) so that the Development Staff could resolve those DEFECTS - BEFORE any rollout happened! I do understand the issues facing open source development groups, but if you want to truly stand out from other projects and the commercial garbage being released these days, the answer, in my opinion, is to put more emphasis on the quality control facet of your project and have someone independent of the developers responsible for that process. Oh, and if that QC Manager says "NO" to a rollout - don't overrule them because you have some artificial (and they are ALL artificial) deadline to meet.

At some point, if the above is followed, people - mostly consumers of your product, will begin talking about how reliable and robust your solution is. That my friends is the gold standard that ALL technology companies should strive for - not to see who beats who with the next bugged-up release or patch.

Unfortunately, today you will have to use your own money to buy a cup of coffee with this opinion.

Posted

I was not going to respond to this thread, but 'what automatic updates on thirtybees'?! 😄 😄 😄 

Regarding the 'pseudo-security updates' - sooner or later you will have 'an outage beyond the unpublished golden limits' but it's up to you. Nobody can force you to update the shop.

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...