Traumflug

@elund, @rubben1985 Maybe you should support the Panda theme also "You" does already, thirty bees claims to be PS 1.6.1 compatible and anything deviating from this is considered to be a bug. That's how I understand various 30bz blog postings and what I observe on bug report reactions. Which means, reports like this topic are mostly a confirmation of the successful implementation of this policy. Nice, isn't it? If you have the Panda theme already, feel invited to set up a test shop, slap that theme onto it and simply try. Chances it just works are very good :-)

You can make the .com page not pointing into the shop at all. Put some PHP there which does nothing but redirect to the appropriate shop. No need for graphics, HTML, CSS, whatever, just a redirector.

Advanced EU Compliance is now an official module. If one can build a compliant shop with PS 1.6, one can do it with thirty bees, too.

Excellent, thank you!

Do you happen to have a link to this module?

If you don't link this new site somewhere, search robots can't find it.

Yes, there's a 32 byte limit in the DB per tag. Two tags = 64 bytes, and so on. Are you sure these are three tags? Or just one tag with all the words? On the product page, each tag has an 'x' on the right side. Three 'x' = 3 tags. Didn't look up whether there are limitations in PHP code, yet.

I like to follow Amazon’s lead on things, I like the way their system works in the frontend https://content.screencast.com/users/PrestaLesley/folders/Snagit(6)/media/26aa6f88-7575-407e-b11f-4b319a3dc582/06.21.2017-17.06.png Yes, this frontend appears to have just the right feature set.

Also having a “hidden” product is not a perfect idea either. Say I have a shop that sells dog products and I have a subscribe and save option like Amazon has. I need to be able to pull a monthly stock status and see how many bags of xxx food are going to be autoshipped. Having a hidden product would be the natural handle to define follow-up sales somehow. Merchants have to express somehow what should happen on subsequent shippings. I'm thinking of dog food coming with a feeding bowl first time, just the food on subsequent shippings. Or hosting subscriptions, which require processing initially, just money collection later. And of course it should be possible with a few lines of code to look up the schedule table to find out what's about to ship next week/month.

Works perfect for me, too. Thanks!

I think the task isn't too complicated. Orders go the normals way. Distinction from a non-recurring order is that shop software schedules another order regularly, without human interaction. Weekly, two-weekly, monthly, ... This automatically scheduled order orders a prepared product. This can be an empty product, just collecting money, or a non-empty product like a license renewal, weekly pizza delivery, such stuff. Task for the merchant is then to set up the initial product, mark this as being something recurring, create and link a follow-up product. This follow-up-product is hidden for shop visitors, of course. So far this doesn't touch payment modules at all. Customers get a weekly/monthly/yearly notification about their follow-up-product order and pay the usual way. Merchants likely want to bill their customers without customer interaction in some cases. As far as I can see, this can be done with payment processors supporting this, only. Task for thirty bees would be to define an appropriate API for payment modules. After such an order is done, shop software's business is to accept payment notifications and compare them with ongoing schedules.

HTML5 supports a geolocation API and there are public/free services allowing to translate that into a bureaucratic location: IPInfoDB, Google Geocoding.

Images are stored on disk, so you can make a backup of the img/ folder and just try. If it fails, restore this folder and you're where you were before.

ounces are "oz", while "lbs" are pounds, aren't they? I'd be surprised if 30bz could handle multiple weight units. I fear you have to convert all weights to one unit. I also wonder what the point of a minimum weight bigger than zero is.

A good module works within pretty much any server limits. Did you try already?

So you are saying I should create a folder /shop in /publichtml move 30bz installation to that folder and change the web root for LJsBooks.com to publichtml/shop/ Yes. Or can I just rename the folder LJsbooks.com in publichtml to shop and then change the web root for LJsBooks.com in the Addon pane to publichtml/shop Outcome is the same, isn't it?

Wait, can't you use server maintenance tools to point LJsBooks.com directly to the shop installation folder? 30bz can't do this, but Apache configuration can. Let me try to illustrate. 30bz is installed in /var/www/html/bookstores/shop. Apache configures /var/www/html/bookstores as root folder for StarGeezerStuff.com. Apache configures /var/www/html/bookstores/shop as root folder for LJsBooks.com. Doesn't sound complicated as long as one can change Apache's configuration. Nice side effect: suddenly distinct physical URIs for distinct domains of a multishop make sense!

Sounds like a good plan. To not mess up everything it's perhaps a good idea to practice with a shop copy or a standard installation, first. Every commodity PC has at least four network names: localhost, 127.0.0.1, network name and network number. In 30bz' eyes these are four distinct domains, enough for an experimental setup.

I always wondered why one can configure different physical URIs for different shops. Unless I miss something, URLs always have to end up at the installation folder; having a shop spread/splitted across two folders isn't possible. If somebody knows what the point of this is, I'm all ears. Because I have commits for removing this setting already, it can be figured from existing PHP variables easily (just like the installer does). Now, to solve @jnsgioia's case: one strategy certainly working is to put the shop into .../shop/ for both domains. Then to add a small .htaccess into ljsbooks.com's root folder with a (permanent) redirect to that folder. In this case, customers can notice the redirection, of course, the URL changes. Not sure whether a similar arrangement with an URL rewrite (instead of redirect) in this small .htaccess is possible as well. This would end up in a double-rewrite, then. Once in the small .htaccess, then again in the installation directory.

Is it needed like that? One of them starts with http://, the other one with https://. There might be usecases like a link "switch to SSL" or a redirection page automatically redirecting to the SSL-version. Or redirecting to non-SSL for picture links. Such stuff. Even if they make not much sense today, they might have had value a few years back.

Many examples on how to solve this in the default template. For example in 404.tpl: html <a href="{if isset($force_ssl) && $force_ssl}{$base_dir_ssl}{else}{$base_dir}{/if}" title="{l s='Home'}">&larr; {l s='Home page'}</a>

But then it must be crap coding Happens often. Sometimes due to sloppiness, sometimes due to laziness, sometimes due to a lack of knowledge.

Yes, it's defined. It's _DB_PREFIX_, defined in config/settings.inc.php. PrestaShop has the same definition, so no excuses to not use this definition properly :-)

@yaniv14 Tell me what you think. Well, can't say. It's good for one of the strategies, wrong way for others. I prefer to work with a target in mind, else individual changes tend to pull in different directions. @mdekker Well written code needs no distinction between Windows and non-Windows. PHP already abstracts this away. It just happens that current code violates this abstraction.

Searching for a more general solution raises the question about which paths to use: Store Unix paths on Unix; Windows paths on Windows. This requires to strictly distinguish between filesystem paths and URL paths. ~~PS_BASE_URI would become \tbshop\ on Windows.~~ It also disallows copying a Windows installation to a Linux server (would require to change all DB stored paths). Store Unix-type paths only, but use Windows paths for display purposes. Still complicated, because paths have to be converted for display, and converted back when reading paths entered by the user. Keeping all paths Unix-type, even for display purposes. In this case users have to take care of the conversion, e.g. when entering a path in a backoffice field. Options 2. and 3. forbid the usage of realpath(). Currently that's used in 174 places. Often apparently out of convenience, e.g. realpath($currentDir.'/..') could be replaced by dirname($currentDir) easily. It's non-trivial, e.g. there's a hint in the example at http://php.net/manual/en/function.dirname.php that dirname() gives a different result on Windows, too. Even if this function doesn't verify a given path against the filesystem. @yaniv14, what do you think?