datakick

Look in server logs. These are usually accessible via your cpanel. If unsure where to find them, ask your hosting provider

I agree with this, and I will write a post about our high level plans. How do you suggest we do that? Please advice some easy to implement solution, or even help set it up. We would be quite grateful. I would personally love to have some publicly available feature request management tool. Currently, enhancement requests are submitted all over the place. In form of github issues, here on forum, on feature request page (https://thirtybees.com/feature-request/), via emails, on slack channel. I have yet to receive sms with feature request, thought 🙂 We try to collect them and copy (interesting one) to our Jira for further refinement, analysis. A lot of the ides are discarded right at the beginning because they are not 'core' material. Merchants often suggest things like 'we want a button' or 'infinite scroll', and these can't be implemented in core, obviously. So yeah, some centralized way to collect ER would be great help. It's a business

This morning at 7am Sprint 3 has officially started. This sprint will be a little bit shorter because of the Easter holidays, we have only 8 days to finish following tasks: Finish Core Updater enhancements continuation of work from sprint 2. There are still some work left before we can release a new version of core update Automated testing pipeline in docker implement docker container that we can use to run automated test on any branch / revision submitted to github integrate this docker into CI pipeline Multiple feature values this is one of the most requested enhancement that existed for a long time, and we will finally implement it it will mean a potential, but very small, compatibility issue Tracking framework implement framework that will allow sending various information about your thirty bees installation to our tracking server (don't worry, it will be on opt-in basis) tracking framework will use scheduler that we implemented in sprint 2 Track environment information once the Tracking framework will be implemented, we will use it to obtain first set of data: php version installed php extensions mysql version memory limit timeout limit Bug fixing review and merge PR requests fix couple of high severity bugs Support requests work on paid support requests Please ask if you have any questions about anything

Yes, most of it will. The code is developed on different branches, and submitted to github already. Once it goes through automated testing, will be merged into main branch, and released to bleeding edge. Not all, of course, for example php-8 compatibility work is very much work in progress, so this will not make it to the bleeding edge for a very long time. But it will, eventually.

First of all -- you should update to tb 1.2. A lot of php compatibility issues were fixed there. So that could fix the problem for you. It might not, in case php compatibility issue comes from third party module. In that case, best thing to do would be to contact module developer. You could also look into error logs, find the error, and post it here. Maybe we can help.

I think you guys deserve to have a better visibility into how thirty bees development is going forward. So I decided to write bi-weekly sprint overview. Let me start by explaining how we do development at thirty bees. We use scrum methodology, with 2 week sprints. In agile development, sprint is (usually) 2-week period of time when development team implements and delivers some functionality that has been agreed upon. Although we have a very small team (some naysayer would say it's not a team at all 🙂 ), we decided to practice this agile process for various reasons. One of them is to be more accountable and focused. Another is to have better understanding of how much work we can really deliver. Before every sprint, we have an internal scrum meeting where we decide on what will be implemented in the next 2 weeks. We have a huge backlog of items that can be done, with effort estimate. We also have a roadmap. We know when the next major version is going to be released, and what functionality it should/must contain (I will write a dedicated forum post about this soon for those interested). We use these information to select tasks for the sprint. We try to put tasks from different areas into to each sprint. The result contains tasks from these categories bug fixing -- we dedicate some time to fix bugs, maintain github, PR, etc enhancements that bring value to merchants -- these are standard enhancement requests, like multiple feature values or order editing platform enhancements -- these are enhancement that you guys don't know you need, but you will love them 🙂 Also tasks that will make platform more friendly and interesting to third party developers, theme developers, etc. chores -- everyone hates doing chores (I know I do). But they need to be done. Tasks like server updates, implementing testing pipelines, support for php8, and what not. The platform would implode without regular maintenance. enhancements that bring value mostly to thirtybees org (us) -- we are adding some functionality to the core / modules that will make us happy. For example, we plan to add usage tracking (how many people installed tb, what features are they using, what errors did they encounter, etc). I understand that merchants don't care much about these (and some will not want to share these info with us), but we need to know. Otherwise tb company will fail, and tb platform will go with it support and paid tasks - time dedicated for paid support. Merchants can contact us and ask for some custom development, server migration, updates, etc. Currently our only stream of revenue. OK, that's probably enough introduction. Let me present to you what we have done so far Sprint 1 01/3/2021 - 16/3/2021 The first development sprint started when I finally joined thirty bees org full time at the beginning of this month. The goal of the sprint was to start progress, and to release first version. What we did: Translation handling - release prerequisites temporarily remove php8-polyfill dependency -- tb failed on php 7.2 and newer because of it Tool to extract translations - automated script that extracts translatable strings from core, themes, and modules Tool to upload translations - script that uploads extracted translatable strings to crowdin, where you guys can translate them Tool to download translations - script that downloads translations from crowin and prepares translation packs Tasks associated with releasing new version Build and release all modules Build and release core Prepare translations Release notes Deploy to demo server Multiple php builds Extending thirty bees build machinery to support building thirty bees for different php versions. We still support php 5.6, but this makes it very hard (nearly impossible) to maintain. It's because many php libraries that tb depends on are not supported on this php version, there can be composer dependencies conflicts, etc. Extend core updater to request specific php version -- work in progress Bug fixing in first sprint we dedicated 1 day to github maintenance, fixing some bugs, merging some PR, and general backlog cleanup Support paid support requests Sprint 2 [current] 2021/03/17 - 2021/03/30 Plan: Core updater enhancements Make core updater user friendly -- core updater was made by developers for developers, that's not good support update to php version build refactoring code to make it less dependent on tb core -- we plan to use the same module as a migration tool from ps16 various enhancements, like tracking specific revision Carrier price semantics enhancement that allows merchant to enter shipping price with or without tax this also fixes AEUC proportional issues Scheduled tasks thirty bees will have build-in scheduler (cronjobs) to run scheduled tasks we need this as a stepping stone to implement additional features, like maintanance tasks, automatic backups, automatic index regeneration, updates, tracking, etc ElasticSearch this module was originally implemented using crowdfunding, it was a shame it didn't work. We fixed that review and extend existing PR requests for ES module, make it work with all supported elastic search versions fixed various bugs PHP8 support ongoing effort to make tb compatible with php8 in this sprint we renamed Attribute class, and all its usages in core. This is work in progress, not in main branch, not yet available for general audience Support paid support tasks in this case, the result will make it to the core, as feature custom Permissions for back office controllers -- you will have an option to hide some tabs in Product back office edit page. For example, you can restrict translators employees to see and edit only Information and Seo tabs. Then won't be able to break your pricing Work queue Work started on work queue feature This is a mechanism that allow us to run some tasks in parallel / in separation from main execution thread this will allow us to improve performance and to implement reliable long running tasks example use cases sending emails -- instead of sending email immediately/synchronously, we will create email task and push it to work queue. It will be send shortly by work queue worker. But it will not block main thread -- the server response will be much faster. Also, this allows for re-trying sending emails on error Bug fixing - Sprint 2 How is it going so far: We are little bit behind the plan -- to implement Core Updater enhancement took much more time than originally estimated. However, we are almost on track. For those of you interested in burndown chart: Sprint 2 will end today, and new Sprint 3 will start tomorrow morning. We have a sprint planning meeting today where we will finalise and agree on scope for the next sprint. I will create new forum thread containing plan for sprint 3 this evening, or tomorrow. If you guys have any questions, don't hesitate to ask 🙂 Have a nice day all

Yeah, you guessed right, it contains integrating your two PR + some additional enhancements 🙂

That's hard to anwser. How did you implement the 'extra tab'? What is it, actually?

It's tracked in our Jira, not really publicly available.

I thought so 🙂 Yeah, it is irritating. But it does not hurt that much, database can take it. If we "fixed" this, who knows what would break. @yaniv14 is right -- the most important information is stored inside order/invoice tables anyway, so it would probably work fine. But there might be some corner cases when it would break things -- refunds, third party modules, etc...

Why? Really, I mean why are you bother with something like this?

No, it didn't work correctly. If it used to work, then it was a bug that you unfortunatelly counted on. When product in managed by ASM, it must have associated warehouse, and only carriers associated with that warehouse are allowed for product. That's the whole point of ASM.

I don't think that's an error. If you had advanced stock management enabled, and you selected that new products should use ASM, and your didn't associate your products with warehouses OR you didn't associate your warehouses with carriers than it makes sense that there were no carriers available. Thirty bees tried to find carrier that can deliver product from warehouse, and failed. That's not error, that's misconfiguration.

In most countries businesses are required by law to issue invoice, and it must usually contain address. Therefore, collecting billing address is a must even for virtual products. You can hide shipping address, of course.

Of course, looking forward to it

Actually, this is expected behaviour. If I have Product A: base price = 100, tax = 22, final price = 122 Product B: base price = 100, tax = 0, final price = 100 Shipping with Shipping Cost = 100, "Price includes tax" = NO enabled "Proportionate tax" Then if I have 1 of each in the cart, then shipping tax is 22% of 1/2 * 100 0% of 1/2 * 100 which is 11% ==> shipping price is 111 If I put 2 products A and 1 product B in the cart, then proportion is different. Product A now account for 2/3 of shipping price, and Product B for 1/3 of product price. Result tax is 22% of 2/3 * 100 0% of 1/3 * 100 Which in total is ~14.66% => shipping price is 114.66 If I put 1 product A and 2 product B, then the result is tax is composed of 22% of 1/3 * 100 0% of 2/3 * 100 which is total tax ~ 7.33% => shipping price is 107.33 The calculations are correct, it just isn't very user friendly. That's why the option "Price includes tax" = "Yes" exists, with that the final shipping price will be always 100, and base price without tax will change for each tax bracket.

Yeah, I can reproduce it as well. The same problem exists in 1.2.0, though, so it's not an injection. But I will look into it, hopefully the fix will be easy

New feature was just included in the bleeding edge. It should resolve this proportionate shipping tax issue. In carrier settings you can now specify if the shipping cost entered in the range table are with or without tax: By default this is set to 'No', for backwards compatibility. If you set this to Yes, and enable 'Proportionate tax for shipping and wrapping' then the system should work as expected. For example, I have set shipping cost to 100EUR including tax, and added two products with different tax rates to the cart. Result is following: @30knees I would like you to ask to test the solution, if you have some testing server. You can use core updater to update to bleeding edge - 'main' version.

If you know there is a bug, then please file github issue, so it won't get lost. It's quite easy to forget forum posts. When I read forum on mobile I don't create github issue immediately, and then forget about it 🙂

You know, you can create issues in github as well. https://github.com/thirtybees/thirtybees/issues/1308

FPC modules depends on overrides to hack into the core system. In this particular area, thirty bees core is very different compared to vanilla ps16, because of native FPC cache. This difference means that third party FPC overrides might not work. I'm not saying they don't

FPC don't know what is displayed on the page. For example, if you install my product comments module, reviews will be part of product page. When new review is submitted, new row is stored in database table. But thirty bees FPC (or any other caching module) don't know what that mean. Thirty bees have no idea on which pages this record is displayed -- in this case, it's a product detail page, category listing, home page, review list page, possibly blog posts, etc... All these pages will show outdated information (new review will not be there). The worst situation will be on product page itself, because the customer will not see the review he just submitted. He might thing that something went wrong, and submit it again. And again.... And all these duplicate reviews will be eventually displayed, once the cached version is flushed... This is just one example. There are hundreds of modules (and core features as well) that can be negatively impacted by FPC. You can try to mitigate this impact by setting FPC dynamic hooks, but... some problems will still happen. If your pages are mostly static, then go ahead, use FPC. If you use a lot of modules, I recommend not to use any FPC. You would shoot yourself to the foot. But yeah, FPC is working correctly. It is working as designed, although design is seriously flawed 🙂

Hi everyone, Elasticsearch module received some love lately. A lot of bugs were fixed. Module should now work on php7 version without issues, and ES versions 5.x, 6.x, 7.x should be supported. Before we release the module officially, I would like to ask community member to test it. You can download pre-release version here elasticsearch-v1.1.0-pre.zip For testing purposes you can start up elastic search in docker using command like this: docker run --rm -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" elasticsearch:7.11.2 Many thanks to @zen for his contribution. Most of this release is based on his work.

Update your store to latest version of tb install maxmindgeoip2 module. create account in maxmind download maxmind city database and extract it to /tools/geoip/ directory

Full page cache works, to some extent. Problem with this kind of caches is that... well they will never work reliably with thirtybees/prestashop system, because there is no way to detect when something changed and flush the cache. Which means that your store will, ultimately, display stale information. For many merchants this is acceptable. But you must be OK with stuff like your customer entering new product review, and then this review not being displayed for couple of hours you change product price, and it correctly changes on product page, but not in category listing ... Note that you would experience these issues with tb native FPC, and with any other similar solution. As I said, there is no way to notify caching layer to flush the cache when content changes. In my experience thirty bees is pretty fast, and you can usually work very well without FPC. If your server is slow, there is probably some reason behind that -- badly written module, bad server, etc.