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.

Traumflug

Administrators
  • Content Count

    1,461
  • Joined

  • Last visited

  • Days Won

    51

Everything posted by Traumflug

  1. If you don't link this new site somewhere, search robots can't find it.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. HTML5 supports a geolocation API and there are public/free services allowing to translate that into a bureaucratic location: IPInfoDB, Google Geocoding.
  7. 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.
  8. 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.
  9. A good module works within pretty much any server limits. Did you try already?
  10. 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?
  11. 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!
  12. 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.
  13. 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.
  14. 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.
  15. 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>
  16. But then it must be crap coding Happens often. Sometimes due to sloppiness, sometimes due to laziness, sometimes due to a lack of knowledge.
  17. 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 :-)
  18. @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.
  19. 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?
  20. Writing this I see this usage of realpath() in the snippet cited above. realpath() returns a Windows path on Windows, see example #2 here: http://php.net/manual/en/function.realpath.php Using str_replace() with one string being a Unix path and the other one being a Windows path doesn't work, of course. Bug found :-)
  21. Grepping around one can see this: sh config/defines.inc.php:70:if (!defined('_PS_ROOT_DIR_')) { config/defines.inc.php:71: define('_PS_ROOT_DIR_', realpath($currentDir.'/..')); Which means, _PS_ROOT_DIR_ includes the subfolder of the shop installation. This definition is used for local file accesses, like finding images, themes, such stuff. PS_BASE_URI is used for remote accesses, like generated URLs. It's the path appended to the domain for reaching the shop installation. Which means, if you can follow links on shop pages, PS_BASE_URI is set correctly. Put together, both of these definitions appear to be fine in your installation. If there is a bug, it's in this email generating code.
  22. We cannot expect windows specific bugs will be addressed (like this one). Well, I don't really like to write this. Still it may help to understand what's going on. An empirical rule of thumb from the 3D printer world is that developers run some sort of Unix, while Windows is used by the clueless. Reality is sometimes sad. There are exceptions, of course. This has two implications, on top of the limitations mdekker mentioned already: Windows bugs don't get fixed because developers don't use this OS, so they're simply not aware of these bugs. Windows bugs don't get fixed because Windows users struggle to create useful bug reports, much less they manage to (or help to) fix bugs. That said, I'm pretty sure fixes for these Windows specific bugs are more than welcome. Or bug reports describing how to reproduce the issue at hand. @yaniv14 - I'm not sure whether it's a good idea to test on a Windows machine for a Linux production server. Ideally, test and production environments are as similar as possible. - If you think PS_BASE_URI should be /, well, change it. It's a setting changeable in backoffice (Preferences -> SEO & URLs).
×
×
  • Create New...