dynambee

@Havouza said in Let's talk about....Shipping!: So if you create a carrier where the cart value of 401$ will disable that carrier its not enough? You need to be able to use both methods for one shipping, both weight, and value. Correct. If I ship a "small packet" item that weighs ~200g it costs ~$4 to ship to the US or Europe if I don't need any tracking. If I do need tracking then it is going to cost $8. If the package weighs 1200g though then it is going to cost $20 without tracking and $24 with tracking. As such shipping costs must be calculated by weight and charged to the customer appropriately. However even with a weight-based calculation the maximum order value must be considered as explained in my previous reply. I envision the maximum order value being set on the same page where the maximum package sizes are set during carrier creation. Just a single field stored in the database to be checked by the system during checkout. The problem with too low value on shipments is a very beg issue in Sweden for the moment. Especially from China. More and more shipments are now stopped in customs because of this. It's obvious tax fraud to do it and disable fair competition Yes, this is a big problem in many countries right now and all over the world packages are being stopped more often. Pretty much everything shipped from China is declared with a $1 value or something similar. I import some stuff from China and even if I tell them to declare full value it still comes with a low value declared.

@Havouza said in Let's talk about....Shipping!: That you decide yourself. Either calculate on wieght or price That isn't the same thing. Offering shipping by price is a very valid thing to do if you want to offer different flat shipping prices and/or free shipping based on the value of the order the customer is placing. For Japanese domestic sales this is exactly what I would do as weight is rarely a consideration for domestic packages in Japan. If the weight is less than 20kg then generally only distance is considered, not weight. However for many shops the cost of shipping, especially international shipping, must be calculated by zone & order weight. Even though the cost of shipping is being calculated by weight there are still order price limitations to consider. I hate to use the same examples over and over but the ones I have already cited are important: In the USA it is illegal to declare a low value on a package being exported. Furthermore USPS policy is that small packet packages can only be valued up to $400. If you write a value exceeding $400 on a "small packet" the USPS will refuse to accept the package. As such if a 30bz customer buys more than $400 worth of items and chooses small packet shipping the store owner is faced with a few unsatisfactory options: 1. They can break the law by writing a low value on the package (which also means no insurance exceeding the declared value) 2. They can cancel the order and ask the customer to reorder with a more expensive shipping option. 3. They can eat the cost of more expensive shipping themselves (generally 2x to 3x the cost of Small Packet). However this problem could be entirely avoided by adding a maximum order value of $400 to any small packet shipping options as the customer would then be unable to choose an inappropriate shipping option for their order value. With PayPal payments any customer dispute about delivery will be automatically lost by the seller if the seller can't provide appropriate proof of shipment and/or proof of delivery, depending on the value of the order. For orders over $750 the seller must be able to provide a signature delivery confirmation. Therefore any customer order that exceeds $750 must be shipped using a shipping method that requires a signature. As with the Small Packet example, setting an order value limit of $749 on shipping methods that do not have signature delivery confirmation avoids customers choosing a delivery method that is not compatible with PayPal's requirements. There are other examples as well but the above two really should be enough. If it isn't a difficult thing to implement (and I don't know how difficult it would be) then adding a maximum order value option to each carrier would be very helpful to many shops.

@Havouza said in Let's talk about....Shipping!: If you create a carrier and use billing according to total order value then you can disable the carrier if the order is out of range. Is that what you are after? Pretty much, yes. When you create a carrier you set the maximum package size and the available weight range. I suggest adding an available order price range as well, or at least a maximum allowed order price. If a customer's cart exceeds the allowed maximum price then the carrier is not offered at checkout. This already happens if the maximum allowed carrier weight is exceed or if the maximum allowed package size is exceeded. As such adding a maximum order price doesn't seem (on the surface...) like it should be all that difficult to do.

Some have 0ver 700 possible combinations and when the customer choose to see different possibilities the price change all the time Yes, but that is the price for one (quantity) of the item they are looking at, and that is the expected behavior for all shopping carts. However when changing the quantity on the product page the item's price doesn't usually change, at least not on large mainstream eCommerce sites that I have experience with. The standard design is that the price shown is for "one" of whatever product the customer is looking at. This is why I suggest leaving the large price unchanged and if you want to show a potential subtotal do it in smaller text and with an explanation about what the number means.

If German law requires a German site to be a certain way then there isn't much option but to follow what they demand. I've never seen a major eCommerce site do what you are considering though. Not Amazon nor any other large scale site. Perhaps the AJAX calls this would create are too much extra overhead on a high traffic site but I suspect it's just not good UX practice to change the main displayed price from one to many without some sort of indication about what is going on.

@vincendenkspel said in Let's talk about Search!: Hi all, I'm the one who suggested the possibility to crowd fund modules among which an elasticsearch module. I'm working out the idea and hope to post it here somewhere on the forum on thursday. Would love to get this moving. Any further thoughts?

Coming back to this topic tonight as I am going to start working on some shipping options for my dev shop again. It really would be ideal to be able to set a "maximum order value" for a carrier, for a bunch of reasons. As mentioned above, in some countries there is a maximum price limit for First Class International ("small packet") items. The USPS limit is $400. Japan doesn't limit small packet item value but only offers up to 6000yen (~$60) insurance for these items. Other countries have various limits, too. Another good example is that if a purchase exceeds US$750 (total cart value) then PayPal requires signature delivery confirmation (search for 750 to find the relevant section.) Many inexpensive shipping options don't offer signature-on-delivery so they should be limited to orders of $750 or less. Currently there is no way to do this in PS or 30bz. So there are plenty of examples of why this would be a good option to offer, assuming it isn't an insane amount of work to implement. @mdekker, is a "maximum order value" for each carrier something that could be done without causing problems or creating a huge amount of work?

@Havouza said in One redis, many shops: Something came up that I have not really thought about. I have 3 tb shops on the same server. All use redis cache. If I understand it they use the same instance of redis. Is this not a problem? It really depends on how busy the shops are, and what your server resources are. Redis is capable of caching multiple databases within one Redis instance and this will not cause any sort of data corruption or cache problems. However Redis is not multithreaded so caching multiple 30bz databases within a single Redis instance will not scale well if the sites are busy. In this case it is better to run one Redis instance per site with each instance on its own port. On the other hand running multiple Redis instances requires more memory and creates additional system resource overhead, which can be a problem on smaller servers such as a small VPS. So if you have multiple sites that are not getting a lot of traffic then using a single instance of Redis is going to be the better (and perhaps only) option.

That would be quite non-standard eCommerce shop behavior. IMO it would be at best unexpected by customers and at worst confusing, especially if the main (large & bolded) price was changing with the quantity. If this is something you would still really like to do I would leave the large & bold main price alone and instead of having "28.56 per 1" in small letters below the price I would put the total there, in brackets. Something like this:

After doing my best to replicate the problems I had before I have been unable to do so. The problems may have been related to the other problems I had when Brad was installed, but I'm not sure if everything was caused by Brad or if it was a coincidence. As far as I can tell everything is okay with the way 30bz creates & works with SEO-friendly category URLs. I have marked this as solved.

So I figured out where it should go by installing 30bz 1.0.1 and then using Linux find to locate the file. It now works and I'll try it out to see how it goes. Edit: If anyone else is wondering the full path from your public_html root should be: administrator/themes/default/template/controllers/duplicate_urls/duplicates.tpl

Okay, I feel like an idiot but I can't make it work. Where, exactly, should that file go? The error says controllers/duplicate_urls/duplicates.tpl which isn't a full path. I have looked everywhere and dropped the duplicates.tpl file in many places but the error remains. Help?

The top of that file mentions PS in the notes in a couple of places: * Do not edit or add to this file if you wish to upgrade PrestaShop to newer * versions in the future. If you wish to customize PrestaShop for your * needs please refer to https://www.thirtybees.com for more information. Going to download the file now and try to use it.

Proper decimal place control is required for Japan, China, and Korea. Not the current main focus of 30bz perhaps but all are huge eCommerce markets.

I also often consider what Amazon does when making eCommerce decisions. For this particular feature though I don't think Amazon covers quite everything. Amazon's subscriptions are focused on physical products (and they do an excellent job of it!) while 30bz's planned subscriptions should IMO cover physical products, services, and virtual products. Services in particular would benefit from things like partial refund options.

@mdekker said in Duplicate friendly sub-category URLs from within different categories: Marking this as solved, because that admin page is supposed to be the solution. I just tried adding AdminDuplicateUrls and it crashes with a [PrestaShopException] when trying to access the menu item. This is on a Cloudways installation of 1.0.0 that was upgraded to 1.0.1 using the 30bz upgrade process. From memory the upgrade completed without errors. I assume I have done something wrong... Any ideas?

Is there a 30bz module section on Envato?

@mdekker said in Warehouse Theme Working: I have no idea why they chose not to support tb, really. I think devs will be more interested in supporting 30bz when there is a more direct way for them to make money from the platform (ie an app/module/addons store... ;))

Always make a backup before starting any migration. Most of the time things go smoothly and you don't need the backup. The one time there's no backup though...

Yes, you can have one shop using just numbers and another shop with a prefix. I like things to look standardized though so if I thought there was a likelihood of more than one shop I'd start with a prefix so that all shops have prefixes.

Better to plan for the potential of more than one shop, IMO.

@Havouza found this: http://greenmousestudio.com/en/prestashop-enhancements Free module that does the same thing and lets you add a prefix. :)

This should work: http://nemops.com/prestashop-replace-order-references-with-ids/ The comments say it works on PS 1.6.1.4 so it should work with 30bz. @Nemo, I think this is your site?

It shouldn't need a module to do this it should only be a few lines of code that need to be changed, perhaps only one line of code. I'm not familiar enough with the codebase to say where that line of code is but perhaps someone else here is. When it's pointed out it should be very easy to edit.

If there is any possible way to integrate this with PayPal's subscription payments it would really be ideal to do so. PayPal is available almost everywhere, almost anyone can open a PayPal account, customers like that they can see & manage the subscription info in their own PayPal account, there are no monthly fees for offering subscriptions, etc. I think it would make the overall subscription feature more useful to more people and thus have more potential upside for 30bz.