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,319
  • Joined

  • Last visited

  • Days Won

    35

Everything posted by Traumflug

  1. Nice to have such a module! Maybe it should even become part of the standard image handling page. Still I wonder a bit why there's an "original copy" switch. Hard to imagine a reason to not keep the original unless one never again wants to regenerate thumbnails. Same for the "progessive" switch: there's AFAIK no point in having non-progressive JPEGs. Each switch, choice, checkbox comes at a cost: Every user has to learn about the "better" position of that switch/choice/checkbox. This is time consuming and if the outcome of that learning is the same for virtually all shop operators, a waste of efforts. More options require more code, so more chances for bugs, additional code maintenance burden, larger memory footprint, etc. My $0.02
  2. The part replacing the shop_url DB table by a file is done, see https://github.com/thirtybees/ThirtyBees/pull/162 To achieve fully scriptable shop synchronization, configuration variables PSSHOPDOMAIN, PSSHOPDOMAIN_SSL and a few others have to go away, too. That's a separate task. Code for backwards compatibility will be provided, of course, so a Configuration::get('PS_SHOP_DOMAIN'); will still succeed, even if there's no longer such a database entry.
  3. Good news: I removed the shop_url table here and the shop continues to work :-) I hope I catched everything. Stuff like this: PHP foreach (Shop::getAssoTables() as $tableName => $row) { // ... $res = Db::getInstance()->getRow('SELECT * FROM `'._DB_PREFIX_.$tableName.'` WHERE `'.$id.'` = '.(int) $oldId); is hard to catch, because not grep-able. For now I simply hope this is never called with $tableName = 'shop_url'. Next step is to adjust the installer. Then to get rid of PSSHOPDOMAIN, PSSHOPDOMAIN_SSL, etc.
  4. Traumflug

    Git ignore?

    @yaniv14, you know best which files you're seeing. We do not see them and you don't tell us either. You can also look into .gitignore, it's part of the repository. You can also create another clone for testing if the previous clone contains valuable work already. For me, cloning the repo works just fine as well.
  5. Must be hard but interesting to start on a mission like TB. TBH, I'm a bit surprised to see so many bugs coming up. One would think that cloning an open source repo and just replacing the brand gives a fully working system. But I'm positive. Looking at the commits so far it's apparent that they're done by people knowing their stuff. And old stuff gets deprecated. Very good!
  6. Traumflug

    Git ignore?

    With Git one can add individual files ... sh git add <path/to/file> ... or even individual patches: sh git add -p Then do a git commit and the new commit will contain the selected changes, only. If you want to revert files that shouldn't have changed, simply check them out. By file or by folder.
  7. Phinx looks like a good option if the task were to get rid of the database entirely. For handling just one 'table' it's overfeatured. Also, the "engine" is already completed. It's just an ordinary PHP array, and writing that is as simple as PHP file_put_contents($this->def['path'], "<?php\n\n". 'global $shopUrlConfig;'."\n\n". '$shopUrlConfig = '.var_export($shopUrlConfig, true).';'."\n"); Reading it is as simple as ... well, it's already there, in a global variable. For better abstraction there's ShopUrl::get() Most of the work is to replace queries also accessing other tables or doing some data shaping. Queries with WHERE, JOIN LEFT, CONCAT or ORDER inside (pretty much any query). This has to be split into a DB access for only the other table(s), then mixing and reshaping both results to get what's required. Phinx won't allow to query both, file based and DB based storage, with a single query, as far as I can see, so no advantage for this part.
  8. Saturday night update. Reviewed each commit again and I think the existing ones are usable now. As I implemented synchronization between file based and database based storage (will go away later), every single commit keeps a fully working front- and backoffice. Still working on eliminating shop_url database table usage, step by step. Code is freshly pushed on https://github.com/Traumflug/ThirtyBees/tree/objectfilemodel , 19 commits by now. Guess is, another 20 are required to complete this task.
  9. Traumflug

    Sitemap for SEO

    How about your.shop.com/sitemap/ ? It's in PS 1.6, PS 1.7 (bare bones link list) and also in TB 1.0 (structured, with advertising blocks). Just not XML. Link that on your front page or in your footer and Google shouldn't miss a page. If there's more to have than just making shure every page is searched, I'd be a good idea to describe the extra features required. As always, every feature comes with a price (writing the code, maintaining that, users have to learn configuring it), of course :-)
  10. and < $Some really big number (10000) AFAIK one can simply leave such fields empty to get "infinite".
  11. IMG>Category>Subcat>Products Products can be in more than one category. PS cant be blamed for being fast, despite the wierd structure It's fast because of the 'weird' structure.
  12. One can't put millions of files into a single folder, there's a maximum of 65000 or something. Looking up such huge folders is also slow. Two good reasons to create some subfolder hierarchy.
  13. Has anybody tried this? I admit it's a bit a silly situation. Worked many weeks on a PS 1.7 custom theme. 1.7 for it's apparently cleaner default theme. When I was almost done, ThirtyBees appeared and PS 1.7 turned out to be a bit buggy as well as slow. Bummer. Copying the theme wasn't that difficult, it's recognized. But instead of getting at least something, templates aren't found. Messages like this appear on an otherwise blank page: Fatal error: Uncaught --> Smarty: Unable to load template file '/var/www/html/ThirtyBees/themes/classic/header.tpl' <-- thrown in /var/www/html/ThirtyBees/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php on line 129 The 1.7 default theme header.tpl is in classic/templates/_partials/header.tpl (and there is only one, not three). Is there a known way to fix this?
  14. @alwayspaws said in Docs - We Need Your Help!: I tried to edit it but got this message: "You’re editing a file in a project you don’t have write access to. Submitting a change to this file will write it to a new branch in your fork quandaries/docs, so you can send a pull request." Github and their stupid forking enforcement. Everywhere else in the world forking is considered to be a bad thing, kind of a last resort. Some even consider (non-fast-forward) merging to be evil. Perhaps opening up a real Wiki is a better idea. DokuWiki works nicely, has syntax similar to MediaWiki/Wikipedia and needs no database, so it can be backed up with Git easily.
  15. Saturday night update. The shim between ShopUrlCore and ObjectModel is now well established as 'ObjectFileModel'. Things start to work, I think editing multishop URLs (backoffice -> Advanced parameters -> Multishop) is complete already. This shim between AdminShopUrlController and AdminController was tried, but dropped. Instead I taught ObjectFileModel to not only write, but also read entries. Typical for the Model-View-Controller concept, but PrestaShop apparently prefers to read from the DB directly (somewhat understandable, one can do some data shaping, like sorting, inside DB queries). Code is on branch ‘objectfilemodel’: https://github.com/Traumflug/ThirtyBees/tree/objectfilemodel , rebased to latest 'master'. Branch length currently 12 commits. Things get clearer, commits smaller, which is usually a good sign. Currently hunting down all usages of the 'shop_url' table and replacing that with the file based storage. :-)
  16. Yes, certainly a nice review system. Also full width for the product, picture almost at the center. Well thought! Cons: not EU legal compliant :-) And still too much mess/distraction for my taste. I'd remove that top bar with the phone number, "Explore Zappos" in the footer (duplication of the top menu) and one of "may also like", "customers who bought" or "customers who viewed".
  17. Traumflug

    Clear Demo Data

    For those not tracking Github: it's already done. If you can't wait for the next release, look at this commit: https://github.com/thirtybees/ThirtyBees/commit/5abcc50db92c71d6467cdf2c18047d610ed3f240 Awesome work, Michael!
  18. Traumflug

    Clear Demo Data

    I opened a Github issue to track this: https://github.com/thirtybees/ThirtyBees/issues/145
  19. @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.
  20. 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.
  21. 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.
  22. @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.
  23. Necessary or not, it's done this way.
  24. 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.
  25. 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.
×
×
  • Create New...