datakick

I've just released new version 0.0.3, with following changes: Features: Ability to register third-party triggers and actions -- Other modules can now register their own triggers and actions. I will soon release new version of my other modules (datakick, revws, pricealert) that will add integrations with conseqs. That will allow to trigger action when new review is created, generate xml/csv file when something happens, etc. Import and export rules -- you can now export your rules and import them back, or to another server. If you have some interesting rules, you can now share them with the community! New action - log into text file,... you can log anything that happens in your store. For example, you can keep track of order state changes. Or you can generate list of orders with VAT number in separate file, etc. New action: Assign customer to group - you can, for example, automatically assign your customers to B2B group if they enter VAT number New binding mode - Interpolation -- in previous version, you could bind action parameters to either constant, or value provided by trigger. Newly, you can combine multiple values using interpolation binding. During runtime, placeholders will be replaced by actual values. You can use this, for example, to personalize subject email: Improvements: Added more common context variables that you can use for binding (date, time, current url, shop url, shop email,...) Caching object models detection to improve performance Bugfixes fix mobile issues I'm open for any ideas for future enhancements!

Please don't, that's not how you should customize thirtybees (or prestashop). Changing core files is the worst you can do, it will lock you to the current version, with very limited options to upgrade. The best way to do this is to implement your own module. If that's too hard for you, at least do this using override. You should never change core files. In other words, Advanced Parameters > Configuration Information > LIST OF CHANGED FILES should be empty. If it's not, you will hate yourself soon enough.

There is nothing different here from prestashop 16. You will need to do the same changes on both platforms.

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