datakick

@Mark from the code you posted it looks like you downgraded to bleeding edge of 1.0.x branch, instead of bleeding edge of 1.1.x. Make sure you choose the correct version

I've just checked @Traumflug's commit, and it did not fix the problem at hand. @Mark edit file /classes/ImageType.php, find function getFormatedName, and insert following code just before // Give up searching: // if $name contains _default suffix, ie. home_default then try to resolve the name without this suffix $pos = strpos($name, '_default'); if ($pos === strlen($name) - 8) { return static::getFormatedName(substr($name, 0, $pos)); } The result should looks like this:

The nice thing about core updater is that you can always go back to the previous version, if needed.

In this case, I would recommend you to update to bleeding edge. Bleeding edge should contain only tested and approved commits. There are no other tests planned for any work already submitted (there is no QA team that would do that). If some new bug was introduced, developers might discover it only by luck, during their regular work on other issues. Or it can be discovered by merchant testing of release preview. From this point of view, I do consider bleeding edge to be a stable release.

Bleeding edge refers to the main branch - 1.1.x branch. It contains code that has been tested and approved for the next release. Everything that's in this branch will be part of upcoming release. If you have development / testing server, you should run it on the bleeding edge. Please report every errors and bugs on github. It's a good idea to include some magic keywords like 'Release preview' or 'Regression' into the issue title. Issue branches contains code that is not yet integrated into the 1.1.x. The code is related to specific issue. This gives you option to test the fix on your test or production environment, and acknowledge whether it actually fixes the problem or not. Note that issue branches can contains non-finished work, so tread carefully. You should always read latest comment on the issue on github to see if it's ready for testing or not.

Please don't. I really think it's very important that users keep the developers accountable for their decisions, and remind them about the real-world impact and consequences. And you do the great job here. Granted, you will not receive any love from the developers for this, but it's very beneficial nonetheless.

I'm not sure, but it will probably take few weeks before I get to that.

No, it's not possible at the moment. It's in the pipeline, though. Together with option to change texts, logo, and generate dynamic delivery time

You should probably delete these overrides completely, if you don't use them anymore.

Let me shed some light on this problematic. Back in the day the image types were named simply 'home' or 'large', and that worked quite well. But then came multistore, and the ability to have multiple themes. And now there was a big problem with image type name collisions. Because these two (or even more) themes could use different dimensions for 'home' and 'large' image types, there was a need to have unique image type identifier per theme. Somebody come up with the idea to append theme name to the image type. And because the default theme was named simply default, this resulted in image type names like home_default, large_default, cart_default.... Unfortunately, this new functionality was not adopted well. I believe the reason is partly in generic name of default theme. But of course, there was poor communication of this feature to theme and module developers, and insufficient enforcement from core code. The module (and theme) developers weren't expected to use fully qualified image type names in the code. But they did. They should have use this new feature like this: $link->getImageUrl($image, $product, ImageType::getFormattedName('home')) But instead they hardcoded the fully qualified image types like this: $link->getImageUrl($image, $product, 'home_default') These hardcoded names in the code resulted in many modules working correctly only in default theme. If some theme developer used this new naming scheme properly, these badly-written modules didn't work with it correctly... bummer. And so theme developers reacted accordingly. They didn't wait for module developers to fix their modules. They rather dropped this use this new naming scheme altogether, and started using the same image types names as default theme. If you look into your warehouse theme config.xml file, you'll find image type 'home_default' as well. Even though it should be named 'home_warehouse'. So, after a long and painful transition from 'home' to 'home_default' image types, prestashop ended up in the very same spot it begin. All the themes now used 'xxx_default' image types. And the possibility to use different themes in multistore was once again severely limited. One of the goal of thirtybees is to fix bugs. And this is a huge bug, so it was fixed. This, and many related issues regarding fully-qualified image types were fixed, and the image type name scheme is now enforced by the core. Theme developers can't any more use 'cart_default' image type --> it will be 'warehouse_cart_default' now. There are some hiccups, of course, but these will be ironed out. Most of the code paths go through the ImageType::getFormatedName method which will make sure the image type are transformed correctly. Of course, there will be some modules that won't work with this new naming scheme. If the module developer manually concatenate strings to build image url,... well there's not much core can do to help here. Fortunately, there aren't many modules that do such blasphemy.

There are no new functions specifically for Niara. The changes to themes and image types are global. What do you talking about? First of all, these image types were already used by community-theme-default. And secondly... they are used by the theme. That's the reason why they exists. Other modules may, or may not use this image type. But in any case they should check that it exists.

Yes, something like this helps in these cases: https://github.com/thirtybees/thirtybees/pull/1057/commits/83060729b33a7065a4f78bd7ded1de56ba198e07

Yes, the best solution would be to fix all modules. Unfortunately that's not realistic solution. There are many modules that uses hardcoded `large_default` or `home_default` image types. These modules don't work on 1.1.0 anymore.

Windows is not officially supported platform. There are more issues like this one, both in core and in third party modules. That being said, I'm sure if you create a git pull request, someone from the tb team will integrate the fix. On a related note -- it looks to me that a large percentage of windows related issues could be fixed if the _PS_ROOT_DIR_ and _PS_CORE_DIR_ core constants were defined with the forward slash. I don't have the windows machine to test this, though.

I propose this pull request to strengthen backwards compatibility. @Mark, could you verify that it fixes your issue?

It is possible you are using some module that has hardcoded image type, ie home_default instead of home. Please share your url, otherwise it's just a guesswork

I can confirm this issue has been fixed. You can update your shop to bleeding edge using core updater

Yes, of course. You can copy the theme to different directory, install it, and make changes there. Or use my child theme module

File new issue here: https://github.com/thirtybees/thirtybees/issues

Never ever modify email templates inside module directory. The proper way is to copy them to your theme mails directory, and modify these copies.

You will probably have to modify the template in your theme - address.tpl

Correct. Customer either didn't give you permission, or unsubscribed later.

recaptcha module works fine as long as 'Login attempts' settings is set to 0. https://github.com/thirtybees/nocaptcharecaptcha/issues/5

Tracked here https://github.com/thirtybees/thirtybees/issues/1052

I looked into this issue and there is a simple workaround. Go to your modules and reset Community Theme Configuration module. One of this module responsibilities is to replace this particular jquery plugin with a new version. It uses displayFooterProduct hook to achieve this. Unfortunately, this hook is not specified in community-theme or niara's config.xml file --> this is what should be fixed