Jump to content

Welcome, Guest!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

datakick

Administrators
  • Content Count

    1,252
  • Joined

  • Last visited

  • Days Won

    96

datakick last won the day on December 5

datakick had the most liked content!

Community Reputation

906 Excellent

About datakick

  • Rank
    Petr Hučík

Information

Recent Profile Visitors

2,967 profile views
  1. datakick

    Nginx

    Oh, it can happen anywhere. It really depends on employment contract. They usually contain clause like The Employee hereby assigns to the Company all rights, including, without limitation, copyrights, patents, trade secret rights, and other intellectual property rights associated with any ideas, concepts, techniques, inventions, processes, works of authorship, Confidential Information or trade secrets developed or created by the Employee during the course of performing work for or on behalf of the Company that the Employee conceives, develops, discovers or makes in whole or in part during or after the Employee’s employment by the Company that are made through the use of any of the equipment, facilities, supplies, trade secrets or time of the Company that the Employee develops, discovers or makes in whole or in part during the Employee’s employment by the Company that relate to the business of the Company, or the research, or development of the Company Which means that if he wrote even a single line *during* work hours (when he was being paid) the company owns the code. Even if he was on home office. If he used company issued computer for nginx development, then the company owns the code. Or if the company core business is related the the code developed (for example if they offer their own server software) they have valid claim as well. Ultimately it is up to the court to decide.
  2. It would, but that functionality is not implemented on purpose - this db migration thingy is still in an early phases, and there can be some bugs. It's much safer to simply not allow 'Fix all', or even 'Automatic fixes' right now
  3. This is a bug in the module that was always there. It would reproduce on prestashop 1.6 as well if you run it on php7. You should ask the developer to fix it -- make it php7.2 compliant. You can also fix it yourself by changing the signature of the method to public static function insertTagM($public=false)
  4. You don't need to store them. As long as you have card detail input fields on your site, you are processing and transfering credit card data. And you need to be PCI compliant for that. But I think we have highjacked this discussion. It's about jquery update, not about PCI compliance.
  5. That is exactly what makes you PCI compliant. And let me tell you, there's nothing wrong with leaving your site. In fact, it might help your sales. When some website ask for card details directly, I become very nervous. And unless the website belongs to a well-known company, I leave without completing the purchase. I'm just too scared to send my card details to anyone
  6. There's a native paypal thirtybees module that works fairly well. And of course there's stripe. I would love to use it myself, unfortunately striped does not support my country yet.
  7. Any merchant that wants to process, store or transmit credit card data is required to be PCI compliant. The solution is simple - don't do that. You can choose a payment provider which complies with the PCI, and which can process, store or transmit card data, so you can avoid the whole struggle with PCI. This means that the payment company you work with processes the payments itself, so your website doesn't touch customer's cards details. They take all the PCI burden themselves. Now, if some payment provider have requirements on stores they integrate with is a completely different topic. It's not PCI, it's a vendor-specific requirement. Braintree, of course, can have any criteria for their partners. But that doesn't mean you are in breach of PCI.
  8. Thanks @musicmaster for your reports. But to be frank, I don't really believe these have much to do with 1.1.x did this module actually ever worked correctly? In my experience, when you ask customers to evaluate some feature / new version, they tend to bring up persistent issues... because they want them fixed, and they frustrate them. I believe this is on of this case. If not, please let us know what exactly does not work in 1.1.x, but work in 1.1.0 Very vague. Usually when customer can't complete the order, the problem is not technical (bug in code), but it's usually misconfiguration. Disabled country, bad carrier zone definition, carrier-payment association missing,... You know what I'm talking about. If there indeed was some bug in 1.1.x that prevents completing order it would be a showstopper, of course. I personally haven't encountered it - and I'm running my own store on 1.1.x, and already migrated few of my customers to bleeding edge as well. So excuse me, but I'll disregard this report as well, at least until you or somebody else can provide some reprosteps / context when this happens. Layout, really? Very unlikely 1.1.x broke theme layout. Core has no way to impact how theme outputs its content. When there are theme-related compatibility issues, they are always caused by controllers providing wrong / different datasets to view layer. But these problems does not change layout, etc... they result in incorrect data being displayed. And again I need to ask - is this new issue in 1.1.x? If you rollback to 1.1.0, does the theme displays the layout correctly? I really don't think so At the moment, tb does not have any long-term plan regarding new features - no new feature development are really on the planning board. Current efforts are aimed to stabilize the system. That means mostly bug fixing. Problem is that when we fix a bug, very often somebody claims it's a compatibility issue (you too, by the way). That's because some module / theme / modification worked around this bug. It expects the bug to exists, and when it's fixed, the module stops working. Now, tell me, should we really resign on bug fixing, because what if some solution depended on it? If you really think so, then let's close this project. Because it will die anyway in a slow and painful death. What standards did we broke? We know that there there is a compatibility issue on 1.1.0 regarding themes. This is actually talked about in the other thread, and is already (somewhat) fixed. Now, you might consider it frightening that the 1.1 compatible theme was released. I look at it a little differently - as an acknowledgement of the existing issues in the theme by its author. It's a regular fix. Of course, I don't expect *all* theme developers to do that. Hence the effort to increase the theme backwards-compatibility again, see code in issue-1104 branch. I haven't as well. But posts like this really take its toll
  9. But I agree with you and Markus that it's not necessary to throw these warnings in front of merchants so aggressively. So I've modified the solution and hide all these warnings behind a Show button:
  10. Or course I'm serious. After all, the fact that the theme is maintained by thirtybees does not make it flawless or bug-free 🙂 And as you see, even native theme has these issues. Without these warnings, nobody would ever discovered them, or fixed them. And it wasn't that hard, let me tell you. The fix took the whole 3 minutes of my time. And the result is correct -- for example, the beesblogcategories module now actually shows the categories in left column, as it should. These warnings are there to nudge theme developers into doing their work properly, and to nudge merchants to verify that modules mentioned in warning sections works correctly
  11. You are probably right here, it's not necessary to frighten users. I'll try to come up with a little less hardcore messages
  12. It does. It behaves exactly as I described above -- if the theme *mentions* some module hook in config.xml, then this config is used. Otherwise, hooks are not touched for this module (but warning is emitted). For themes with correct config file, the result is the same. For themes with incorrect config file, the the result is still functioning theme + couple of warnings. In 1.1.0, the result was non-functioning theme. That's a difference Of course, we could just hide these warnings. Merchants would be happy that *it's all goooood*. But the truth is, it's not. Merchants should verify that the mentioned modules were installed correctly. And theme developer should fix their theme. Again, it's about correctness. We know that the theme contains errors, is non-deterministic, not-specific. We can still try to install it, and the result will *most likely* be ok. But the problem is that it might not be ok. And that's not the situation we want to officially support. When you have theme that is not correctly written, then you can either have a system that installs the theme, says everything is ok and green, even though you can clearly see it's not. This is how prestashop do it or you can have a system that at least warns you something is wrong, and points you to the problematic parts
  13. Ok, branch issue-1104 contains proposed fix for this issue. Anyone who can, please test and let me know how it works for you. Simply use core updater to forward to this branch.
  14. There is PaymentModule class in tb. However, the proposed fix is not very good. It was actually rejected by prestashop. Doing this check in validateOrder is way too late -- payment is already processed, and money are on the way to the merchant. That means that order should really be created, even if stock will go to negative numbers. There is no easy solution for this problem, as there can always be some time that your customer spent off-site. The only way to solve this is to implement some stock-blocking mechanism, complete with automatic release
×
×
  • Create New...