the.rampage.rado

Follow @datakick's recomendations: And please update your shop after you find and remove the hack! Can you DM me your domain? If it's already in maintenance, you'll have to add my ip, so I can check the source if I can help without FTP access.

You are hacked. Disable your store so customers can't pay to the hackers as you will have to fullfill the order. Give us more details about the installation: thirty bees version, installed 3rd party plugins, recent changes, logs, error logs, server access logs. You can search for the malicious module (if it's a module, as it sounds like some sort of injection) in the modules folder and deduce from the upload date roughly when you were hacked.

thirty bees integration test report Measured on 2026-08-24 against the local thirty bees 1.8.0 shop using PHP 8.3.30. The repository remained the canonical source. This report distinguishes measurements and observations from interpretation. CCC and lifecycle Measured: installing tbwikiminifier while official tbminifier was installed returned false, showed the explicit conflict error, created no hook rows, and left both module versions unchanged. The old module was never modified automatically. Measured: after clean old-module removal, the new module registered exactly actionMinifyCss and actionMinifyJs for shop 1. No actionMinifyHtml row, controller, table, or setting was introduced. Measured: direct Media::minifyCSS() and Media::packJS() probes recorded the new hooks in Hook::$executed_hooks; outputs matched Wikimedia Minify apart from the core JS semicolon trimming/join contract. Fifteen generated CCC bundles across the tested page set parsed successfully. Measured: disable and re-enable removed/restored the only active hook provider in separate PHP requests. CCC CSS/JS versions advanced together through 15, 16, 17, 18, 19, 20, and 21 during lifecycle tests. After the interleaved comparison, tbwikiminifier was restored as the sole active provider and tbminifier was uninstalled. Observation: thirty bees core calls the first CSS/JS hook response and does not chain providers, although all responding providers can run. The explicit old-module conflict prevents the known double-provider case. Asset corpus benchmark Every one of the 156 generated outputs (78 inputs multiplied by two engines) passed the applicable Acorn or CSSTree syntax validation. The actual-shop subset contains 33 JavaScript inputs totalling 1,178,692 bytes and 22 CSS inputs totalling 541,778 bytes. Actual-shop aggregate tbminifier tbwikiminifier New - old JS output 1,063,778 B 1,061,031 B -2,747 B JS gzip 288,557 B 287,785 B -772 B CSS output 424,402 B 429,813 B +5,411 B CSS gzip 86,794 B 87,173 B +379 B Summed per-input median time, JS 2,123.47 ms 896.55 ms -1,226.92 ms Summed per-input median time, CSS 135.19 ms 9.00 ms -126.19 ms The summed actual-corpus medians were 2,258.664 ms for the old engine and 905.548 ms for Wikimedia (2.49x old/new ratio). This is a minifier-operation comparison, not a front-office TTFB claim. Brotli is N/A because neither a Brotli executable nor PHP extension was available. The 2 MiB stress cases completed successfully: 2 MiB case Engine Output Gzip Median p95 Peak memory increase JavaScript tbminifier 1,825,339 B 5,380 B 4,318.185 ms 4,663.861 ms 3,653,824 B JavaScript tbwikiminifier 1,827,104 B 6,916 B 1,429.121 ms 1,741.703 ms 1,832,024 B CSS tbminifier 1,592,317 B 4,708 B 913.665 ms 949.068 ms 24,349,888 B CSS tbwikiminifier 1,708,828 B 5,054 B 47.876 ms 57.636 ms 8,163,352 B Real HTTP performance The initial sequential cold runs intentionally regenerated provider-specific CCC assets. They are valid cold observations but vulnerable to time-order/environment drift. Cold homepage metric tbminifier tbwikiminifier New - old TTFB 617.120 ms 321.106 ms -296.014 ms Total 622.828 ms 327.096 ms -295.732 ms Provider-specific home bundles from those runs were: Asset tbminifier raw / gzip tbwikiminifier raw / gzip New raw / gzip JavaScript 316,517 / 90,378 B 315,520 / 90,271 B -997 / -107 B CSS 364,698 / 68,888 B 369,260 / 69,096 B +4,562 / +208 B The stronger warm comparison randomized 40 blocks (20 per provider) with 10 requests per block and seed 20260824. Both modules were installed once before measurement. All 400 requests used the same page, database/shop, warmed CCC bundle state, cURL handle, cookie jar, web-server pool, and OPcache pool. Only the shop activation row changed between blocks; no lifecycle method, module install/uninstall, or CCC clear ran inside the loop. The harness cannot force Apache to select the identical worker process for every request. Interleaved warm metric tbminifier (n=200) tbwikiminifier (n=200) New - old TTFB median 107.681 ms 106.630 ms -1.051 ms TTFB mean 108.977 ms 107.283 ms -1.694 ms TTFB p95 123.013 ms 120.897 ms -2.116 ms Total median 113.785 ms 112.257 ms -1.528 ms Total p95 128.607 ms 127.207 ms -1.400 ms Measured: both engines returned HTTP 200 for all 200 samples; response size was constant within each engine (18,361 and 18,363 bytes respectively); no transport retry was needed. Measured: before/after CCC versions remained CSS 21 and JS 21, with the same five bundle paths, byte sizes, and SHA-256 hashes. Every transition snapshot contained exactly the requested single provider. Inference: warmed front-office overhead is effectively equivalent in this environment. The small 1-2 ms Wikimedia advantage should not be generalized as a guaranteed production improvement. Browser, network, and visual validation Measured: home, category, product, search, CMS, cart, and checkout pages completed under both engines. Candidate product option selection, quantity change, add-to-cart, carrier change, and payment-option selection worked; no order was submitted. Measured: all candidate CCC JavaScript/CSS responses loaded successfully and parsed. No browser or PHP error unique to tbwikiminifier appeared. Observed in both baselines: the theme's external lite-youtube.min.js is an ES module loaded as a classic script (Unexpected token 'export'), and the theme bundle calls missing $.debounce. The latter prevented the mobile menu and absent search UI in both runs. These pre-existing theme defects are outside the module and were not hidden. Measured visual stable regions: mobile home was pixel-identical; product was pixel-identical; category changed 0.0607% of stable-region pixels with mean RGB delta 0.0357. Desktop home used different effective responsive breakpoints and cart contents were intentionally changed, so those pairs are retained but marked incomparable. The candidate product full-page image has a browser fixed-header stitching artifact below y=720, which is excluded from the stable region. Security and dependency review Measured: composer audit --locked and the production-only composer audit --locked --no-dev reported no advisories. The complete development graph reports abandoned marcusschwarz/lesserphp; it is transitive development-only benchmark code and is absent from the release. Production dependencies are Wikimedia Minify 2.11.0 and pear/net_url2. Measured: the repository security scan found zero reportable findings. Production contains no public controller, upload, SQL, shell command, eval, deserialization, remote include, outbound request, telemetry, source logging, or source persistence. Observation: developer benchmark/capture utilities are CLI-only and excluded from the release ZIP. Limitations and evidence retention Wikimedia's deliberate parser trade-offs remain: CSS source-looking comments inside quoted strings and JavaScript multibyte line separators in certain comment contexts can change content. These have regression documentation and are correctness concerns, not remotely exploitable module attack paths. Invalid CSS that does not make Wikimedia throw cannot always trigger fallback; valid CCC inputs remain a prerequisite. All JSON, CSV, Markdown, and screenshot results under build/reports/ are retained. Raw non-customer test-shop capture inputs under ignored build/captured/ are also retained for reproducibility and are excluded from the release package. -------------------------- I would invite everybody to test this new module. Simply uninstall the bundled minifier module and install this one. Test for visual bugs. The cold combined js and css files should take 2x less time to generate. Which I think is a huge win for FTTB for customers coming from SERPs directly onto your product/category pages. 3 times less memory usage is a bonus. Yes, our total combined css+js package becomes 3 kb larger but I doubt this is an issue with modern 5G and optical networks if our page is around 1 mb in total. tbwikiminifier-1.0.0.zip

If you use Warehouse it's breadcrumbs.tpl emits schema. If you use the JSON module (which is complete; very few items are to be improved/added to it), you will have 2 fields for breadcrumbs. Which is not correct but is not problematic; I ran my shop until recently that way and only noticed and removed the schema from the tpl last month. The discovered rich snippets in Webmaster Tools started dropping and normalized to the correct level (from double the amount previously). I recommend using the JSON module as it offers other data for the whole shop too.

Claude/Codex will change few lines of code, not create entiran ely new module for you. But that way you will be able to update your shop, have many security patches, performance gains, etc.

Does it work with non ASM products too? Previously I expereinced an 'issue' with it where I had mixed catalog (ASM and non-ASM) products in the cart and it made split orders for thast cart. But how i works for non-ASM carts? I believe the products have to be set to use different carriers prior to creating the cart/order? But in this case the functionality @DRMasterChief proposed (option to change delivery method post-order) will not be available through the split-order?

What if you ask the customer post-order and they give you permission by email? I see no harm in that if you receive it.

My initial approach was flawed. I might revisit this later. Your idea is good. We should have this functionality in the core, not as a module, as this scenario is possible for every merchant.

Yes, I had similar issues with Warehouse theme and other modules. Codex and, before that, chatgpt fixed them and, I was able to migrate from php 7.4 to 8.3 in like 2 months. The 20 USD account per month is worth every penny for small merchants.

What is the issue with this module? If you're hacked, first you'll have to find the compromised files, clean/restore them, then look through access logs to find from where did they gained access. The only solution is to patch the hole, but since 1.4 there were numerous security flaws fixed.

The BO htaccess section is little buggy. Add this through FTP instead. You'll notice you've added it and it's there in the file but it does not always show in BO preview.

Please, update your shop to the latest version. If this does not solve the issue you should find some access logs, investigate if something is changed and gives access to somebody, etc. As a start - use code updater to compare against 1.4 official and check every file it finds that is different.

Hope this helps: https://github.com/thirtybees/thirtybees/pull/2132

It would be perfect, but it needs a lot of work.

Thank you for the detailed explanation, Petr! I did not see that the old behaviour is moved in the old pack. I will test it now. You said you fixed the pack not depleting the product quantity bug when configured, right? Regarding the second approach, I think I get it now - we select first the attributes in the said combination and then we configure the applicable products for the said combination. Adding them one by one. Then add second combination, and repeat. I will experiment with it. For now one bug I see with the old behaviour (normal pack and virtual attribute) is that it does not calculate the available quantity for the pack based on the product availability: Also, do we consider if the product is 0 (or has negative stock due to previous preorders) but is WOO: Allow orders - does the pack treat this as an orderable state for the pack also?