the.rampage.rado

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.