Traumflug

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.

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.

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 :-)

and < $Some really big number (10000) AFAIK one can simply leave such fields empty to get "infinite".

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.

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.

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?

@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.

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. :-)

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".

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!

I opened a Github issue to track this: https://github.com/thirtybees/ThirtyBees/issues/145

@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.

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.

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.

@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.

Necessary or not, it's done this way.

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.

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.

Try it, @Havouza. Much faster than waiting for an answer :-)

@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.

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).

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.

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.

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!