datakick

Really hard to tell where the issue is. It may not even be within thirtybees installation. This problem could also be caused by your customers using some browser with very strict privacy policy, or with some adblock extension that mistakingly considered tb cookie as a tracking one, and deleted it. Or maybe you have incorrectly set up nginx reverse proxy in front of your php server, with too small cookie buffer. When cookie is bigger than the buffer size, nginx might drop the cookie completely. And who knows what else can this cause. Only thing that we know for sure is that cookie does not contain customer information. Until you find the root cause and fix it, you can try this: edit file modules/paypal/controllers/front/expresscheckout.php and change it like this commit: https://github.com/thirtybees/paypal/commit/5578b7825301488872d758f7ecfdd770bb04e61c With that fix, the system will survive this particular place, and *hopefully* create an order. Although the order will be associated with a brand new customer account (with the same email address), so it's more of an workaround that a permanent solution.

The stacktrace suggests that, at the time customer is redirected back from paypal to your store, cookie no longer contains information about customer. And most likely cart (but we don't know that). This is very strange, because core definitely creates (or loads) customer record and set it to cookie before it redirects to paypal. Unless you have some third-party checkuot system / OPC etc, that may not do that? Or maybe you have some module installed that handle cookies/consent/gdpr and similar crap? Such module could delete the cookie if customer didn't give consent to track their info, effectively blocking the entire checkout flow.

Look into collectlogs module if you can find that 500 error message. Without knowing the details, nothing can be done.

So, the combination packs can be set up in 2 ways. The first one is described in the original post of this thread, using (Virtual Attribute) method. The other method is to set up packs per every combination individually. 1) Virtual Attribute method This is useful when your combination changes only combination of one of pack products, and the rest of the pack items remains same for all combinations. Example pack: Product A (size S/M/L/XL/XXL) Accessory 1 Accessory 2 You can create a pack on product level, using Product A (Virtual Attribute) option: When you save it, system will generate a new Attribute Group that is synchronized with combinations of Product A. For every combination, attribute value will exists: Now, you can create a combinations for a pack, using this new Attribute Group On front office, it will look like this: Your customers can select value of this new attribute group. When order is created, system will automatically select the proper combination for (Virtual Attribute) product in the pack, and save it so you know what was ordered: This approach is a lot of auto-magic, and not really customizable. It works nicely for simple packs where only a few products needs to be selected. However, it does not work that good when the product in question has a lot of combinations. Because all those combinations are merged into single Attribute Group. For example, if our Product A had both Size and Color, the UI on front office would not look that good: For that purpose, we created a full-fledged combination packs 2) Full fledged combination packs This method allows you to freely set pack content for every combination. Pack items can be very different between combinations. This method gives you much more freedom with defining packs, but it takes a lot more time, because you have to set your packs for every combination. Not on product level. Steps: Create your product, and generate as many combinations as you will need for it Change product type to Pack of existing products - combinations go to combination tab, edit every one of your combinations, and set your pack items. This time, you will need to select explicit combinations (Virtual Attribute is not available): On front office, you can use standard Attribute Groups to select combination, and combination in turn will populate pack items. This is much more powerful, explicit, and no magic involved. But more time consuming

System doesn't know your password. We only stores it's hash -- there's no way to determine your password from that. You can use 'I forgot my password' functionality on your back office login page to generate a new password.

That module is not php8 compatible. You should probably stop using it, or ask author for a new version, or hire somebody to fix it for you. In this particular case, the fix is very simple. Replace the if ($this->_cookie_path{0} != '/') $this->_cookie_path = '/'.$this->_cookie_path; with if ($this->_cookie_path[0] != '/') $this->_cookie_path = '/'.$this->_cookie_path; But who knows how many other issues that module contains.

If you can't remember your pwd, or if it's lost, you can either recover new password - you will need to fix your email issues first. But you should do that anyway create new admin user

The php script do not change your pwd. Use your original password, unless you broke it with manually changing stuff in the db.

A little bit unnecessary, since everything is protected behind admin pwd anyway. One of the reasons to do this is to protect against any potential vulnerabilities in admin PHP files -- attacker can't exploit them if they can't access that portion of website in the first place. But there are not that many php files in /admin directory, so...

that's why the recovery steps explicitly says:

Not really sure what are we talking here about. The fix for this problem was, previously, to change password directly in database. Which would, in fact, be a bit more complicated than it was written in the post above, because plain md5 would not work. The password would have to be salted with _COOKIE_KEY_ for this mechanism to work. You could, however, insert any password generated by php function password_hash. The new solution is to use a php script to log in into your server. To me, those two solutions are similar in complexity. For a lot people the new solution might even be easier, as it's just upload file using FTP. Changing data directly in database may be more scary.

As it should be. SQL injections are really bad, of course, as attacker can extract or change all informations in your store. But gaining access to PHP side is much more severe. Attacker can then do anything they want. Making it impossible for store owners to change email and password manually in database is a small price to pay.

The approach described by @DRMasterChief will not work on newer versions of thirty bees, intentionally. You can check if your tb_employee table contains column signature - if the column exists, you can't change the email/password in the table manually. You also need to change the value of column signature, but for that you need to know a secret that's not available to mysl. This mechanism exists to prevent attackers to elevate sql injections into complete access. If your store contained SQL-injection vulnerability (often caused by older third party modules), attacker could use it to change admin password, and then log in (basically the same mechanism described above). With the requirement to change signature as well, this no longer works. You can use force-login php script to log into your admin, see this post: You will have to: upload force-login.php file into your admin123xyz directory (every installation have different admin folder name) open url https://your.store/admin123xyz/force-login.php this will logs you in as an admin change password delete force-login.php script

Fixed in commit https://github.com/thirtybees/thirtybees/commit/7e9f2db06acd8323d4cefef0bb44654b87e6f0ca

This Attempt to update unsaved object warning message exists to alert developers to a code that do something they probably do not expect. In this case, FrontController is trying to update Cart object and set language/currency. But because the cart does not exists, that update is silently ignored - nothing is actually saved/updated into database. This is obviously strange situation that needs to be investigated and fixed. In this case, we should can simply add a check that cart exists before we try to do any of this stuff. In a lot of other cases, the fix may be much more complicated.