Leaderboard
Popular Content
Showing content with the highest reputation since 11/24/2024 in all areas
-
Hi Guys! Are you getting ready to the new EU Law regarding product safety. Here is a short summary about what it requires from store owners. When selling remotely via a website, the product listing must include: Manufacturer's details: the full name or registered name, registered trade name, or registered trademark of the manufacturer, as well as the postal and electronic address where they can be contacted; If the manufacturer does not have a residence or registered office in the EU/EEA: the full name or name, postal address, and electronic address of the responsible person (responsible entity); Information to identify the product, including its image, type, and other product identifiers; Any warnings or safety information. I already have a module that helps stores to comply with it, but in case you have any questions let me know, as I've been studying the subject a bit lately.3 points
-
Nevermind. I opened an Account at Wise and even, if it's a prepaid card as well. This one got accepted 😅 🤦♂️3 points
-
2 points
-
There is no such feature. But you can make a custom query in the SQL manager in BO and pull this list: (adjust the table prefix to your needs) In general - if you want certain list to be created and it's still not a part of thirty bees you can do so with ChatGPT and save it in the SQL manager to use from BO. SELECT email, COUNT(id_customer) AS customer_count, GROUP_CONCAT(id_customer ORDER BY id_customer) AS customer_ids FROM ps_customer GROUP BY email HAVING customer_count > 1;2 points
-
1 point
-
Thank you! You have a PM. EDIT: Thank you for the quick fix! 10/10!1 point
-
That seems to have fixed it. Thanks!1 point
-
Make sure that the necessary PHP installed modules (not the TB modules) are activated on your cPanel. One easy check is to open two tabs of the cPanel PHP version selector. Use the older version of PHP in one tab, and the newer version of PHP in the other tab. Then go through and make sure the same modules are activated in the newer version as the older version. This approach definitely helped resolve 500 errors when I transitioned to newer versions of PHP.1 point
-
I believe it's not possible to fill the APCu cache by a cronjob. This is a big drawback in my use case. I am trying to use redis now. Doesn't seem to be much more complex 😏1 point
-
I'm afraid this is won't work. You can create conditions for order object, not for order products. The condition would have to be something like 'Order contains products from manufacturer XXX', and that's too complicated to implement. But I believe you can achieve the desired outcome using build-in Cart Rules. leave cart rule 'Code' empty so it is applied automatically in condition, set product restriction like this and in action, use 'Send a free gift' Should work out of the box1 point
-
This is not 100% completed functionality -- it can be used perfectly fine, and it is being used by core, but there is still a piece missing that can make this very useful. There are couple of main use cases for this workqueue system: execute some task in isolation, and potentially in different thread/process defer execution of task for some time execute some task on regular basis (cronjob replacement) There are a lot of tasks in the core/modules that we want to be executed, but we don't really care about the result, or even when exactly the task finishes. A few examples: generate image thumbnails for a product sending email Currently, when we call Mail::send() method, the system is trying to synchronously deliver an email to smtp server. This can take a lot of time, and delays page response time. Order confirmation page can take few seconds to display because of this. Work queue system can help with this. We can describe the 'Send email task', and pass it to work queue system to execute it later, and the original process can continue its work. The email will be eventually sent, depending on the workqueue executor implementation. Unfortunately, currently exists only one Work Queue Executor implementation -- immediate executor. This implementation executes the task immediately, synchronously -- so there is no real benefits. We have plans are to implement different executors stand alone executor - there would be a dedicated worker process(es) that run as a cli php application (maybe even on different servers). The task would be serialized, saved in some queue (db, redis,...), end workers would pick it up and execute them. This is most advanced, most complicated, but also provides the most benefits cron-based executor -- tasks would be serialized and saved somewhere (db, redis), and executed on periodical cron events (every minute or so, for example) end-of-process executor -- the task would be executed in the same process that it initialized, but at different time. Instead of execute the task immediately, it would be executed after the response has been sent to browser, just before script end It would be up to store owner to decide, and set up, which executor they want to use. I'm currently running a variant of stand-alone executor on my site. It's not a complete solution, just a proof of concept, but it works quite nicely. But back to your question. To use this system, you need to Implement WorkQueueTaskCallable class. The execute method accepts $parameters. It can be anything, but it's a good idea to somehow encapsulate the shape of that parameters. Example task that generates image thumbnails/types can look like this: class GeneratImageTypesForImageTask implements WorkQueueTaskCallable { static function createTask(Image $image): WorkQueueTask { $parameters = [ 'imageId' => (int)$image->id ]; return WorkQueueTask::createTask( GenerateImageForProductTask::class, $parameters, WorkQueueContext::fromContext(Context::getContext()) ); } public function execute(WorkQueueContext $context, array $parameters) { $image = new Image((int)$parameters['imageId']); // ... todo - generate all image types for this image } } To execute this task, somewhe in core/module you need to get instance of WorkQueueClient, and enqueue the task: //... $image = new Image((int)$parameters['imageId']); $workQueueClient = ServiceLocator::getInstance()->getWorkQueueClient(); $workQueueClient->enqueue(GeneratImageTypesForImageTask::createTask($image)); And that's it. If you want to schedule execution of the task, you can create a Scheduled Task and save it to database. $payload property of scheduled task is passed as $parameters to callable.1 point
-
I don't really know, you will have to test and let us know 🙂 I never used APCu in production, only on dev site. I don't like the idea that cache is part of the php process, I prefer standalone caching solution (redis for me)1 point
-
1 point
-
No, only litespeed. Will send you a link to test the speed and caching of my site.1 point
-
1 point
-
Hello, you can use JTL-PackingBench – Help pages on the free shipping tool by JTL (there is no connector especially for tb, but you can use PS-connector and/or implement your changes into the connector by a developer)1 point
-
Hello, that's exactly what we're going to do. I'm still doing some tests, as mentioned in another topic. Datakick suggested that it could be done in 1-2 hours of work. That's money well spent. Of course you want to try things out yourself and if you're successful with small changes to the code, that's great. For other things, however, we're at the point where we'll outsource it, which includes the final adaptation for PHP 8.x.1 point
-
If your store runs on PHP7.4 without errors, you can indeed continue running it on that version. But you should definitely strive for higher PHP version compatibility, and update version once you achieve it. There is no good reason not to do so -- newer versions of PHP are faster, more efficient, and more secure. And of course, you will be able to use modules that are compatible with newer versions of PHP only. For example, I'm not writing new module that implements digital invoices functionality, and because of the library this module uses the minimal supported PHP version will be 8.1. It's not hard, and quite safe, to achieve higher php compatibility. PHP never introduces a breaking change out of the blue. They raise WARNING / DEPRECATIONS in previous version, and introduce breaking change in the next one. We have a great tool named collectlogs to handle those warnings. So the process is: install collectlogs module wait for a while, allow the module to collect deprecation warnings look at the warnings, and fix them rinse and repeat once your store does not generate any warnings for a while, you can safely update your php version Note: some (well, sometimes a lot) warnings are not caused by php native methods, but by libraries / core itself. These warns you about upcoming breaking changes in the library / core itself, not about PHP breaking changes. You can ignore these for the time being, as they have no impact on PHP update. Example of such warning: Note 2: if unsure how to handle fixing the issues, you can always hire some dev do to that for you. In my experience, most stores can be 'fixed' in 2-4 hours, as the fixes are usually trivial. Note 3: there are a lot of fixes described on a forum, especially fixes for themes. Most themes are very similar, so you can apply the same fix to your theme without changes. Note 4: you can also look into niara / community theme github history, to find out how some problem was fixed in that theme. For example, if collects logs tells you there is an issue with breadcrumb.tpl, you can go to https://github.com/thirtybees/niara/ , open breadcrumb.tpl file, and look at the history: https://github.com/thirtybees/niara/commits/master/breadcrumb.tpl1 point
-
1 point
-
Good for you! But I think a new thread regarding the GPSR Directive may be a good idea. Many stores are still unprepared, and there is much to do in some cases.1 point
-
Indeed. Looks like a bug in translation system, when $this->l() does not accept strings with quotes, only with single apostrophes. Oh my... The fix is here: https://github.com/thirtybees/tbcontactformrecipientfilter/commit/0318e7a56d261a21e92fc9960aff6ed3bd80b66d The fix of the actual bug (translation strings extraction in core) will be hopefully in next version.1 point
-
The problem could be the css worked for me, without the middle semicolon. I experimented on a test site > backoffice > preferences > custom code > CSS so that could have been the reason as well. Maybe the custom code CSS is applied last. I didn't know about the autoload directory, which sounds neat.1 point
-
You can edit/add/remove CMS pages at Preferences->CMS and you can control which ones to display in the footer at Modules->Block CMS1 point
-
I recently started using prestools... while it does not have all of the functionality of SM, I have found it to be quite useful in facilitating batch edits and various other needs. I currently use it for light category work and daily for products. I have the supplier plugin and plan on getting two more - so far so good.1 point
-
ok, i don't have a multishop, but for a "single" shop setup this works for me: You create your GA4 tag in google analytics first. You will get code like this, change the id G-58HPYXXXXX to your own id. <!-- Global site tag (gtag.js) - Google Analytics --> <script async src="https://www.googletagmanager.com/gtag/js?id=G-58HPYXXXXX"></script> <script> window.dataLayer = window.dataLayer || []; function gtag(){dataLayer.push(arguments);} gtag('js', new Date()); gtag('config', 'G-58HPYXXXXX'); </script> copy this code in: (instellingen is dutch for Settings)1 point