datakick

@slick_303 said in I'm going to create a free module: Great idea, thanks for your time in advance. Thanks, but the idea wasn't mine - I've shamelessly repurposed thirtybee's crowdsourcing idea :)

Hi guys, it's the end of year and I've decided to contribute a little bit more to the opensource community. So I will start next year by creating a free thirtybee module. Of course, I would like to create something that people actually use. In order to do so, I need your help to decide what module to develop - just go this poll and either vote for existing idea, or suggest your own. I will start working on the winning idea at the start of the year. I plan to spend ~14 days developing the module. That's plenty of time to create something cool. And hopefully useful. The question is - what? Petr

@30knees said in DataKick and Google Merchant with Combinations: I'd just like to re-state how fantastic @datakick's customer support is. The tool is also incredibly powerful. You can use it as a bulk editing, too, too. It's highly recommended. One of the few exceptionally well-done modules out there. Thank you @30knees , I really appreciate the shout-out

just FYI, i've just released a new version that fixes the collate problem.

Thanks @30knees I'd like to add one more think - during investigation I found out that there is a problem with database collations. This issue cause some sql to throw exception (for example sql to retrieve data for gmc combinations template). I already have a fix for this problem, and I'll release it today / tomorrow as part of 2.1.0 release together with XML import.

@Traumflug said in Multistore fields: The question arising is, what's the gain for merchants? The benefit for merchants is, well, bug-free system :) As I wrote in my previous post, every code that actually access data from tb_product.price instead of tb_product_shop.price is bound NOT to work correctly in ALL scenarios. There will be some settings where this code fails terribly, and it will produce strange errors / confusions. What's worse is that there are many scenarios when this code works just fine. And that makes the whole debugging / fixing much more harder. To demonstrate these weird errors, let's continue with my example from previous post. Let's say there is some module that will apply a discount only if shopping cart contains a product whose base price is more than 90 USD. And let's say this module works solely on tb_product.price . Then the discount would be apply only if the product was last edited in shop A context (because tb_product.price == 100). If, however, any employee edits the product and change any value in shop B context, then tb_product.price == 80, and the discount will not be applied. These kind of transient bugs are crazy, don't you think? I totally agree this is very hard change, and I'm not suggesting that it should be done. But it's a huge technical debt. That's why I raised this thread - to brainstorm what can be done.

Hi, I just wanted to start a discussion about multistore fields (fields that can have different values in different shops, when multistore is enabled) What bugs me is that values are stored in two places in database. Let's have a look at product base price - it's stored in tb_product.price and tb_product_shop.price. Whenever you save product, the value is stored into both two columns. Everything is OK as long as you don't enable multistore feature. (well, not really, as values in these two tables can quite easily become out of sync) Once you enable multistore the values of multistore fields in tb_product table will behave strangely. This table will always hold the value of the last updated shop. Example: I have shop A with USD as default currency, and shop B with EUR currency. I create shared product, and edit it in shop A context. I set base price = 100 USD. When I hit save, then the number 100 will be saved in both tb_product.price and tb_product_shop.price columns. So far so good. Then, I edit the product in shop B context, and set price to 80 EUR. After save, ```tb_product.price`` will contains value 80. As you can see, the tb_product.price can very quickly became mix of total nonsense. Every piece of code that uses this column will NOT work correctly when multistore feature is enabled. As an example have a look at product list in back office. Solution The solution is obvious but not trivial - get rid of these columns and fix all references in code. Let's have single source of truth. It is definitely not backward compatible. But I believe it would make the whole product much more stable. Just something to thing for version 1.1

@Havouza said in PrestaShop Will Enforce Encrypted Modules Soon: If I buy one license of a software I can use it wherever I want. No, you can't. You can use the module only in the extent of the license agreement. And if the license states that you can use it for one domain only, you can legally use it on one domain only. This has nothing to do with the platform, it's just common law. By purchasing module, and it really doesn't matter if it's for 30bz or prestashop, you have established a binding contract. So, basically, it's up to the module developer to choose licensing options. And then it's up to you to decide. If you don't want to buy a module that has license for single domain only then don't buy it. Go with the module from the competitor. But if you decide to buy it, then please respect the license contract.

@marci123 said in PrestaShop Will Enforce Encrypted Modules Soon: If somebody buys a module it should be allowed to test it on a development site first, shouldn’t it? Definitely agree it should be allowed to test it. And I hope it will be possible within this new system somehow. I was just pointing out that it's quite easy to inadvertently infringe on someone's rights. And I wasn't really talking about the new system - this is the current situation. Even today, many paid modules have a single domain clause in their license agreement. (I actually never read the official addon's license agreement, but I wouldn't be surprised if they had such clause in it as well). And if you install such module on your development site, you are violating the license agreement, and you could get sued. You will probably not, but it could very easily happen.

@Havouza said in PrestaShop Will Enforce Encrypted Modules Soon: A simple question. I buy a protected module and use it. But that shop is not successful so I close it and open another one. With fresh shop install.Now I still owns one module license and want to use it in my new shop. But can I? That probably depends on the license agreement. I can imagine there will be multiple types of licenses in the system - single user + single domain, single user + multiple domains, multiple user + multiple domains (for development agencies) So, if you purchase single user + single domain, and you have already used the license key on domain A, then you will not be able to use it on domain B. If you have bought single user + multiple domain license, then sure, why not. You see - this is exactly the case when even honest merchant can inadvertently infringe on developer's rights.

@datakick Thanks for this plausible explanation. I think as soon as you allow developers to generate and sell licenses themselves you open the door for piracy since there will be a loophole in the system (with regard to piracy). Not really, developer will register the module into the shared ledger using his own private key, and licenses will be generated using the same key. There's no way anyone could submit forged license key into the system without the private key. What do you think is the main purpose? Fighting piracy or binding custumers to the addon marketplace? Personally I think the latter is perhaps the main goal. Yes, this is my concern also. That's why I pointed to this issue in A few thinks to consider section. But I hope prestashop will be smart about this. If they don't, this system don't stand a chance. Another thing to remember is that it's really hard to control these distributed systems. They are actually designed to prevent tampering. You can't impose any rules on the system without majority of nodes agreeing with them (well, majority of computer power, actually). Basically, decision whether the transaction is valid is based on network consensus. When a new transaction is submitted to the system, it will be part of some block. Every node in the system will receive this block, but they will append it to their version of blockchain only if all transaction in this block are valid. So, if majority of nodes in the ecosystem decides that licenses generated by Envato are valid, there's nothing Prestashop marketplace can do about it. These transaction will be valid part of the blockchain forever. Unless Prestashop can harvest more then 50% of all computing power in the system and use it to kill the transaction. Regarding piracy ... using modules and other stuff from warez sites is not without risk. Especially in the ecommerce sector more serious merchants won't even consider using modules from such sites and on the other site, if a module cannot be copied users from warez sites in most cases won't consider buying the module but would use something else instead. I think the damage caused by warez sites is a bit overrated. There will always be users who are honest and would never use modules from shady sources, and there will always be users who don't want to spend money and use everything as long as it is free. Those people however won't turn into paying customers if there is a licensing system, in most cases they would use something else instead. Considering those human factors it is questionable if it is worth the efforts. But we will see. I am curious how things will develop. I totally agree serious merchants will not use modules from these warez sites. But they might be tempted to use the module multiple times (for example on their development site). Or they could simply forgot they have purchased it, and send it via email to their friend. Or they could hire some third-party developer to prepare the shop for them, and this developer could install some paid module to their system without their knowledge... These could stack up. I'm saying that this system, if implemented right, will not harm honest merchants in any way. It's just a way to protect developers.

If I understood the idea correctly, then I believe this could be very beneficial for the entire community ( if done right ) What is the problem? Paid module licensing. At the moment it's very hard for paid module developers to stop their customers from misusing their product ( illegal distributing / copying / sharing / multi installation etc). This could really cut their profits. You know, it's quite easy to find most paid modules on warez sites, free to download by anyone. If developer wanted to fight this, it's a lot of work - if you are lucky and the warez site is located in US you can use DMCA takedown notice, but more often these are offshore servers in countries with limited digital rights legislations. Your options are very limited. In the end, this is the cost of business. You could, of course, implement some sort of licensing mechanism inside your module. But then you will have hard time selling it on official marketplaces. Solution One solution is to have build-in licensing mechanism inside prestashop core that would ensure merchant have the rights to use the module (of course, you can always modify the prestashop core and disable this licensing mechanism, but that's not something that regular user will do) We all know such mechanism is very easy to implement. Why haven't prestashop do it already? Because it's hard to make this open-source friendly. Nobody want single centralized license server that is controlled by one company (Prestashop). That would really hurt the PR. The blockchain is ideal solution - it's decentralized, open and very secure. How it works? When you buy a module on marketplace, they will generate a license key(s) and put them into a shared ledger as a transaction. When you use the license key in your prestashop installation, your prestashop will consume the key - it will create a new transaction in shared ledger marking the key as used. These transactions are verified, and protected by proof-of-work concept in the same way it's used by cryptocurrencies. Basically, after a few minutes it's not possible to change old entries in shared ledger. Not unless you own the most powerful supercomputer in the world. Benefits This will benefits two parties. The module developer and marketplaces - they will see a nice bump in sales. Also, they will not have to worry about piracy copies of their work, since nobody could use them (on vanilla prestashop anyway) Merchants, on the other hands, will not see any benefit - the only bonus for them is the proof of license purchase. But the important part is that this will not hurt them in any way. Not unless they are scumbags that wants to use paid modules for free. Also, merchants can still install and use modules from other sources (free modules, etc...) This mechanism can really attract more developer to the platform. I personally would love it. If prestashop rolls out a system like this, it would be really nice to back-port into 30bz. A few things to consider Open system I believe for this to succeed it's important to keep this system open. This shared ledger has to work with multiple marketplaces, not only prestashop marketplace, so the developer can sell his module over different channels. And, of course, it must be possible for developer itself to generate and sell licenses. But this all it's very easily possible. Who will pay for cpu The blockchain technology requires enormous amount of cpu cycles to be spend. And that costs money. Cryptocurrencies solved this problem by mining - the miners do the heavy lifting, but they will get a rewards in form of bitcoins - every 10 minutes a few new bitcoins are generated and awarded to one lucky miner (or more probably to a cluster of miners). How to motivate miners in prestatrust? There could be a fee associated with every transaction that will be awarded to miners. Or maybe miners can get a license for some module in exchange for their work, and they can later resell them to marketplaces / customers, or use them as they will. There are many possibilities. We really don't know yet At the moment we really don't know how this will turn out. Meanwhile, please, don't look at this initiative with prejudice. It may be very nice functionality. But of course, execution is the king. They may very easily kill this idea.

@roband7 one possible solution is to detach php process from request - installModule will immediately return response, but php process will continue to work (this is basically the same way cron works). There would have to be some javascript on frontend that would periodically check if the process finished yet.

I've encountered similar problem just few days ago - it was caused by low fastcgireadtimeout settings in my nginx configuration. Apparantly 90 seconds isn't good enough. I increased it to 360s and it went well. I guess it would be beneficial to split the installModules phase to several separate steps.

This looks like a bug. There's definitely different behaviour than in ps1.6 . In tb - the language prefix is present if there are multiple languages in store, even if only one of them is enabled in ps - language prefix is not preset if there are multiple languages in shop, but only one is enabled

I agree with @Skipper that this should be renamed. I understand that some retailers use the term “wholesale price” for the price they pay to a wholesaler. But really, how much confused would they be if we renamed this to "cost price"? I believe every merchant would immediately understand what that means. On the other hand, if we keep the name, there will always be the ambiguity.

use the theme that has twitter card metadata - when you share the url, twitter will automatically fetch this url, parse the metadata and display the card.