Traumflug

:thumbsuptone4: for doing such a video! :thumbsuptone4: for showing how to clone a shop and for working on that clone! :thumbsup_tone4: for the module doing the migration so seamlessly! To those who have a clone already or want to try on a test installation: start at 10:20 in the video.

That said, as a good merchant I should have offered you to implement all four features, take the cash for all of them and implement only the one needed thing.

Right. So you don't want an entire module, but enhance the existing module to allow subscriptions as well. Split payments are (hopefully) transparent to the user, so no module change required. Invoices can be done by 30bz, so no change required either. Entirely different perspective for a developer.

@Havouza now I only need a programmer to make the module https://docs.payza.com/reference#prestashop

But i don’t understand the logic to deleted and recreated. the reason why. It's the simplest way to do an update. Such updates happen rarely, so there's no need for performance optimization. For Tags I’ve found another logic to develop the solution Code, please! :relaxed: Ideally as a pull request, but patches uploaded here are also welcome.

No need to feel sorry, multiple reports put more emphasis on the matter and confirm the first report. In the Ubuntu tracker, bugs with duplicates even get bonus points.

I create a standard “tb in a box”, back it up, and restore it in another domain. Simsalabim, working Yes, absolutely!

People usually write code which fits their needs. They have no magic crystal ball to find out which other uses one could come up with in the future. The code in question was written in 7/2015 (reformatted later). Now it's 2017 and you found such an additional use, so this code apparently needs a review. If you can come up with better code, not breaking previous usage, I'm pretty sure it can be accepted for thirty bees 1.1.0.

In multistore this applies to the first shop. All defined domains load their related shop, all other domains load the first shop. Maybe this feature makes using multistore obsolete in some cases, because defining multiple URLs just to make one shop accessible from multiple domains is no longer necessary.

P.S.: another use case is when copying a shop from one domain to another. No need to adjust shop URLs set to automatic, then.

Doing my first steps with PrestaShop worked pretty well. Went to http://localhost/, ran the installer, eventually started editing the theme. Ah, right, mobile users! Picked the phone to see how it looks there, connected to my desktop and ... u-oh, "This page can't be opened, because Safari can't find the server" Bummer. What happened? Well, at installation time, domain name was localhost. Installer picked this up. Shop software insists on this domain and redirects to it, even if the shop is accessed from another address. Accordingly, http://mydesktop.local gets redirected to http://localhost, which is an entirely different host on the phone, of course. A long googling session later I learned how to fix this misalignment, still I couldn't resist to teach this shop software proper manners. Domain *automatic* was born. This is how it looks in Backoffice -> Preferences -> SEO & URLs: Having it enabled means that thirty bees will no longer try to redirect traffic just because the domain is "wrong". It'll just proceed. It's turned off and works as before when an actual domain name is entered in these fields. What do you think about this feature? Useful? Might it break other use cases? Thanks for your comments. Related Github pull request: https://github.com/thirtybees/thirtybees/pull/250, it'll go into thirty bees 1.1.0, then.

Is PageCache in this class index? The section should look like this: php 'PageCache' => array ( 'path' => '', 'type' => 'class', 'override' => false, ), 'PageCacheCore' => array ( 'path' => 'classes/PageCache.php', 'type' => 'class', 'override' => false, ),

Excellent! Let's assume for now these error messages are a result of you upgrading the database in this unusual way :-)

PageCache::flush() exists: https://github.com/thirtybees/thirtybees/blob/1.0.x/classes/PageCache.php#L173 Are there overrides involved? cache/class_index.php deleted (will be re-built automatically) ?

Line 286 in AjaxProcessor.php is this: php $this->nextQuickInfo[] = sprintf($this->l('Files will be saved to %s and %s'), $this->getCoreFilePath()); Two %s and just one argument indeed look like a bug.

Sounds pretty similar to this one: https://forum.thirtybees.com/topic/340/upgrade-error-500

Dataset is obviously the data which is subject for searching. As a coarse estimate one can use the size of the uncompressed database backup file.

Maybe there are some extra steps required to get these rules into effect. Instead of investigating what this could be it's probably easier to apply the patch here: https://forum.thirtybees.com/topic/320/problem-saving-seo-url-routes/3 Use a generic text editor (Word is the wrong tool), open file controllers/admin/AdminMetaController.php, find text addFieldRoute(, then 'type' => 'text', then change this 'text' to 'textLang' and save the file. On success there will be a small menu for selecting the language under each of these rewrite rule fields. Modify the rule(s) to your likings, do the same for each language, click 'Save', then 'Regenerate URLs'. This should do the trick.

Your shop is running, where's the problem?

Eeeek. Overrides. Source of trouble. Usually these overrides are made for PrestaShop. Thirty bees changed quite a bit under the hood, so no surprise if PS overrides don't work on 30bz.

See https://forum.thirtybees.com/topic/320/problem-saving-seo-url-routes: The table to edit for manual tweaks isn't configuration, but configuration_lang. Rewrite settings are language-aware, so one has to change the value for each language. Distinct values for different languages are perfectly possible. While this currently isn't possible in backoffice, a fix is provided for 1.0.2.

Done: https://github.com/thirtybees/thirtybees/pull/249 A couple of things I learned along the way: Language-aware rewrite rules are a pretty young, 30bz-only feature. They do work, switching languages on a product page changes it's URL as appropriate. Entries in configuration_lang aren't self-sufficient. They're kind of an add-on to an entry in configuration. Installer does indeed create ..._lang entries, my installed DB was too old. @braffas' patch is spot-on. Thank you.

Code snippets I found are a bit contradicting. Default values ignore the language. Installer installs apparently empty fields in configuration. Other code snippets, the one you found, too, handle it as language dependent. This raises the question whether language dependent rewrite rules can work and if yes, whether they're a wanted feature. Having language dependent rewrite rules easily opens a can of worms, e.g. just switching the language might lead to a 404 page.

Funny: without the patch, these values aren't stored at all. The shown values are the default ones.

Thanks for providing this patch, @braffas. I can confirm this misbehavior. While this change indeed appears to work, I think it's the wrong solution. This makes rewriting rules language dependent, rules are then stored in table tb_configuration_lang instead of tb_configuration. I don't think setting different rules for distinct languages works. I'm currently searching for a better solution.