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

Members
  • Content Count

    1,579
  • Joined

  • Last visited

  • Days Won

    71

Everything posted by Traumflug

  1. Traumflug

    Clear Demo Data

    I opened a Github issue to track this: https://github.com/thirtybees/ThirtyBees/issues/145
  2. @Havouza said in Guest account in general: to really state for the Guest customers what is saved about them That's certainly something you should put into your privacy declaration.
  3. I face the same issue with my effort to move shop configuration out of the database, into a regular file (https://forum.thirtybees.com/topic/76/safe-maintenance-strategy-shop-cloning/9): for multishop, URLs & Co. are stored in table 'shop_url', while for monoshops, the same data is stored in table 'configuration'. Additionally, both can be overrided with query and/or environment variables (AFAIK). I guess three reasons for this data and code duplication: Ease of development. Substantial changes to the infrastructure in projects as complex as PS/TB come with a LOT of work. And users barely honor this, because they don't see it. Attempts like the one discussed here are an exception. Removing stuff easily breaks things. After doing so, one has to try and test all the millions of combinations of functionality. monoshop/multishop, nonolanguage/multilanguage, distinct themes, all the varieties of products, and so on. Backwards compatibility. Removing the older structure means to break all the modules relying on it. Broken modules mean angry customers ("suddenly my module stopped working, but I paid it!") and disappointed developers ("Argh, I have to rework my cash-cow yet again!"). Perhaps that's the reason why PS decided to entirely start over with some parts of the software, like disallowing overrides at all or moving database access to Doctrine. And you're all aware of the results: LOTs of flaming towards PS 1.7.
  4. P.S.: certainly a useful feature would be a function to package data no longer needed for ongoing business as a downloadable ZIP, then to remove this stuff from the database of the public web server. What's not there can't be hacked, undoubtly a security improvement.
  5. @Havouza @Havouza said in Guest account in general: I want it to be real guest checkout, that take away the customer info when the order is delivered Can this be done? What about revocations? I'd at least wait 28 days before deletion. What about the warranty period? If you get the stuff back as defect after a year, how do you deal with this, without even an Email address? What about legal duties? Here in Germany, all tax relevant documents have to be stored for several years. Especially invoices and money transactions. Invoices contain all user data, so all the stuff is stored anyways.
  6. Necessary or not, it's done this way.
  7. AFAIK, database structures make no distinction between monoshop and multishop. A monoshop is a multishop with just one shop defined. And a flag for visually removing all the multishop checkboxes and menus in backoffice at page render time.
  8. Next update. Progress is slow, but I learn a lot along the way :-) Today I tried to put a shim between ShopUrlCore and ObjectModel. The idea is to override all database accesses with accesses to the array in question. This shim is class ObjectFileModel. Code is on branch 'objectfilemodel': https://github.com/Traumflug/ThirtyBees/tree/objectfilemodel This mostly works, but one way only. The array gets updated after e.g. adding a new URL to a shop. But the page load following that falls back to reading the DB. Because page rendering uses AdminController, which accesses the database directly, ignoring ObjectModel. Looks like I have to try to put a shim between AdminShopUrlController and AdminController tomorrow, too. Another idea is to connect AdminShopUrlController to ShopUrlCore directly, but then I'd loose all the validation, field forming and relational (multishop, multilanguage) code.
  9. Traumflug

    403 Forbidden

    Try it, @Havouza. Much faster than waiting for an answer :-)
  10. @spidawebs said in Backup not working?: Much better than manually doing a backup which you always tend to forget about. Cron jobs are ideal for not forgetting such tasks. These cloud based backup services require you to send your passwords there, right? So you also open them a door to manipulate your shop. Doesn't feel well to me.
  11. PS 1.7 tackles this by joining all the CSS and JS snippets into one big file for each. Pretty simple to do, just use a master CSS/JS file containing nothing but @include's for the other files and use that. The webpack compiler even manages to optimize the result (options --optimize-minimize --optimize-occurence-order --optimize-dedupe).
  12. Let me put a status update here. I managed to get a development shop running from a clone of the Git repo. There I applied this 'automatic' branch and added a couple of additional things: An attempt to not read shop domains from the database in classes/shop/Shop.php at all. Which means to remove all this redirection code there, speeding up page loads. Doing redirection via .htaccess. Writing .htaccess in backoffice adds a few lines to do this redirection. All three parts work nicely for monoshops. When trying to review the first commit for multishops I enabled multishops. After doing so, frontoffice was broken (infinite redirects), so this first commit apparently needs rework. Then I tried to add a second shop. This messed up the database somehow. Whatever I try to access, backoffice or frontoffice, results in "Internal Server Error". Disabling multishop via phpMyAdmin didn't improve this. Next step here is to drop that shop for starting over. Code is here: https://github.com/Traumflug/ThirtyBees/commits/ignoredomain P.S.: Generally, all this redirection stuff is very complex. I found at least 8 code locations dealing with it. Looks like there are at least four levels: domain "fixing" in Shop.php, something similar in FrontController.php, some widespread mechanism to redirect depending on content and an approach distinct from all this for switching between http and https. This led me to the conclusion that not storing the domain somehow would be a way to intrusive change. New plan after fixing the commits described above is to just move the configuration table into an ordinary file, making it accessible for upload scripts.
  13. Glad to see you like it. TBH, the more I think about the issue, the more I think the right way would be to get rid of all this code in classes/shop/Shop.php and classes/shop/ShopURL.php which tries to figure the "right" URL and also tries to redirect to that. A monoshop shouldn't care about the domain it's hosted on. If a merchant wants to redirect something, e.g. http:// -> https:// or typo-domain -> real domain, .htaccess is the right place to do so. A multishop should just read the domain, not try to "fix" it. If a domain happens to be not one of the multishop domains, that's a configuration error, nothing which should be validated at runtime on every single page request. Removing all that code would also remove a number of database queries, as far as I can see. I think I'll play a bit with this idea.
  14. Of course. Note that these patches are done for PS 1.7. They should be sufficient for discussing the strategy, I'll happily port them to TB, then. Patch 1 is about the shop domain. PS uses the PSSHOPDOMAIN configuration variable for this. This variable is used in dozens of places, so I decided to override the value read from the database, instead. Nice side effect: previous behavior is kept, new behavior is applied if that field is set to 'automatic' in back office, only. 014888992878330001-CO-Allow-automatic-PSSHOPDOMAIN.patch Patch 2 does the same for installation location. 014888996240770001-CO-Allow-automatic-for-Base-URI-too.patch Patch 3 also tweaks a configuration variable, this time PSSHOPENABLE. Instead of storing that value in the database, it's stored by presence of a file. This way one can easily set a store into maintenance mode by uploading a file by FTP (name matters), then do the synchronization, then remove the file. Scripts are very good at doing such sequences : - ) 014888999404540001-CO-store-PSSHOPENABLED-not-in-the-database-but-by-.patch While patch 2 appears to work so far I could think of a better strategy in this case. Code location has no interference with multishop capabilities, so the IMHO better way would be to get rid of that database entry entirely in favor of always automatic detection. Not done this way so far, because I have to keep code changes small for not running into conflicts on the next PS upgrade (or migration to TB). P.S.: glad to see one can upload patches in this forum!
  15. By profession I'm more a server admin and embedded developer, so please bear with my ignorance. Nevertheless I currently have a PS 1.7 shop almost ready for production. What I miss in pretty much any shop software is a safe way to handle maintenance. A way to deal with upgrades, patches, code improvements, without interrupting services to the customer. It looks much like every merchant just tweaks the running shop and hopes the best s/he makes no mistake. No strategy other than quickly reverting wrongdoings or, if things go really wrong, take the shop down to recover from a backup. 30B's stated goal is even to allow code editing from backoffice, surgery on the open, beating heart! As server admin I've learned that one shouldn't do such things unless one doesn't care about customer experience or enjoys to live on the dangerous side. The safe way is to do maintenance offline. On the public web server in a separate installation or on a local installation on the developer's machine. Then to test, test, test. Only after tests were satisfying, development code is synchronized with the public server. This is safe and comes with a minimum of downtime, which means a minimum of customer disruption. However, and this is the reason of this post, this requires a way to clone or synchronize a shop. Rsync shop-here to shop-there with the confidence that the copy works the same way as the origin. AFAIK, PrestaShop doesn't allow such a strategy. Server name is stored in the database, so one has to tweak that manually after an upload. Even installation location on the server is stored somewhere, one can't move a shop from one folder to another without breaking it. Wether a module is present or not isn't determined by looking at files, but by looking at some DB entry, making things inconsistent when one just removes or adds module files. Are there ThirtyBees plans to improve this situation? For PS I made a couple of patches which resolve most issues for monoshops (multishops are more complex). Are such improvements welcome? What do others think?
  16. @mdekker said in German support for thirty bees: You say that sites can be scanned with automated scripts. Do you happen to know one for sites based on PrestaShop/thirty bees? Sorry, no, never been in that business. It's also more a guess. If I'd try to, I'd simply google for shops selling products similar to mine. Most items can be found pretty easily if you know what has to be there: imprint, revocation terms, "including taxes, without shipping fees" next to the price, such stuff. DRMasterChief and mannefred have named a few additional ones above.
  17. @lesley said in German support for thirty bees: We realize things are very different over there in regard to the ecommerce laws I think this is mostly a misconception. Some 90% of what's "german e-commerce law" is based more or less directly on EU legislation. For some parts, like revocation terms, EU law is applied directly. For other parts it's done by national implementations. In short: law for all EU countries is (almost) the same. What makes the situation in Germany so tedious is our (AFAIK, worldwide unique) Abmahnwesen. Every competitor of a website can hire a lawyer and send the owner of that website a Abmahnung (cease and desist letter) for whatever that competitor thinks is not in entire agreement with laws on that site. No police, no state attorney, no court, no judge required. So far it's still similar to other countries. The really bad part here is, the website owner has to compensate (pay!) for the damage the competitor thinks he has suffered. And the website owner also has to pay for the lawyer. Unless that owner disagrees and pulls the case to court. Result of this situation is that lawyers started to search for faults on websites, then to search for competitors which could claim damages and lawyer fees. If this is done with some scripting and series cease-and-desist letters, it can be a source of pretty big income. Kind of an "industry" was born. On top of that there are competitors which try to jerk their competition, of course. Result of these revenue seeking lawyers is that even pretty minor faults get claimed. There are court cases where it was to decide whether it's sufficient to notify users about EU Online Dispute Resolution link or whether this link has to be clickable. Cases where website owners were found "guilty" to have their forename shortened to a single letter instead of having it written in full. Such stuff. Tl;dr: at the bottom line, german shop owners have to comply with the about same laws as all other european shop owners, but they're way, way, way, more keen on getting everything right to the smallest detail. Because every detail done wrong comes with a bill, with loss of cash.
×
×
  • Create New...