datakick

https://github.com/thirtybees/niara/blob/af439f01033dd0cd41622a2470813c29dc09453c/breadcrumb.tpl#L12 This is comment text in smarty template breadcrumb.tpl. You have probably modified this file and "uncommented" this, making it part of output

Thanks. This screenshot provides much more information that your first one. We now know the actual error message: Class 'Attribute' not found, and we know that it comes from override. The override is referencing Attribute class that does not exists anymore in thirty bees core, because it's reserved name in PHP8. You have probably installed some some module recently that added this override, or you have updated your store. Anyway, the fix is to edit the override file, and change Attribute::checkAttributeQty to ProductAttribute::checkAttributeQty There might be more usages of Attribute class, you have to replace them all.

The very first image, with error on line 121, is from override, isn't it?

Why not? The only "valid" reason I can see is PHP version. But that's not valid reason anyway, really. Just from security point of view, I would advise everyone to update to latest bleeding edge. https://github.com/thirtybees/thirtybees/blob/d9c85fa9ec25a186494daba2f3eec983ae75c553/classes/ConfigurationTest.php#L326-L348

sudo find . -type d -exec chmod 755 {} \; sudo find . -type f -exec chmod 644 {} \; This changes permissions of all directories and files to be readable and writeable by owner, and read-only to others. It will work properly as long as all files are owned by your php server user, as it needs write permissions.

Looks like a bug. Please create github issue with reprosteps

Do you have some email transport module installed? EDIT - you can use one of these two mail modules Mail via swiftmailer Mail via PHPmailer

Enabling debug mode will NOT help you decrypt your existing error txt files. When you enable it, and encounter some 500 error on your website, you will see error directly on the screen. There will be no prompt to download some error txt file and decrypt it. There can be many reasons why your back office don't want to decrypt your error txt files. One of the images in your previous posts shows that your server cant creating files in /tmp folder because of read only filesystem. The same probably happens when you try to upload the error file -- your php server can use /tmp dir to temporary store file during the upload.

Debug mode fixes the problem with The decrypt function in Logs is not decrypting the message. since there is nothing to decrypt.

enable debug mode

regarding get_magic_quotes_gpc - you can do full search / replace in all modules, and replace get_magic_quotes_gpc() with false Of course, you can then remove the surrounding code as well, since if (get_magic_quotes_gpc()) { $params = Tools::stripslashes($params); } will turn into if (false) { $params = Tools::stripslashes($params); } But it's not strictly necessary. The end result will be the same if you keep the unreachable code or if you remove it.

This is from order-confirmation.tpl template. In Niara / community-theme-default, the value of $id_order_formatted is rendered: <p>{l s='Your order ID is:'} <span class="bold">{$id_order_formatted}</span> . {l s='Your order ID has been sent via email.'}</p> This variable is set in OrderConfirmationController, and contains order internal ID left padded with zeros 'id_order_formatted' => sprintf('#%06d', $this->id_order),

This key is generated during installation, or when you switch from Blowfish to PHP Encryption. At least that's how it works on bleeding edge. Anyway, creating this manually works as well. Thirty bees does not add anything related to admin directory to .htaccess file. This might be your own manual addition, or entry by some module.

You can download this php script, upload it to your store root directory, and then open https://www.yourstore.com/genkeys.php genkeys.php Keys for rijndael should not be needed. Just ensure you are using Use the PHP Encryption library as you ciphering algorithm (in Advanced Parameters > Performance)

I don't have any issues even on php8.2

No, I won't implement this. Frankly, that's too much work, and I believe it can only cause trouble. For example, in my country invoice must contain customer's full address, so I need to collect it even for virtual products. That only leaves company information fields. And this one is important for business users. I guess I could implement such check. Is is something that is useful, though? I mean, if my customer has voucher for $100, and they want to use it on a product that costs $80, why should I block them to do that?

All information required for invoicing is collected, including address If you cart contains only virtual products, shipping is not displayed No, such option does not exists. It behave in the same way as default checkout -- allow free orders. I don't understand

Thanks for reporting this. Fixed in new version 0.9.3

In PHP8 Attribute is a reserved name. Every PHP codebase that used the same name must stop using it if they want to be compatible with PHP8. Thirtybees definitely want to run on PHP8, so we renamed this class to ProductAttribute. You will have to adjust your module and replace usage of Attribute class with this one. For example, if your module contains $attr = new Attribute(); $attributes = Attribute::getAttributes(); You have to change it to look like this $attr = new ProductAttribute(); $attributes = ProductAttribute::getAttributes(); There is also more easier solution - add this line at the beginning of every PHP file in the module (that is using this class). And you can keep the rest of the code intact use ProductAttribute as Attribute;

Yes, as long as it's a full backup. You shouldn't do merge into current root directory, but delete everything (or rename your root directory) and replace with your backup.

Oh, that's scary. Stage 1) remove the infection. use core updater and/or Configuration information to figure out if core files were modified. Use core updater to fix that look for any modules that you didn't installed check your overrides. You can use overridecheck module to list all existing overrides. check the theme for any modification. Take note of all modified or new files. Write down file creation/modification dates. Stage 2) strengthen your store update core to latest bleeding edge 1.5, if possible. There were a lot of security fixes rename your admin directory change all sensitive information in /config/settings.inc.php, including _DB_PASSWD_ - you will need to change password for your database user first _COOKIE_KEY_, _COOKIE_IV_ _PHP_ENCRYPTION_KEY_ _RIJNDAEL_KEY_, _RIJNDAEL_IV_ Delete all modules that you don't use. Even if they are not installed, they can pose security risk. Delete them. Stage 3) figure out attack vector updating your store to latest version and deleting unused modules may or may not fixed the vulnerability. If not, attacker can use it once again to get access to your store. You need to figure out how they got access look into your server Access logs It will help if you know the approximate time of attack (from file modification time) search for group of weird requests. Something like this nginx_1 | [29/Apr/2023:03:43:02 +0000] "GET /.git/HEAD HTTP/1.1" 403 153 "-" "curl/7.54.0" "-" nginx_1 | [29/Apr/2023:03:43:03 +0000] "GET /nmaplowercheck1682739782 HTTP/1.1" 302 5 "-" "curl/7.54.0" "-" nginx_1 | [29/Apr/2023:03:43:03 +0000] "GET /localstart.jhtml HTTP/1.1" 302 5 "-" "curl/7.54.0" "-" nginx_1 | [29/Apr/2023:03:43:03 +0000] "GET /CSS/Miniweb.css HTTP/1.1" 302 5 "-" "curl/7.54.0" "-" nginx_1 | [29/Apr/2023:03:43:03 +0000] "GET /5Mrh HTTP/1.1" 302 5 "-" "curl/7.54.0" "-" nginx_1 | [29/Apr/2023:03:43:03 +0000] "GET /Portal0000.htm HTTP/1.1" 302 5 "-" "curl/7.54.0" "-" nginx_1 | [29/Apr/2023:03:43:03 +0000] "GET / HTTP/1.1" 302 5 "-" "curl/7.54.0" "-" nginx_1 | [29/Apr/2023:03:43:03 +0000] "GET / HTTP/1.1" 302 5 "-" "curl/7.54.0" "-" nginx_1 | [29/Apr/2023:03:43:03 +0000] "GET /?=PHPE9568F36-D428-11d2-A769-00AA001ACF42 HTTP/1.1" 302 5 "-" "curl/7.54.0" "-" nginx_1 | [29/Apr/2023:03:43:03 +0000] "\x0E\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00bbbb0100000001" 400 157 "-" "-" "-" nginx_1 | [29/Apr/2023:03:43:03 +0000] "POST /sdk HTTP/1.1" 302 5 "-" "curl/7.54.0" "-" nginx_1 | [29/Apr/2023:03:43:03 +0000] "GET /Portal/Portal.mwsl HTTP/1.1" 302 5 "-" "curl/7.54.0" "-" nginx_1 | [29/Apr/2023:03:43:03 +0000] "GET /robots.txt HTTP/1.1" 200 36 "-" "curl/7.54.0" "-" nginx_1 | [29/Apr/2023:03:43:03 +0000] "GET /__Additional HTTP/1.1" 302 5 "-" "curl/7.54.0" "-" nginx_1 | [29/Apr/2023:03:43:03 +0000] "GET /HNAP1 HTTP/1.1" 302 5 "-" "curl/7.54.0" "-" nginx_1 | [29/Apr/2023:03:43:03 +0000] "GET /?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000 HTTP/1.1" 302 5 "-" "curl/7.54.0" "-" nginx_1 | [29/Apr/2023:03:43:03 +0000] "POST /scripts/WPnBr.dll HTTP/1.1" 302 5 "-" "curl/7.54.0" "-" within this group, search for requests that succeeded - response code 200. POST and PUT requests should be the first to investigate. check the php scripts for requests that succeeded check requests with response code 500. it can be indication of some vulnerability If you are unsure how to do all that, you can and should hire somebody to help you with all that.

While the idea behind this module is nice, I think it has a potential to cause a lot of trouble. And doesn't solve any actual problem, really. When you use this module, you should edit your templates and strip all microdata from them. Otherwise, search engines would see two sets of metadata. For product and organization info metadata this is ok, as json+ld format already contains this info. Problem occurs if you have some module that emits additional metadata (like reviews from revws module, author metadata, FAQ, related content, etc). Because of missing product metadata we just removed, these additional information will not be attributed to anything. And google search console will raise a lot of errors. In this case, the proper solution would be to integrate these third party modules with jsonmodule. Jsonmodule would expose some API that other modules could use to render json-ld metadata. This api does not exists. And even if it did, nobody will modify these third party modules to work with jsonmodule. So, if you don't use any module that emits metadata, you can use the jsonmodule. The end result will be, however, the same as if you just keep the html based markup

You should check files permissions. Maybe some of your files are not readable/writeable and were not updated delete file cache/class_index.php clear cache disable all overrides

Note: previous suggestion no longer works for bleeding edge / thirty bees 1.5. Employee record in database now contains 'signature' column that ensures employee password/email/role is not modified externally. This is to prevent attackers from accessing your back office in case of SQL injection vulnerability. If you are locked-out, you can use auto login script from this thread:

Here's a helper php script force-login.php Upload it to your admin directory, and then open it in your browser, ie https://your.domain.com/admin-dir/force-login.php This should log you in without need for password. Then go to core updater. In settings, enable Developer mode. Then click on Developer icon in upper right corner. In the developer tool, execute "Execute processes" That should complete the failed migration, and you should be able to log-in again. Don't forget to remove the force-login.php script again force-login.php PS: if you tried the suggestion from https://forum.thirtybees.com/topic/6081-locked-out/#comment-46072 thread, then don't forget that your password is already changed to changeme1234