the.rampage.rado

There is a bug in thirty bees or the core updater that not every time the update runs define('_TB_BUILD_PHP_', '8.1'); in settings.inc.php is updated. It is not critical and you can manually edit this if you're sure the update propagated and your shop is running OK. This isssue was spotted a while back and @datakick advised that it can be fixed that way but nobody tracked down the issue so it's still present for some users in some scenarios.

Currently edge has no pressing bugs (in fact it has quite lot of work done since 1.6 in terms of bugs and small new features). If you have a test installation I would strongly recommend updating there to 1.7, see if it's working with php 8.3 (it should work but third party themes and modules might have a problem) and then update your production after you've made a working backup of it (files structure and db). I use edge on my production and I can't remember when was the last newly introduced but I noticed in my daily work. But thirty bees 1.6 would also work on php 8.3 (with few more deprecation warnings which should not be conserning) so if you only want to make your install work on php 8.3 I would recommend to play with only one variable - update your current store and make it working robustly on 8.3 and only then update it to edge if you see any reason.

Could you try and follow this procedure and tell us if it makes any change. At this very moment if you're updating to version 1.6, the same version should be in your BO. If you update to edge channel your BO should show 1.7 (which is currently not released as final version). When you switch between php versions you update only dependencies, the core is not updated.

The module in github from above is for thirty bees and it works flawlessly.

Not all stores use google accounts. 🙂 Turnstile is separate service from Cloudflare. There is no need for your store to be behind it to use Turnstile. Yes, account with them is needed but I advised for this module as it offers smoother flow for the real customers imho.

https://github.com/eschiendorfer/genzo_turnstile Do you have this module for turnstile in FO? If not, I highly recommend installing it and checking if the bots will stop.

As I said in the SQL manager, you are using there are forbidden statements or nested queries, etc. The export functionality in Customers is prepared query that does not run through thirty bees' SQL manager. As DRMasterChief said - if you have tool at hosting level similar to phpMyAdmin and you're confortable using it - do so but always keep a fresh copy of your db so not to end in a bad situation (only one deleted column in this table can brick your shop). You want a list containing those columns? SELECT c.id_customer, c.id_shop_group, c.id_lang, c.firstname, c.lastname, c.email, c.newsletter, c.date_add FROM ps_customer c; Of course edit the table prefix to match yours.

The SQL manager is heavily restricted in the operations it can do to limit exposure of the DB to bad actors. Give us the query you want to run so we can check for a better version.

Yes, the best one https://www.getdatakick.com/ Bonus - you can use it for far more than that.

https://www.getdatakick.com/ The best solution for any data feed for thirty bees.

Yes, I would start troubleshooting with your hosting first or the person that is maintaining your server. Because they have made some changes recently and we're here just guessing. In general if the thirty bees settings work - they work. Most of the issues are changes - of the merchants or hosting environments. It's not necesary an account/password issue - it might be some additional configuration of the mail server regarding transport/security.

Edited vulnerable information from your link. Did you use php8.2 before? Is it happening for every email sent out?

Sorry, now I remembered that if the generator tag is present core automatically changes it to thirty bees from one of it's classes. You found the solution - just remove it, that way core does not play with it. Regarding the top line look for Block Links module - it is reposnsible for adding links in the header top bar. The module Block Top Menu is the one with the drop down menus. Everything above it is header teritory.

<meta name="generator" is used to identify the CMS under the website (for noobs). You can safely remove the whole tag if you do not wish to advertise thirty bees. In your example it does nothing (brings no SEO).

Title comes from SEO URL settings - adjust your meta title for index. Generator tag is located in header.tpl of the theme you work with. Note that if you edit Niara's header file it will not be updated for Community. After that, go to Performance and clear your caches. Both mentions should be gone.

It's not a bug but the way the system works - it creates connections table record which then is used in quite many places to track connected events. Ask your module developer to simply add this discount voucher only for carts >0.00 and the module will work. Me personally - if I find out that you give such discounts and I want to be a regular at your shop I will always abuse this. Cron job is planned for this functionality with the development of the maintanance class but more pressing bugs/features are in the pipeline before this class is polished. You don't loos lots of performance if you have 1000 records with 0.00 carts. I put those buttons so a merchant can have quick and easy way to scrub this section once every few months, don't hang over those rows too much.

You can use any module for PS that supports cards or iDeal and have version for PS1.6 (some modules with versions for 1.7 only can be compatible or made to work with thirty bees but it's not 100% sure job).

Go for thirty bees. The community is small and the forum is not so active but this shows how little bugs are there so merchants do their business instead of hanging here.

Could you post more detailed repro steps as I'm unable to replicate this. I have 2 shops, If I have the same currencies in both - I'm unable to disable/enable them per shop. If I switch to Shop 2 context and disable a currency it gets disabled for shop 1 also. If I put a new currency in shop 2 only then I can disable it and it's not visible in shop 1 but then when I run the cron the disabled currencies stay at the same status. Also what currency update module do you use?

Sometimes it happens so 🙂 If you experience any other issues, please ask so we can try and help or if you think you've found a bug in the core or any native module you can directly create an issue report at github. Cheeers!

Can you describe more detailed repro steps for this bug? I'm unable to replicate it for now. EDIT: Never mind, I replicated it. We should move the category on the same level and we should not have a category with the same position in the new place. Can you try this if it's working for you so I can make a PR? Category::update public function update($nullValues = false) { if ($this->id_parent == $this->id) { throw new PrestaShopException('a category cannot be its own parent'); } if (PageCache::isEnabled()) { PageCache::invalidateEntity('category', $this->id); } // Read current persisted parent (and level) before we write anything $row = Db::readOnly()->getRow( (new DbQuery()) ->select('`id_parent`, `level_depth`') ->from('category') ->where('`id_category` = ' . (int) $this->id) ); $oldParentId = $row ? (int) $row['id_parent'] : 0; $oldLevelDepth = $row ? (int) $row['level_depth'] : null; if ($this->is_root_category && $this->id_parent != (int) Configuration::get('PS_ROOT_CATEGORY')) { $this->is_root_category = 0; } // Update group selection, if provided if (is_array($this->groupBox)) { $this->updateGroup($this->groupBox); } // Compute target depth from the new parent $calculatedLevelDepth = $this->calcLevelDepth(); // throws if parent invalid $parentChanged = ($oldParentId !== (int) $this->id_parent); $levelChanged = ($oldLevelDepth === null) ? true : ($oldLevelDepth !== (int) $calculatedLevelDepth); $this->level_depth = $calculatedLevelDepth; // If parent changed we must reseat position; otherwise do it only if duplicate exists $needReposition = $parentChanged || (bool) $this->getDuplicatePosition(); // === Multistore-safe shop list to touch === $shopIdsToTouch = []; if ($needReposition) { if (Tools::isSubmit('checkBoxShopAsso_category')) { // Admin form posted: only the explicitly associated shops $assoc = Tools::getArrayValue('checkBoxShopAsso_category'); $shopIdsToTouch = array_map('intval', array_keys((array) $assoc)); } elseif (Shop::getContext() == Shop::CONTEXT_SHOP) { // Single shop context $shopIdsToTouch = [ (int) Context::getContext()->shop->id ]; } else { // Fallback: only shops already associated with the category $rows = static::getShopsByCategory((int) $this->id); foreach ($rows as $r) { $shopIdsToTouch[] = (int) $r['id_shop']; } if (!$shopIdsToTouch) { // If somehow none, at least touch default shop to keep data consistent $shopIdsToTouch = [ (int) Configuration::get('PS_SHOP_DEFAULT') ]; } } // Reseat position per associated shop foreach ($shopIdsToTouch as $idShop) { $this->addPosition((int) static::getLastPosition((int) $this->id_parent, (int) $idShop), (int) $idShop); } } $ret = parent::update($nullValues); if ($ret) { // Clean positions in both branches when moved; always clean in the new parent when we reseated if ($needReposition) { static::cleanPositions((int) $this->id_parent); if ($parentChanged && $oldParentId) { static::cleanPositions((int) $oldParentId); } } // Any parent change or depth change requires a full ntree rebuild if ((!isset($this->doNotRegenerateNTree) || !$this->doNotRegenerateNTree) && ($parentChanged || $levelChanged || $needReposition)) { static::regenerateEntireNtree(); $this->recalculateLevelDepth($this->id); // fix depths of descendants } Hook::triggerEvent('actionCategoryUpdate', ['category' => $this]); } return $ret; }

You know our module is completely different from theirs, right? The version we have is long archived and not used in PS.

Looks great!

Regarding the modules - I mean that I think there could be modules that change the shipping status via API. Regarding the statistics - I'm sure there is none. 🙂 Those KPIs are internal parameters and every large organization is tracking them. I'm working on a module that could track such data and I'm thinking if we can modify the delivery date-time when we set the Delivered status.

Hi there, I'm curious if any of us is tracking those two vital KPIs for their shops? Handling time (TTS - time to ship) - the time between receiving an order and shipping it. Shipping time - the time between shipping from your warehouse and delivery to the customer. Delivery time - sum of both. So are any of us using modules or internal tools to measure those KPIs? This is useful for inner workings optimizations and, of course, for comparing carriers serving the same delivery zones. I'm curious if editing the delivery timestamp in the table during marking it as Delivered or at a later point is a viable option for making those stats more accurate. I, as a small merchant, do this in bulk when I have free time to clear the 'Shipped' orders from my list. I imagine there are shipping modules that also track delivery and will mark the orders as Delivered or Returned, etc, but I've never worked with similar.