datakick

Are you changing core files? Please don't do that... you'll get stuck with outdated version of thirtybees. These changes should be handled by custom module. Such module can either provide overrides, or hook to appropriate hooks if exists. In this case, there is a hook named actionEmailSendBefore that can be targeted. This hook can be used to adjust email parameters, for example to add your email address to bcc for all emails, change subjects on the fly, etc... And you can use it to block some emails from being sent, by returning false value from the hook. This is clean and reusable way to customize your shop.

as the reply states, gmail rejected the email because it did not pass SPF check You need to add SPF records to your dns, so email servers can verify that your server can send emails on your domain’s behalf

You can either install the apcu extension, or modify configuration of your prestashop you are migrating from and change the caching system in /config/settins.inc.php to something else

@cprats pm me your ftp access, I'll check this for you

There is some code that's trying to communicate with some external service. You need to figure out where that code is, and what url it tries to access. Since you wrote that it happens roughly at the same time, I would start by looking at the module with some cron support.

@Smile what you are trying to do is to maintain your own fork of thirtybees platform, with all the benefits and drawbacks. This also means that you can't use update module to update your site, because this module works against thirtybees codebase. To keep updated, you will need to manually merge thirtybees git repository to your bitbucket fork, resolve all potential conflicts, and then manually update your site. This can get pretty ugly. I would recommend you 1) not change core code. Implement your own custom module instread, and hooks / overrides to extend the core functionality 2) if you plan to change community theme, then clone this theme to your own, change it's name, and carry on from there. You can, of course, try to merge changes to community theme to your theme, if it makes sense. But even if you don't, you should be ok. Your *old* theme should still be compatible even in future version of thirtybees

Works very nice and fast. Congrats on this release! I tested it a bit, and here are my notes: 1. my locally modified files are correctly listed in Files to get changed, but are not marked as M (this worked when I updated from 1.0.8 to 1.0.x, but when not when downgrading back to 1.0.8) 2. I could not find if my modified files are saved anywhere before they get overwritten by updater module 3. I strongly recommend to not touch community theme at all, as everyone makes changes to it. Unfortunately we don't have ps17 template inheritance functionality yet

If you are not willing to wait for 1.0.9, then you can try to apply the fix from this commit (or simply copy the newest version of Configuration.php file to your tb classed directory). That should fix this problem.

I don't think this is tb related. That's probably problem with your server configuration (firewall, connection timeout limit, etc...) or with the server your server is trying to communicate with.

Disable module Block Featured Products

You might be right. I've submitted a fix for this issue today. You can download the latest version of classes/Configuration.php file from github, upload it to your server, and test if it helps. If you do so, don't forget to let us know the result

Thanks for the but report, let's track it in github: https://github.com/thirtybees/thirtybees/issues/815

This is really harmless debug message. In fact, I'll drop it from the code in the next version, as it does not help anyone. It can mean one of two things: 1) visitor's cookie contains reference to a cart that not longer exists in your database. This can happen, for example, when some module removes abandoned carts from the database. 2) visitor's cookie contains reference to a cart that has been already converted to an order. This will usually happen on order confirmation page. In both cases we just need to remove cart reference from cookie and carry on. Neither of these are bug, and I don't see any reason why it should fill merchant's log

Any chance that these are stored inside configuration table? If so, this might be caused by this issue: https://github.com/thirtybees/thirtybees/issues/807

These notices are, well, notices. They are not errors themselves, and are not cause of your problems. You should, of course, fix the template (or module) to get rid of them, but that will not help you with those two other problems.

we shall add some check into class_index generator to prevent this kind of problems in the future

there shouldn't be any directory classes/range/pdf I suspect you accidentally copied directory classes/pdf to classes/range/pdf. This can confuse autoloader, because there are now two classes with the same name. To fix this 1) ensure that directory classes/pdf exists and that it contains file HTMLTemplateDeliverySlip.php 2) delete directory classes/range/pdf 3) delete file cache/class_index.php

If you have debug mode enabled, then disable it and try again. It has the tendency to break json/xml responses because of display_errors php directive

Don't do that, as system is not designed to share images. For example, when you delete product, all its images are deleted as well. If on of those images is shared with another product you would have a problem.

The theme does not work without the Tools.php override. It throws Call to undefined method Tools::getProductsImgs() in product-list-item.tpl This method indeed does not exists in ToolsCore, so the theme should not depend on it. I suggest you remove this from the theme. The best way to provide this functionality might be dedicated module -- your theme could trigger hook to obtain product images, and this custom module would fulfil the request. If the module were missing, then the theme would fallback to standard rendering.

Url structure has changed, which means all inbound links, bookmarks, etc wont work anymore. SEO nightmare. For example, topic urls changed from forum.thirtybees.com/topic/id/friendly-url to forum.thirtybees.com/topic/id-id/friendly-url

This check has already been fixed If it shows this warning for you, it really means you have server cache enabled on your server.

Frankly I don't know. I remember there was a whole thread (https://forum.thirtybees.com/topic/1095/paypal-6-0-0-beta-the-final-push-for-victory) dedicated to paypal v6, but that seems to be deleted since. So that knowledge is gone forever. I could find only one bug on github regarding v6 (redundant api calls on every page). While that's unfortunate, it's not something that should prevent using that version of the module. But I'm sure there is the reason nobody is using it. But it would be great if we have those reasons tracked as github issues, otherwise we can never fix this. Here we need merchants help. Please test v6, if you can, and let us know what does not work. So we can finally resolve this paypal hell.

Oh, it's also necessary to change the next line $order = $params['order']; to $order = $params['objOrder']; Basically, the beginning of the hookPaymentReturn method should look like the highlighted code here

There's another bug in hookPaymentReturn. Edit file paypal.php, find method hookPaymentReturn and change the first line from if (!$this->active || !isset($params['order']) || !$params['order'] instanceof Order) { to if (!$this->active || !isset($params['objOrder']) || !$params['objOrder'] instanceof Order) { Note that all these fixes are already part of the paypal v6.0.0, see here What is the reason paypal 6.0 is not used yet?