datakick

This is nice bug. Calling __destruct on connection instance make this instance unusable, but does not remove it from connection pool. Sequence like this would fail: Db::getInstance(_PS_USE_SQL_SLAVE_)->__destruct(); Db::getInstance(_PS_USE_SQL_SLAVE_)->execute('select * from table'); Tracked in issue https://github.com/thirtybees/thirtybees/issues/1600

Probably override in your theme. Read here:

Again, there is NOTHING to fix here, from the thirty bees perspective. Thirty bees / ps16 always performed geolocation using maxmind database. Because maxmind stopped supporting database version 1, we had to fix it. When we were doing that, we though that it's a good thing to make this 'detect country' functionality pluggable, instead of depending on single implementation. So we extracted it to separate maxmind geolocation module. We support both this new module, and geolocation functionality in core core. If you use these two together, you will have the same functionality that always existed. This new pluggable architecture allowed ME (not thirty bees) to create another module that gets the geolocation information from cloudflare. This module is mine. I made it myself, in my free time. It is new functionality. It is not part of thirty bees native modules. From thirty bees perspective, this is just ordinary module by third party developer. You don't have any rights to go on this forum and demand changes to that module. It is absurd. It is like you creating a new issue in thirty bees project demanding changes to Panda theme.

You are mistaken. I have not marked this request as an enhancement. I have simply closed it as an invalid request. There is absolutely nothing to implement in thirty bees core here. Core does not know anything about individual geolocation modules, and therefore it can't check if those modules are correctly set up. That check should be responsibility of individual modules -- if not configured properly, module can simply not offer itself as an geolocation option. Your request is basically an enhancement request for my free CLOUDFLARE GEOIP module. Thirty bees core issue tracker is not the right place to submit enhancement requests for third party modules. That's the reason why I closed the issue. Nevertheless, I copied your request to my personal to-do list. This is module that I have implemented in my free time, and I offered for free on my website to the community. As a free module, it was released "as it is". I agree that your proposed enhancement make sense. But it has very low priority, especially since most users didn't have any problems settings things up. This is not a bug in the module, it works nicely if you setup cloudflare correctly (and have no intermediate proxy that might block these http headers). I have a big backlog of more pressing issues for my premium modules that have priority, and very little time to work on those. If this is really a pressing issue for you maybe you could try to fix it. After all, it's just "simple to do since its just data in a header."

Indeed, this was javascript bug. I've released new version 0.9.1 that fixes this one.

Both modules runs without problems even on PHP 8.2 As I wrote before - this looks like a theme issue. Your theme overrides template for these modules, and these overrides are causing issues.

Any changes to core files will be wiped out when you update your store using core updater. You have been warned 🙂

It's true that bleeding edge is not intended for production use. I personally use it on my production server, but that's because I know what I'm doing, and I'm fine with the risk 🙂 Bleeding edge changes quite often, and sometimes it contains some new bugs. This version should be deployed to testing environment, if you have any. If not, I strongly suggest you to create one -- so you can continuously test the upcoming release, and see if you are in need for any modifications. And provide feedback to us if you encounter any issue, so we have a chance to fix it before official release. For production, I recommend you use 1.4.x branch -- it can be found in 'Custom target'. This is bleeding edge for upcoming bugfix release 1.4.1. The diference between main (bleeding edge) and 1.4.x is that main contains bugfixes, new feature work, refactoring, code maintenance, etc. On the other hand, 1.4.x receives only well understood bug fixes. There are no new features or refactoring that could cause unnecessary troubles. One could argue that 1.4.x is more stable than stable release 🙂

What module is causing you trouble? Who is the module author? Did you report this issue, are developers aware of the problem? Are they still actively supporting/developing this module? If you are talking about this problem: then it's not a module issue, but theme one. You are using outdated community-theme version. You should update to new version. Core updater can help you with this, unless you modified the theme yourself. This particular problem was fixed by this commit back in September 2020: https://github.com/thirtybees/community-theme-default/commit/e8aaf3632640d8df85e6ca1074878d4b80d008a0

What module is causing you trouble? Who is the module author? Did you report this issue, are developers aware of the problem? Are they still actively supporting/developing this module?

Go to Core Updater settings page (either click on Configure from Module list, or open core updater and click on Settings in upper right corner), and in distribution channel choose Bleeding Edge.

Yes. Fix is in both bleeding edge, and 1.4.x (bleeding edge for upcoming 1.4.1 bufix release)

Instead of deleting/overwriting existing theme, I would recommend to create new file, for example: /admin/themes/default/css/schemes/admin-theme-dark.css You can then select and use this new theme in Employee settings page.

Yes, it's normal, unfortunately. While thirty bees core is PHP8 compatible, many third party modules are not. New major versions of PHP bring breaking changes, which means that PHP code have to be updated. Users are warned about these breaking changes in advance by PHP deprecation warnings (while you are still running on lower versions of PHP). Unfortunately, not so many people looks inside their server's error log. I recommend this flow: update your store to thirty bees 1.4 still use PHP 7.4 install collectlogs module use your store for few days/weeks continuously watch Advanced Parameters > Error Logs. You should fix every Error/Warning/Deprecation. You can ignore notices, for the time being. once you fixed all issues, and no new warning was found for a few days, you can switch to PHP 8.0 watch error logs for few days, if everything is ok, upgrade to PHP8.1 do NOT update to PHP8.2 yet, as it is not supported by tb 1.4. Support will be added in 1.5

Hi, xml backup file generated by module can be imported using datakick export/import module, as it supports reviews data. Alternatively, you can open this xml data in excel, and transform it to csv format. Or dump tb_revws* database table and import them using phpmysql tool. Note that in all scenarios you will have to make sure your product ids and author ids matches in both systems, or map them manually.

This is a bug in 1.4, already fixed in bleeding edge: https://github.com/thirtybees/thirtybees/commit/6a4f9d59a6af67b79546aca8d8af8aebf589ae81

Indeed, looks like a bug

I can implement this for the next version.

The module is not compatible with stripe api version 2022-08-01 or newer.

Works fine for me. Do you have any error message in your error logs?

First, you need to know exactly what hooks you want to trigger. There are a lot of them, actually. For product modification, these can be called (and that's only a subset of them) actionObjectAddBefore actionObjectProductAddBefore actionObjectAddAfter actionObjectProductAddAfter actionObjectUpdateBefore actionObjectProductUpdateBefore actionAdminUpdateAfter actionObjectProductUpdateAfter actionAdminProductControllerAddBefore actionAdminAddBefore actionAdminProductControllerUpdateBefore actionAdminUpdateBefore actionProductUpdate ... Once you know which hook(s) to trigger, you need to find the place in the core that is calling them, and figure out what parameters are send. Each hook sends different parameter. For example, hookObjectProductUpdateAfter https://github.com/thirtybees/thirtybees/blob/82b3102a421ce53347c4a660966048439e4f759b/classes/ObjectModel.php#L857-L858 Expects single parameter 'object' that is instance of Product class. You can trigger it as this one (for product 123): Hook::exec('hookObjectProductUpdateAfter', ['object' => new Product(123)]); Note that this can actually cause you more troubles. Modules can expect that the hooks are triggered in some sequence. For example, I have a module that create create audit logs of all changes. This module expects that first 'hookObjectProductUpdateBefore' is called -- at that point I retrieve data from database. Then when 'hookObjectProductUpdateAfter' is called, I once again retrieve data from db, and compare these two datasets to find out what has changed. If you just trigger hookObjectProductUpdateAfter, my module would be quite confused 🙂 And I'm sure there will be other modules that depends on things like these (sequence, context, controllers, GET / POST parameters, etc). So be aware

/config/settings.inc.php define('_COOKIE_KEY_', '********'); define('_COOKIE_IV_', '********'); Make sure your new server has the same values as the old server. This information was used to salt md5 passwords.

You should first look into source database ps_customer table and compare data with target db. SELECT id_customer, passwd FROM ps_customer ORDER BY id_customer LIMIT 10 Verify few customers. If the data are different, you can keep this conversation here, as it's a bug in the copy tool. If the data are the same, though, then the issue is somewhere else. You either didn't copied the _COOKIE_KEY_ and_COOKIE_IV_ settings from source to target server. Or maybe you used some sort of custom login functionality in your original server in the first place (maybe some auth module, or whatnot)

Of course you can. You just have to first update your thirty bees using coreupdater to PHP 7.4 build. There would be compile/syntax errors if you tried to run code that is using PHP8 syntax on PHP7. It's been discussed on this forum already. Try search.

This module is not PHP8 ready. https://github.com/thirtybees/nocaptcharecaptcha/issues/12