the.rampage.rado

Hi there. I would like to start a discussion on the RMA part of thirty bees. How do you use it? Do you find it easy to use? Do your customers find it easy to navigate? What modules do you have that are using it? What would you improve in it? Do you use it only for warranties/claims/etc. or also for product exchanges, etc? What is your typical use case/flow? ------------ I'm currently not using it as I find it very limited and hard to use for me and for my customers. I handle all (very few) quality/warranty claims via email/phone and I want to start using the RMA for this. BUT, with the slow growth of my shops I started experiencing a rise in exchange requests for items that are the wrong size. The customer wishes to return the initially purchased item and receive a different size. For now, they have to call/email me to arrange this. I would like to centralize this flow in one place. Preferably with all other returns, different from the cool-off period returns (which are almost non-existent for me for now). I have the idea to use the current RMA for this. Here is what the LLM spit out as an idea, and I quite like it. I would like to see the RMA as a one-stop-shop for all warranty and exchange flows in the shop. In the future, we can even implement some connection to the Withdrawal module so we can truly have everything in one place. I would like for the customer to have the opportunity to file a claim in their profile, so we can handle every request in a specific flow. I would call this an evolution and a step forward for the RMA system that will truly make it useful for me (and hopefully others). Will you use something similar if you currently don't use the RMA as well, and what ideas do you have that you think will be useful in your work day? becomes structured data instead of something written into question. That distinction will make the system dramatically more useful later. Backwards compatibility I would not replace order_return or order_return_detail. Existing modules and themes potentially depend on them, and thirty bees itself reads returned quantities from order_return_detail. Instead: Existing / legacy ----------------- tb_order_return tb_order_return_detail tb_order_return_state tb_order_return_state_lang New --- tb_order_return_reason tb_order_return_reason_lang tb_order_return_resolution tb_order_return_history tb_order_return_attachment tb_order_return_shipment tb_order_return_reservation tb_order_return_order The old tables remain valid and continue to work. Existing code asking: $orderReturn->state still gets a valid state. Existing code reading: order_return_detail still sees the products/quantities involved. The new tables simply enrich the RMA. That is the safest BC architecture. How I would implement it Modernize the RMA concept without breaking the legacy API. Keep OrderReturn as the RMA header. Keep OrderReturn::addReturnDetail() and existing queries working. Add services such as OrderReturnService, OrderReturnResolutionService, OrderReturnStockService, OrderReturnNotificationService and OrderReturnEligibilityService. Controllers should progressively become thin orchestration layers. The current FO still uses the traditional order-return controller/template architecture, so we can modernize internally while retaining the existing URLs and theme contract. Introduce structured reason codes. Instead of relying on the free-text question, create configurable reasons such as too_small, too_large, wrong_product, damaged, defective, not_as_expected, withdrawal, and other. Reasons should be multilingual and optionally enable/disable specific resolutions. For example, too_small can allow exchange/refund, while defective could allow replacement/refund/repair. The legacy question remains and becomes the customer's optional comment. Introduce resolutions per returned line. A single RMA may contain two products with different outcomes. One might be refunded while another is exchanged. I would therefore not put resolution_type directly on order_return. Create something along the lines of: tb_order_return_resolution id_order_return_resolution id_order_return id_order_detail id_customization quantity reason_code resolution_type id_product_target id_product_attribute_target price_original price_target price_difference status date_add date_upd For a size exchange: original: Product 123 Combination 456 = Size M resolution: exchange target: Product 123 Combination 458 = Size L This also lets us support colour exchanges or even replacement with another product later. Create a proper RMA state machine. Keep order_return.state because of BC, but add meaning and history behind it. I would use operational states approximately like: Requested ↓ Awaiting approval ↓ Approved / Awaiting return ↓ In transit ↓ Received ↓ Inspection ↓ Approved for resolution ↓ Refund pending / Exchange pending ↓ Replacement shipped / Refunded ↓ Completed There should also be: Rejected Cancelled by customer Expired The important change is tb_order_return_history. Currently the RMA essentially has one current state; we should know who changed it, when, and why. For example: 22 Sep 10:14 Customer Requested exchange M → L 22 Sep 10:21 Employee #4 Approved 23 Sep 16:42 System Return shipment collected 25 Sep 09:10 Employee #3 Item received 25 Sep 09:12 Employee #3 Condition accepted 25 Sep 09:13 System Size L allocated 25 Sep 15:03 Employee #3 Replacement dispatched order_return.state simply remains the legacy projection of the current state. Make exchanges combination-aware. This is particularly important for your shops because sizes are combinations. When the customer selects Exchange, thirty bees should retrieve the combinations belonging to that product and show only valid alternatives. For example: Exchange for: ○ 39 ○ 40 ● 41 ○ 42 — unavailable ○ 43 There should be configuration controlling whether unavailable combinations are hidden or shown as unavailable. For a simple size exchange, don't let the customer arbitrarily search the catalogue. Start with: Same product → different combination Later we can add: Exchange for another product as a separate feature. Add stock reservation specifically for exchanges. This is one of the most important parts. Imagine the customer requests XL, returns L five days later, and XL sells out in between. We should therefore support an optional reservation: Requested exchange: M → XL XL available: 2 Reserve: 1 × XL I would make the policy configurable: Reserve replacement: ○ Never ○ When RMA is approved ○ Immediately when customer requests exchange My default would be reserve on RMA approval. The reservation should have an expiry and be released automatically if the return is cancelled/rejected/expires. Importantly, a reservation isn't the same thing as decrementing physical stock. Handle the inbound and outbound legs separately. A return/exchange actually has two possible shipments: Customer → shop and, for an exchange: Shop → customer So don't put one tracking number directly onto the RMA. Use: tb_order_return_shipment direction = inbound/outbound carrier tracking_number label/reference shipping_cost status date_shipped date_delivered This would eventually integrate very nicely with tbspeedy. For example your BO might show: RETURN Inbound Speedy Shipment: 123456789 Delivered 25 Sep Replacement Speedy Shipment: 987654321 Dispatched 25 Sep The exchange workflow I'd build The customer's Order Details page could become: ASICS Gel-Rocket Size: 42 Qty: 1 [ Return / exchange item ] Then: What would you like to do? ● Exchange ○ Return for refund ○ Report a problem Exchange: Why? ● Too small ○ Too large ○ Prefer another colour ○ Other Then: Choose replacement Size 40 Size 41 Size 42 ← purchased Size 43 Size 44 Size 45 Then a summary: YOU ARE RETURNING ASICS Gel-Rocket Size 42 × 1 YOU WILL RECEIVE ASICS Gel-Rocket Size 43 × 1 Price difference: €0.00 Customer clicks: Request exchange That creates the normal legacy RMA plus the new exchange information. Same-price versus different-price exchanges I would deliberately treat these differently. Same price This is the easy and common case: M → L €39.90 → €39.90 Difference: €0 No need to alter the original order. The RMA handles: return M + stock M -stock L ship L The original commercial order remains untouched. Replacement costs more Example: Original: €39.90 Replacement: €44.90 Customer owes: €5.00 Don't rewrite the old order. The RMA should create a linked payment/new-order operation: RMA #123 Original order #5000 Exchange difference: +€5 Related order/payment #5019 Replacement costs less Original: €44.90 Replacement: €39.90 Refund due: €5 Use the existing refund/credit-slip machinery where possible. This is much safer than altering historic order_detail records. Do not convert the original order into the new size This deserves emphasis. If somebody bought: Order #1000 Shoe / size 42 and exchanges for 43, do not change the original OrderDetail to size 43. Order #1000 must forever show what was actually purchased: Purchased: size 42 The RMA should show: Returned: size 42 Replacement: size 43 That preserves invoices, statistics, payment reconciliation, audit history and module assumptions. Back Office redesign Rather than the old mostly tabular Merchandise Returns screen, I'd turn it into an operational RMA workspace. Header: RMA #000184 ORDER #001284 CUSTOMER Created Age Current status Main section: RETURNED ITEM [image] hmlCORE XK POLY JERSEY Size: M Qty: 1 Reason: Too small Requested resolution: Exchange Replacement: hmlCORE XK POLY JERSEY Size: L Stock: 7 available 1 reserved Then actions: Approve Reject Mark received Inspect Accept item Reject item Prepare exchange Issue refund Create credit slip Generate return label Generate replacement label And below: TIMELINE with all history and communication. This would be much more useful for actual daily operations. Customer communication We should stop making every RMA state dependent on manually written emails. Introduce events/templates: rma_created rma_approved rma_rejected rma_waiting_return rma_received rma_exchange_reserved rma_exchange_unavailable rma_exchange_shipped rma_refunded rma_completed Modules could hook into these events. For example: Hook::exec('actionOrderReturnStatusChanged', ...); Hook::exec('actionOrderReturnCreated', ...); Hook::exec('actionOrderReturnReceived', ...); Hook::exec('actionOrderReturnResolutionCreated', ...); Hook::exec('actionOrderReturnExchangeShipped', ...); We should retain existing hooks/behaviour and add new hooks, never silently change the meaning of old ones. Eligibility should also become a service The current front controller exposes the configured return-day value to the template via PS_ORDER_RETURN_NB_DAYS. Longer term, eligibility shouldn't be scattered through controllers/templates. Something like: $result = $returnEligibilityService->check( $order, $orderDetail, $customer ); could return: ReturnEligibilityResult { eligible: true, refundAllowed: true, exchangeAllowed: true, deadline: ..., reasons: [...], } This gives us a future path for: Different return periods Category exclusions Customised products Clearance items B2B customers Defective-product claims Warranty workflow Different countries Different shops without adding more conditionals everywhere. RMA vs warranty I would also future-proof the naming internally. Not every after-sales case is really a merchandise return. Eventually: AfterSalesCase ├── Withdrawal / Return ├── Exchange ├── Warranty claim ├── Wrong shipment └── Damaged shipment But I would not rename OrderReturn now because that would cause unnecessary compatibility problems. Externally we can call the BO section: Returns & Exchanges while internally maintaining OrderReturn. Attachments Another worthwhile addition: Customer attachment Employee attachment Courier document Product-condition photo For damaged or defective, BO configuration could say: Require photograph: YES For: Too small Too large Changed mind no photo would be needed. Configuration I would add a dedicated: Orders → Returns & Exchanges → Settings with settings such as: Setting Example Returns enabled Yes Exchanges enabled Yes Return period 14 days Exchange reservation On approval Reservation lifetime 7 days Allow exchange to unavailable size No Allow exchange to another product No Customer pays return transport configurable Merchant pays replacement transport configurable Require approval before shipment Yes Photos required for damage Yes Multistore scope should work from the beginning. API / module architecture The services should be callable independently from the controllers: OrderReturnService OrderReturnEligibilityService OrderReturnReasonService OrderReturnResolutionService OrderReturnExchangeService OrderReturnReservationService OrderReturnInventoryService OrderReturnShipmentService OrderReturnRefundService OrderReturnNotificationService OrderReturnHistoryService That will make it much easier later to expose: Webservice/API mobile interface courier integration ERP integration warehouse integration without copying controller logic.

Personally never used it, too complex to configure as a merchant has to have deep knowledge of every module and what it displays to configure it. For me when all other caches are enabled + litespeed server the shop is fast enough. +1 to remove it.

Yes, the team said those features will be gradually added soon.

Unfortunately, only the bots are getting smarter.. 🙂 Yes, I put this check in as otherwise we will end up minifying twice. If you think that the library could replace the native implementation that is no longer supported, I would love for thirty bees to adopt the module. 🙂

Soon there will be an official release. As you can imagine - many new features, bug fixes, security patches, etc. It is STRONGLY recommended to update to 1.7!

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?

Did you try the module and the options it gives you? In general if you migrated from Warehouse you will see that Niara is far less configurable.

Could somebody that have already updated or tested the new implementation give me some guidance on how to use the new feature? The old implementation was quite intuitive. I can't understand how to implement the new approach. I have to select Packs with combinations, don't save and directly go to Combinations -> New combination and add my products, but then what? In the same time I have to add attributes, but how? Quite unintuitive. My use case is packs of products with combinations, only 1 product per combination, but with sizes. Like 5x or 10x balls packs. Later, I would like to use it to make packs of sporting kits (shirt and pants) - with 2 attributes - color and size. But how? I even tried asking the bot - it was unable to give me detailed description I can follow... 😞

You got a PM.

Be extra careful when removing image formats here as every theme creates what is needed during install. Regarding speeding up image generation - if you're generating your images during manual product creation the only way is to increase the speed of your server (buy better VPS/server). If you are annoyed that image creation times out/is slow during product import - simply don't create the thumbnails during the import but later in a dedicated tab while you do other work. The image section got nice rewrite by @wakabayashi but in the end it has to regenerate the files. Also - don't use jpg, it's 2026. Switch at least to webp, avif is even better if your server/php version supports it. BEFORE you switch the image format and regenerate all images - make sure that your theme can work with the new formats. Take inspiration from Niara and see how you can pass the file extension dynamically. Backup, make the change, then regenerate all thumbnails (Images -> Reset status -> Regenerate all). This will not speed up your generation time but will speed your FO performance and speed score if you approach the quality conservatively.

I basically told Codex to use this and that local repo of Warehouse, upgrade FA to 7.2, use the shims and not make any changes to the actual usage of the font in the theme so I can check if the shim layer works. After I saw that the new icons are loading with the old code calling them (FA3 and 4) I asked it to inspect all the theme files and module and swap the code for the new formatting. The old font files light stay for the initial testing and you will have to put the new FO files where they are expected to be (I beleive in 7.2 they must be in /webfonts folder under theme's /css folder). After that the bot will merge the big global.css file with all the glyph mappings in the FA source css (necessary if you don't want to have an additional call to another css), this adds around 11k lines of css. The only issue I think I had was in FO -> My profile section one of the icons was not rendering properly so I had to change it to similar one in the new package. In total, around 2 hours with all the testing