datakick

I've just released new version 1.0.24. This version brings following enhancements and bugfixes: Enhancements Reviews with empty titles are now supported Review tab label now shows number of total reviews Customer is redirected back to product page after login Added default css for review average custom placement Italian translation French translation Bugfixes Fixed image overflow issue Fixed images being stretched in firefox Fixed ordering by usefulness Also, new paid version 2.0.5 has been released as well, containing the same features and bugfixes

@yaniv14 answered you already. I can elaborate more: 1) create new module 2) this module should register hook actionEmailSendBefore 3) in this hook, you can add your files to 'fileAttachments' output parameter. That requires loading the file content from disk and passing it in a structure like this: [ 'content' => ...file content... 'name' => 'filename.pdf', 'mime' => 'file mime type' ] If you don't know how to do any of these steps, then you will have to study. There are plenty of resources for prestashop module development out othere. If you don't have time, then hire somebody to do this for you.

Thanks for the heads up. I didn't really test the module for mobile use, because not many merchants are managing their back office using their phones. But it should definitely be fixed

PS: new version is also compatible with ps16 / ps17,... in case you haven't still migrated 🙂

I've just released new version 0.0.2 -- I've added another level of records data that you can use for conditions and/or bind to action. For example, when you choose trigger Before record is created and select record = Product then in Conditions you can use all product fields -- you can write condition like this: Product:Name contains 'Cup' This was already available in previous version. This new version will allow you to access sub-records field values as well. For example, every product has default category, so we can now write condition using this default category values: Product:Category:Name = 'Shoes' This mechanism is implemented using lazy loading technique, so it shouldn't impact performance. Data for sub-records are loaded only when needed

Good idea, I'll add these to my backlog

This looks like a bug in thirtybees core, or some override is messing around. If you send me ftp access, and back office access, I can have a look into this for you.

This is just a default design. It's intended to be light and spacey, because that's what I personally like. I hate too many information on a page. But it's just my opinion. You can, of course, modify css that comes with the module and adjust it according to your needs. In this case, you will want to target .chex-row, .chex-input or .chex-input-label css classes. For example add this to your theme's css file: .chex-row { margin-top: 0px; margin-bottom: 0px; }

Hard to tell. We would need to go over the filesystem and figure out what content is related to database entries or individual store instances, and what not. The investigation itself would take couple of hours, and the fix itself would require at least week of work.

Thanks Andy for the access. I have found the issue - it was related to page javascript optimization / moving to bottom of the page. I've fixed this and released a new version

Well, you will get into issues with store customizations. Same codebase means same modules. If owner of Store A deletes some module, other stores will be affected as well. The same applies to module upgrade, for example... Also, file assets will be problematic. For example, product images are stored using image database id inside directory /img/p/... When you have two databases, you will have file conflicts. When I think about this... you better don't do it...

Why not use multistore? Anyway, if you are really committed to this approach, you will need to edit /config/settings.inc.php and define database settings conditionally, based on current request url. Just note that there might be some corner cases when the thirtybees is not bootstrapped inside web context. For example, some cron tasks can be setup to run in php-cli environment.

I've just released first beta version of this module, you can download it here. There are still a lot of work to do, but I wanted to release it as soon as possible in order to collect your opinions and ideas. I hope there will be some 🙂 You can also test this module on my demo server - go to Advanced parameters > Conseqences. Please be careful and don't ruin my test account too much 🙂 Some information about the module: - this module allows you to create Rules - every Rule consists of three parts: trigger, conditions, and action - trigger is some event that can fire the action, for example new order created email is about to be sent page view order status change ... etc - conditions - optional settings that you can use to react only on some events. For example, you can use conditions to execute action only when new order is created for customer with id 123 - action - this is where you set what you want to do in reaction to trigger event. For example: send email redirect raise error change product quantity execute custom sql Some screenshots: 1) Rule builder: 2) Choose trigger 3) enter conditions: 4) define action

Sometimes cherry picking single commit doesn't work -- for example, it might depend on some code that was committed before this commit, but is not part of 1.0.8 The only answer I can give you is to use core updater and update whole shop to bleeding edge.

The memory limit is a red herring, not a root cause. There is some error thrown somewhere, and error reporting engine tries to serialize this error message and output it to error page (encrypted). If the context is large enough, this operation can easily lead to memory exhaustion. This problem is fixed (or mitigated) in bleeding edge. So, if you can, try to use core updater and update your shop to bleeding edge. That should fix the error reporting issue. Then the root cause will be revealed -- and of course, you will have to fix that one as well.

I remember that @Traumflug fixed similar problem lately. Forward your shop to bleeding edge using Core Updater to see if this bug is fixed in upcoming version.

Cache modules are one of the few that aren't (deliberately) compatible. The question is, do you need to use this module at all? Thirtybees has very good response time even with all caches disabled.

This is, in general, the intended use case. The module will work like this: 1) something happens in your thirtybees that will trigger the consequence rule 2) every trigger type will collect and provide details about the event. For example, *product added to cart* event would fetch information about added product, information about cart, information about customer, current cart total, etc... and pass these information forward to conditions/action layer 3) conditions can be build using only those information passed by trigger. So, there can be condition like 'added product id equals 100' or 'added product description contains word T-shirt'. 4) if all conditions are met, then the action is trigger 5) most actions needs some parameters for execution. For example, action 'Redirect' needs redirect url. These action parameters can be provided as constant during rule definition, or can be derived from trigger output. For example, we could say the redirect url is 'https://www.google.com/{product_name}' where {product_name} will be substituted on the fly Your use case would require to define condition (step 3) like this: - there exists some customer record in database that is marked as blacklisted and has same email as currently pending email While this condition can be implemented, it will not be in the first few versions, as I will first try to tackle primitive conditions

You can copy post.tpl to themes/<yourtheme>/modules/beesblog/views/templates/front/post.tpl and make your modifications there. This file will not be overwritten on module update. But you are right, I also don't see any reason why it should use <h4> by default. Let's track this in github issue: https://github.com/thirtybees/beesblog/issues/33

Thanks for bug report and proposed fix. I was able to reproduce the caching problem, and the fix indeed works correctly

That's true. But fortunately, creating new trigger or action is very easy (at least it has been easy so far). One needs to declare input/output parameters, and then implement the actual action execution. If there will be a demand for this module, I'll be happy to invest some time on this task. And maybe some tech savvy users will be able to implement (and share) their own actions/triggers.

Thanks for the ideas. The first one is probably not possible -- it would be hard/possibly impossible to change page content. Actions that can be triggered are somewhat independent, not related to the source / trigger. The rest of your ideas could be theoretically done

This gave me an idea for simple module to flush cloudflare cache (via api call) when store cache is cleared.

There is really something very wrong with your site. More precisely, there is some cache somewhere that is returning non-thirtybees files. 1) Thirtybees contains notification.js file, but this file does not contains references to show_new_orders at all 2) thirtybees version of dashgoals.js javascript file contains this content on line 163: $months = $this->setMonths($year); As you can see, there is no reference to $, so the error can't be trigger. The only explanation is that something somewhere is returning old/prestashop versions of these files. Please make sure to 1) clear browser cache 2) clear server cache 3) clear any proxy server cache (nginx, cloudflare, or any other service that might be between your server and your browser)

Thanks @Briljander for your input, I really appreciate Unfortunately these use cases will be out of the scope of my module (at least for now), because there aren't any immediate triggers that I could hook to. My module can only react when something happens (record is saved to database, visitors perform some action, email is about to be sent, etc...). Here there aren't such immediate actions, it's more about state in the database. I do, however, plan to implement scheduled triggers in the future, if this module takes off. There would be a cron task that would periodically check if some condition is met, and if so then trigger action. This mechanism could be used to implement your use cases.